Mar 12 2018

McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals

The nonperishable nature of medical data makes an irresistible target for cybercriminals. The art of hacking requires significant time and effort, encouraging experienced cybercriminals to plot their attacks based on the return they will see from their investment. Those who have successfully gained access to medical data have been well rewarded for their efforts. One seller stated in an interview that “someone wanted to buy all the … records specifically,” claiming that the effort had netted US$100,000.

While at a doctor’s appointment with my wife watching a beautiful 4D ultrasound of our unborn child, I noticed the words “saving data to image” flash on the screen. Although this phrase would not catch the attention of most people, given my research on how cybercriminals are targeting the health care industry, I quickly began to wonder why an ultrasound of our child would not instead save to a file. Intrigued, I decided to dig into the world of medical imaging and its possible security risks. The results were disturbing; ultimately, we were able to combine attack vectors to reconstruct body parts from the images and make a three-dimensional model.


Most hospitals or medical research facilities use PACS, for picture archiving and communication system, so that images such as ultrasounds, mammograms, MRIs, etc. can be accessed from the various systems within their facility, or through the cloud.

A PACS setup contains multiple components, including a workstation, imaging device, acquisition gateway, PACS controller, database, and archiving—as illustrated in the following graphic:

The basic elements of PACS infrastructure.

The imaging device creates a picture, such as an ultrasound or MRI, which is uploaded to an acquisition gateway. Because much of the imaging equipment in use by medical facilities does not align with security best practices, acquisition gateways are placed in the network to enable the digital exchange of the images. The acquisition gateway also often acts as the server connecting to the hospital’s information system (using the HL7 protocol) to enrich images with patient data.

The PACS controller is the central unit coordinating all traffic among the different components. The final component in the PACS infrastructure is the database and archiving system. The system ensures that all images are correctly stored and labeled for either short- or long-term storage.

Larger implementations might have multiple imaging devices and acquisition gateways in various locations, connected over the Internet. During our investigation, we noticed many small medical practices around the world using free, open-source PACS software, which was not always securely implemented.

To determine how many PACS servers are connected depends on on how you search using Shodan, a search engine for finding specific types of computers connected to the Internet. Some servers connect over TCP 104; others use HTTP TCP 80 or HTTPS TCP 443. A quick search revealed more than 1,100 PACS directly connected to the Internet, not behind a recommended layer of network security measures or virtual private networks (VPNs).

PACS systems connected to the Internet. Darker colors represent more systems.

Our eyebrows began to rise very early in our research, as we came across “IE 6 support only” messages or ActiveX controls and old Java support; many of these products are vulnerable to a plethora of exploits. For example, one of the PACS generated an error page when we changed one parameter. This is a very basic common way of testing if the application developers did proper input sanitation check to prevent attackers inserting code or generating failures that could reveal data about the application and can give clues to compromise the system.

A stack-trace error.

The stack-trace dump revealed the use of Apache Tomcat Version 7.0.13, which has more than 40 vulnerabilities.

When communicating with the DICOM (digital imaging and communications in medicine) port, TCP 104, it is possible to grab the banner of a server and get a response. As we queried, we recorded different responses. Let’s look at one:

\x02\x00\x00\x00\x00\xbe\x00\x01\x00\x00ANY-SCP         FINDSCU         \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x151.2.840.10008.!\x00\x00\x1b\x01\x00\x00\x00@\x00\x00\x131.2.840.10008.1.2.1P\x00\x00>Q\x00\x00\x04\x00\x00@\x00R\x00\x00"1.2.826.0.1.3680043.2.135.1066.101U\x00\x00\x0c1.4.16/WIN32


The FINDSCU string refers to the findscu tool, which can be used to query a PACS system. The DICOM standard defines three data models for the query/retrieve service. Each data model has been assigned with one unique ID for the C-FIND, one for the C-MOVE, and one for C-GET; so all together there are nine unique IDs, three for each model. In the preceding banner, we retrieved two of those IDs:

  • 2.840.10008.1.2.1: A transfer unique ID that defines the value “Explicit VR Little Endian” for data transfer
  • 2.826.0.1.3680043.2.135.1066.101: A value referring to the implementation class

Another value in the banner, “1.4.16/WIN32,” refers to the implementation version. In the context of the medical servers, this refers to the version of XAMPP, aka Apache with MariaDB, PHP, and Perl. This server was running Apache 2.4.9, which is publicly known to contain nine vulnerabilities.

In other cases, there was no need to search for vulnerabilities. The management interface was wide open and could be accessed without credentials.

A PACS interface.

What does this mean? It is possible to access the images.


In addition to expensive commercial PACS systems, open-source or small-fee PACS are available for small health care institutions or practices. As we investigated these systems, we found that our fears were well founded. One web server/client setup used the defaults “admin/password” as credentials without enforcing a change when the server is started for the first time. We found more problems:

  • Unencrypted traffic between client and server
  • Click jacking
  • Cross-site scripting (reflected)
  • Cross-site scripting stored as cross-site request forgery
  • Document object model–based link manipulation
  • Remote creation of admin accounts
  • Disclosure of information

Many of these are ranked on the list of OWASP Top 10 Most Critical Web Application Security Risks list, which highlights severe flaws that should be addressed in any product delivered to a customer.

We have reported the vulnerabilities we discovered to these vendors following our responsible disclosure process. They cooperated with us in investigating the vulnerabilities and taking appropriate actions to fix the issues.

But why should we spend so much time and effort in researching vulnerabilities when there are many other ways to retrieve medical images from the Internet?

Medical Image Formats

The medical world uses several image formats for different purposes. Each format has different requirements and works with different equipment, protocols, etc. A few format examples:

  • NifTi Neuroimaging Informatics Technology Initiative
  • Dicom Digital Imaging and Communications in Medicine
  • MINC Medical Imaging NetCDF
  • NRRD Nearly Raw Raster Data

Searching open directories and FTP servers while using several search engines, we gathered thousands of images—some of them complete MRI scans, mostly in DICOM format. One example:

An open directory of images.

The DICOM format originated in the 1980s, before cybersecurity was a key component. The standard format contains a detailed list of tags such as patient name, station name, hospital, etc. All are included as metadata with the image.

Opening an image with a text editor presents the following screen:

An example of the DICOM file format.

The file begins with the prefix DICM, an indicator that we are dealing with a DICOM file.  Other (now obscured) strings in this example include the hospital’s name, city, patient name, and more.

The Health Insurance Portability and Accountability Act requires a secure medical imaging workflow, which includes the removal or anonymizing of metadata in DICOM files. Researching the retrieved files from open sources and directories, we discovered most of the images still contained this metadata, such as in the following example, from which we extracted (obscured) personally identifiable information (PII).

Metadata discovered in a DICOM file.

Combining Vulnerabilities and Metadata

We combined possible vulnerabilities and the metadata to create a test scenario, installing information from a dummy patient, including an x-ray picture of a knee, to the vulnerable PACS server.

Our test patient record, followed by an x-ray of a knee. 

Using vulnerability information gathered in an earlier phase of research, we launched an attack to gain access to the PACS server. Once we had access, we downloaded the image from our dummy patient and altered the metadata of the image series, changing all references of “knee” to “elbow.”

Altered metadata of the test patient image.

We then saved the picture and uploaded it to the server. Checking the records of our dummy patient, we found our changes were successful.

Changes successfully updated.

Reconstructing Body Parts

In the medical imaging world, a large array of software can investigate and visualize images in different ways, for example, in 3D. We took our collection of images, and using a demo version of 3D software, we reconstructed complete 3D models of vertebrae, pelvis, knees, etc. and, in one case, we reconstructed a partial face.

Because we firmly believe in protecting privacy, the following example—a series of images from a pelvis—comes from a demo file that accompanies the software.

An example of a series of images.

After selecting areas of interest and adjusting the levels, we generated a 3D model of the pelvis:

A 3D model of the pelvis.

The application that generated the 3D model has a feature that allowed us to export the model in several data formats to be used by other 3D drawing programs. After the export, we imported the data into a 3D drawing program and converted the file to STL, a popular format for 3D objects and printers.

In short, we began with files from open directories, transformed them into a 3D model, and printed a tangible model using a 3D printer:

Our 3D model of a pelvis.


When we began our investigation into the security status of medical imaging systems, we never expected we would conclude by reconstructing body parts. The amount of old software used in implementations of PACS servers and the amount of vulnerabilities discovered within the software itself are concerning. We investigated relatively few open-source vendors, but it begs the question: What more could we have found if we had access to professional hardware and software?

Default accounts, cross-site scripting, or vulnerabilities in the web server could lead to access to the systems. Our research demonstrates that once inside the systems, the data and pictures can be permanently altered.

In May 2017, one report claimed that through artificial intelligence pictures could be studied to determine how long a person will live. What if criminals could obtain that information and use it for extortion?

We understand the need for quickly sharing medical data for diagnosis and treatment and for storing medical images. We advise health care organizations to be careful when sharing images on open directories for research purposes and to at least scrape the PII data from the images.

For organizations using a PACS, ask your vendor about its security features. Employ a proper network design in which the sharing systems are properly secured. Think not only about internal security but also about the use of VPNs and two-factor authentication when connecting with external systems.


For more on the health care industry follow @McAfee_Labs and catch up on all threats statistics from Q417 in the March Threats Report.

The post McAfee Researchers Find Poor Security Exposes Medical Data to Cybercriminals appeared first on McAfee Blogs.

Mar 02 2018

How Hackers Bypassed an Adobe Flash Protection Mechanism

The number of Flash Player exploits has recently declined, due to Adobe’s introduction of various measures to strengthen Flash’s security. Occasionally, however, an exploit still arises. On January 31, Kr-Cert reported a zero-day vulnerability, identified as CVE-2018-4878, being exploited in the field. (Adobe has released an update to fix this flaw.) We analyzed this vulnerability and found that it bypassed the byte array mitigation feature that was introduced to prevent “length corruption” attacks in Flash. This post will focus on how the exploit bypasses the length checks.


How the exploit works

This exploit has been used in targeted attacks and arrives as a Microsoft Office Excel file with an embedded Flash file. On opening the Excel file, the Flash file contacts a server and requests a key. Once the key is received, the file decodes another embedded Flash file, which is the actual exploit.

The key is 100 bytes. It decodes and loads the embedded file using the loader.loadbyte function:

Because the URL for the key was offline, we could not retrieve it. But the sample hash was available online on various sites. We analyzed the sample (SHA-256) 1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d.

This Adobe .SWF file contained multiple ActionScript 3 files as well as two embedded files in the BinaryData section, constituting the shellcode (marked in red in the following screen):

The exploit in action

When launched, the exploit checks if the system is running Windows. If so, it triggers the vulnerability.

As we see in the preceding image, the exploit takes several steps:

  • It creates a mediaplayer object
  • It initializes the drmManager property of mediaplayer to a specially crafted class based on the DRMOperationCompleteListener object nugamej.
  • The object nugamej is “freed,” but the drmManager points to the same memory location that nugamej used previously

If we take a close look at nugamej, we can see that it was created from the class Rykim, which implements the DRMOperationCompleteListener class. The Rykim class has various “uint” variables with values set as 0x1111, 0x2222, etc.:

These variables will be used later to access various addresses in the process space and other operations.

The exploit then causes an exception by using Localconnection().connect, creates the new variable “katyt” of the Rykim class, and implements the DRMOperationCompleteListener class. A time check calls the function “cysit”:

Cysit checks whether the newly allocated object’s a1 variable is 0x1111. If the value is not equal to 0x1111, then cysit stops the timer and proceeds with the exploitation.

The exploit creates another object, “kebenid” of the type “Qep,” which extends the byte array class. The length of kebenid is set to 512 bytes. This will be modified later to make a read-write primitive to gain unrestricted access to process memory.

Byte array checks to avoid corruption

We can see the structure of the byte array from

We can see that the byte array class has array, capacity, and length. In the past we have seen attackers corrupting the length variable to arbitrarily read and write to a memory location. Thus there is an extra check to ensure the integrity of the byte array. The check creates a secret value that is XORed with array/capacity/length and saved in the variables check_array/check_capacity/check_length.

When these variables are accessed, they are XORed with the secret key and their value is compared to the values stored in check_array/check_capacity/check_length. If they match, then we have genuine data; otherwise it will throw an error as in the following image:

Bypassing the checks

From the preceding code, we can retrieve the key by simply using any of the following calculations:

If the value of copyOnWrite is 0, then the key will be check_copyOnWrite.

If we look carefully, we see both the katyt and kebenid object variables point to same memory locations. This can be confirmed If we print and compare the variables of the two objects.

Comparing the following variables with the byte array structure, as previously mentioned, we get the following:

So if we change katyt.a24 and katyt.a25, that will actually change the byte array capacity and byte array length. Then we just need to find the XOR key and we can set it to any length we want.

Thus in this exploit the key is found using the logic Array ^ check_array = key.

Once the key is available, we can easily modify the byte array capacity and length to 0xFFFFFFFF and check_length, thus bypassing the byte array security mitigations, and we can read or write anywhere in the process space:

Code execution

The exploit uses the preceding read-write primitive, gained through the byte array object, to read memory and search for kernel32.dll and functions such as VirtualProtect, and CreateProcessA. Once the addresses of these functions are located, shellcode can be executed on the system. This technique is very well documented online. The following screen shot shows the code responsible for searching kernel32.dll, later locating the VirtualProtect API address as 0x75ff2c15:

The exploit later executes the shellcode and connects to a URL:

It also launches cmd.exe using CreateProcessA:

The shellcode also checks for some antimalware products:


Attackers constantly search for ways to bypass new protection mechanisms. This exploit shows one such way. As always, we advise readers to be careful when opening unknown attachments and documents received in email.

McAfee Network Security Platform customers are protected from this vulnerability through signature ID: 0x45223900.



SHA-256: 1a3269253784f76e3480e4b3de312dfee878f99045ccfd2231acb5ba57d8ed0d


  • hxxp://
  • hxxp://
  • hxxp://


The post How Hackers Bypassed an Adobe Flash Protection Mechanism appeared first on McAfee Blogs.

Jan 04 2018

Decyphering the Noise Around ‘Meltdown’ and ‘Spectre’

The McAfee Advanced Threat Research (ATR) Team has closely followed the attack techniques that have been named Meltdown and Spectre throughout the lead-up to their announcement on January 3. In this post, McAfee ATR offers a simple and concise overview of these issues, to separate fact from fiction, and to provide insight into McAfee’s capabilities and approach to detection and prevention.

There has been considerable speculation in the press and on social media about the impact of these two new techniques, including which processors and operating systems are affected. The speculation has been based upon published changes to the Linux kernel. McAfee ATR did not want to add to any confusion until we could provide our customers and the general public solid technical analysis.

A fully comprehensive writeup comes from Google Project Zero in this informative technical blog, which allowed ATR to validate our conclusions.

The Techniques

Meltdown and Spectre are new techniques that build upon previous work, such as “KASLR”  and other papers that discuss practical side-channel attacks. The current disclosures build upon such side-channel attacks through the innovative use of speculative execution.

Speculative execution has been a feature of processors for at least a decade. Branch speculation is built on the Tomasulo algorithm. In essence, when a branch in execution depends upon a runtime condition, modern processors make a “guess” to potentially save time. This speculatively executed branch proceeds by employing a guess of the value of the condition upon which the branch must depend. That guess is typically based upon the last step of the same branch’s previous execution. The conditional value is cached for reuse in case that particular branch is taken again. There is no loss of computing time if the condition arrives at a new value because the processor must in any event wait for the value’s computation. Invalid speculative executions are thrown away. The fact that invalid speculations are tossed is a key attribute exploited by Meltdown and Spectre.

Despite the clearing of invalid speculative execution results without affecting memory or CPU registers, data from the execution may be retained in the processor caches. The retaining of invalid execution data is one of the properties of modern CPUs upon which Meltdown and Spectre depend. More information about the techniques is available on the site

Because these techniques can be applied (with variation) to most modern operating systems (Windows, Linux, Android, iOS, MacOS, FreeBSD, etc.), you may ask, “How dangerous are these?” “What steps should an organization take?” and “How about individuals?” The following risk analysis is based upon what McAfee currently understands about Meltdown and Spectre.

There is already considerable activity in the security research community on these techniques. Sample code for two of the three variants was posted by the Graz University (in an appendix of the Spectre paper). Erik Bosman has also tweeted that he has built an exploit, though this code is not yet public. An earlier example of side-channel exploitation based upon memory caches was posted to GitHub in 2016 by one Meltdown-Spectre researcher Daniel Gruss. Despite these details, as of this writing no known exploits have yet been seen in the wild. McAfee ATR will continue to monitor researchers’ and attackers’ interest in these techniques and provide updates accordingly. Given the attack surface of nearly every modern computing system and the relative ease of exploitation, it is highly likely that at least one of the aforementioned variants will be weaponized very quickly.

McAfee researchers quickly compiled the public exploit code for Spectre and confirmed its efficacy across a number of operating systems, including Windows, Linux, and MacOS.


To assess the potential impact of any vulnerability or attack technique, we must first consider its value to attackers. These exploits are uniquely attractive to malicious groups or persons because the attack surface is nearly unprecedented, the attack vector is relatively new, and the impacts (privilege escalation and leaks of highly sensitive memory) are detrimental. The only naturally mitigating factor is that these exploits require local code execution. A number of third parties have already identified JavaScript as an applicable delivery point, meaning both attacks could theoretically be run from inside a browser, effectively opening an avenue of remote delivery. As always, JavaScript is a double-edged sword, offering a more user-friendly browsing experience, but also offering attackers an increased attack surface in the context of the browser’s executing scripted code.

Any technique that allows an attacker to cross virtual machine boundaries is of particular interest, because such a technique might allow an adversary to use a cloud virtual machine instance to attack other tenants of the cloud. Spectre is designed to foster attacks across application boundaries and hence applies directly to this problem. Thus, major cloud vendors have rushed to issue patches and software updates in advance of the public disclosure of these issues.

Additionally, both Meltdown and Spectre are exceptionally hard to detect as they do not leave forensic traces or halt program execution. This makes post-infection investigations and attack attribution much more complex.


Because we believe that Meltdown and Spectre may offer real-world adversaries significant value, we must consider how they can be used. There is no remote vector to these techniques; an attacker must first deliver code to the victim. To protect against malicious JavaScript, we always urge caution when browsing the Internet. Allow scripting languages to execute only from trusted sites. McAfee Windows Security Suite or McAfee Endpoint Security (ENS) can provide warnings if you visit a known dangerous site. These McAfee products can also provide an alternate script-execution engine that prevents known malicious scripts from executing.  As operating systems are changed to mitigate Meltdown and Spectre, organizations and individuals should apply those updates as soon as possible.

Even though we have not seen any malware currently exploiting these techniques, McAfee is currently evaluating opportunities to provide detection within the scope of our products; we expect most solutions to lie within processor and operating system updates. Based on published proofs of concept, we have provided some limited detection under the names OSX/Spectre, Linux/Spectre, and Trojan-Spectre.

Microsoft has released an out-of-cycle patch because of this disclosure: Due to the nature of any patch or update, we suggest first applying manual updates on noncritical systems, to ensure compatibility with software that involves the potential use of low-level operating system features. McAfee teams are working to ensure compatibility with released patches where applicable.

While the world wonders about the potential impact of today’s critical disclosures, we also see a positive message. This was another major security flaw discovered and communicated by the information security community, as opposed to the discovery or leak of “in the wild” attacks. Will this disclosure have negative aspects? Most likely yes, but the overall effect is more global attention to software and hardware security, and a head start for the good guys on developing more robust systems and architectures for secure computing.

The post Decyphering the Noise Around ‘Meltdown’ and ‘Spectre’ appeared first on McAfee Blogs.

Nov 24 2017

Don’t Substitute CVSS for Risk: Scoring System Inflates Importance of CVE-2017-3735

I am a wry observer of vulnerability announcements. CVE-2017-3735—which can allow a small buffer overread in an X.509 certificate—presents an excellent example of the limitations of the Common Vulnerability Scoring System (CVSS). This scoring system is the de facto security industry standard for calculating and exchanging information about the severity of vulnerabilities. The problem is that CVSS is used for far more than it was intended.

For many organizations, security tools, and risk assessments, a CVSS score has become the security industry’s shorthand substitute for risk scoring and impact rating. In fact, many organizations measure their ongoing risk posture by counting the number of unfixed vulnerabilities and their associated CVSS scores.

The McAfee Product Security Incident Response Team (PSIRT) uses CVSS Version 3.0 as an important tool to assess vulnerabilities. McAfee PSIRT augments CVSS with other risk analysis techniques, similar to Microsoft PSIRT’s Exploitability Index and Security Update Severity Rating System.

CVSS is useful, but must not be confused with deeper risk assessment. Strictly relying on CVSS for vulnerabilities such as OpenSSL’s CVE-2017-3735 is likely to cause incident responders to focus their organizations’ resources on patch cycles that may be unnecessary. In addition, PSIRT credibility and influence may be squandered on low-impact, low-probability issues. Due to the sheer volume of issues being discovered and reported, PSIRT must remain focused on those that have a high probability of exploitation and whose organizational impact or attacker value make them worthy of exploitation.

But as we shall see from the following analysis, a vulnerability itself, taken out of context, cannot be equated to risk. Furthermore, CVSS has an inherent problem in that the impact is averaged against the exploitability: From the attacker’s perspective, this is a mistake, because threat actors exploit vulnerabilities to suit their goals, not just because something is easy.

For those readers whose sole interest is assessing OpenSSL CVE-2017-3735, this issue, I believe, should be rated as a low to very low risk. Although easy to perform, exploitation does not offer an attacker much of value. The most likely impact will be cosmetic within a text display. Plus, the code in which CVE-2017-3735 occurs is not called from OpenSSL’s protocol and cryptographic functions,[1] but is rather confined to the display of an X.509 certificate, typically for users consumption. (Certificate display does not take place as a part of typical cryptographic functions.)

Taking either of the competing published CVSS scores for this vulnerability, 5 or 7.5, at face value is misleading. Without further analysis, one might be tempted to raise the risk from CVE-2017-3735 beyond its rather minor impact. That is why I decided to investigate further, including reading the offending module’s code on GitHub. The CVSS measure of CVE-2017-3735 provides a situation where accurate scoring does not match the likelihood of exploitation and increases the score above what a risk analysis would probably reach.

Although it is true that attackers must choose exploits that lie within their technological capabilities—namely, exploits that are easy enough to ensure success—the first concern will nearly always be, “What will the exercise of this vulnerability achieve for me?”

In other words, what matters is the impact or result from the exploitation that is key to choosing a particular attack, not its relative ease or difficulty. If a vulnerability advances the attacker’s goals, then it will be considered for use. If there is nothing to gain, the vulnerability will not be exploited.

Limits to CVSS

Attackers exploit vulnerabilities that further their goals: That is a key point when assessing the potential for harm of any vulnerability. In this analysis, we will take a closer look at CVE-2017-3735 for its potential value to attackers. Along the way, we will also examine some of the limitations of CVSS as it applies to this vulnerability.

I do not mean to assert that CVSS is not an important tool for assessing vulnerabilities. I have worked with CVSS since before Version 1 was published; CVSS is key to prioritizing initial responses to vulnerabilities as they are released. CVSS may comprise one component of a robust risk rating method or approach.

I like to characterize CVSS as “potential severity.” A CVSS score, when fairly calculated,[2] can indicate what any vulnerability might harm. CVSS scores are particularly useful for triage, before a deeper analysis.

The McAfee PSIRT makes use of CVSS as a core component of incident response, just as many organizations PSIRTs do. As a CVE Numbering Authority, McAfee PSIRT must calculate a CVSS score for every published vulnerability. In practice, nearly every potential issue is scored as a critical foundation of PSIRT’s robust risk assessment.

Still, despite the importance of CVSS to vulnerability triage, it is a mistake to confuse a CVSS score with a risk rating, as we shall see.

CVE-2017-3735 has had two competing CVSS scores published.[3] The difference is in the rating of the impact: Integrity = High or Integrity = Low, resulting in a combined score of either 7.5 or 5.3 (in CVSS Version 3.0). In either case, both scores earn the exploitability rating of 10, because the issue may be exploited over a network without authentication.





How can there be two CVSS calculations? Why is one calculation High and one Low? Plus, is Integrity the correct impact parameter?

We can answer these questions by analyzing what the vulnerability allows.

The vulnerability is a buffer overread. An attacker may read one more byte from program memory than should be allowed. The attacker’s advantage of the unallowed access is directly related to where that extra byte exists. After looking at the code on GitHub, it appears all buffers in that module are allocated from program heap memory. Although running programs can exhibit macro patterns in their heap allocations and deallocations, generally, we can assume that any allocation may reside wherever it is convenient for the program memory manager to grab a piece of memory sufficiently large to support the request. This introduces an element of entropy (randomness) into any particular allocation. Each allocation may come from any portion of heap memory; there is no guarantee of a particular address.

Because a particular address cannot be guaranteed, an overread will get whatever bytes happen to be larger than that allocation’s required size.

Whichever data happen to be at that address is what the overread vulnerability will retrieve. Buffer overread exploitation can be a fishing expedition; there are no guarantees of the data retrieved, though there may be macro patterns in programs in which runtime processing is relatively consistent from run to run. The data returned depends on how lucky the attacker is. We saw the same situation in the Heartbleed overread vulnerability.

Just One Byte

For CVE-2017-3735, the overread is precisely a single byte. That is a very small payoff for the attacker, especially considering that there is no guarantee of what that byte might contain.

Furthermore, even if this were not an overread but rather an overflow (which it is not), a single byte is not enough space for malicious code to allow an attacker to exit to a command shell. A buffer overread does not allow an attacker to push code into a program heap. It allows an attacker only to retrieve data (a single byte) that the attacker should not have reached.

Although we may be surprised some day by a clever attacker’s ingenious use of a single byte, today we see no way that anyone can benefit.

If CVE-2017-3735 allows an attacker to retrieve only a single byte, then why have CVSS scorers used the Integrity impact rather than Confidentiality? Heartbleed, a heap buffer overread that returned nearly 64KB to the attacker, impacted Confidentiality. Attackers retrieved data they should not have been able to access. Yet CVE-2017-3735 has been scored on Integrity. There is a clue alongside the description.

Because I do not have access to the graph of code calls to the vulnerable IPAddressFamily routines, I cannot confirm the following educated guess. However, typical cryptographic and protocol implementations do not dump certificates to text; primarily users do. Which indicates that an attacker does not retrieve the extra byte. Instead, the extra byte is converted to text in the IPAddressFamily certificate extension’s human-readable dump. Thus the integrity of the text representation of an X.509 certificate has been impacted. With this understanding of the impact, scorers have used Integrity rather than Confidentiality.

If the attacker retrieves the text dump, is there a way to track back from various text irregularities to the value of the extra byte? I have not looked at a range of dumps to confirm or deny. Perhaps this is either not possible or not a productive approach.

If there is any way to retrieve the data byte, then the proper CVSS score would have to be Confidentiality = Low rather than None, which would increase the CVSS score to either 6.5 or 8.2, depending upon Integrity’s value, Low or High.

A CVSS score of even 5.3 gives a luster of importance to CVE-2017-3735 that it does not deserve. Any of the potentially higher scores suggest the wrong direction, which is probably why scorers refrained from including the potential for a confidentiality impact. Still, we should analyze this score to understand the strengths and limitations of CVSS. If scored for all impacts and the ease of exploitation at 6.5, CVSS indicates that this is an important vulnerability that should be addressed in a timely manner. Yet if my analysis is correct, CVE-2017-3735 should not move to the top or even middle of anyone’s work queue. Patch it in due time, through scheduled update cycles. Nothing more.

The potential impact from CVE-2017-3735 is probably not significant in the vast majority of OpenSSL’s use cases. Integrity = Low, maybe Confidentiality = Low, too. Attacker utility = None.

In fact, the most often published description for CVE=2017-3735 indicates the trivial nature of any impact: “The most likely result would be an erroneous display of the certificate in text format.” (See References.[4])

After reading this analysis, I hope it is clear that CVSS fails to account for the complete situation with respect to CVE-2017-3735.

Unequal Weights

As we mentioned, the exploitability and impact scores are each weighted equally (actually, averaged). From the attacker’s view, this is inaccurate.

Attackers do not equally exploit every vulnerability. More important, attackers do not choose to exploit a vulnerability simply because it is easy to exploit. They have no time for that; attackers are trying to achieve their goals, whatever those may be. Anyone prioritizing vulnerability responses needs to keep this in mind as we analyze.

The following published description for CVE-2017-3735 is, at the very least, misleading and erroneous, considering the single-byte heap buffer overread affects only a user-initiated text dump:

“Successfully exploiting this issue will allow attackers to bypass security restrictions and perform unauthorized actions; this may aid in launching further attacks.”

There are no “security restrictions” involved in a certificate transformed to text. Further, a single byte is insufficient to enable “launching further attacks” even if the issue were more than an overread: The attacker cannot gain control of program memory through this flaw.

Quite often, organizations have hundreds or thousands of vulnerabilities to examine. To which should they respond first? Which response should get the most resources? Which of the perhaps dozens of vulnerabilities announced in any week or month can be allowed to remain open in the face of limited resources?

These are fundamental questions that every organization must answer, probably every day. One way to prioritize is to begin assessing the potential impact to the organization and the potential utility to the attacker. These two dimensions are more important than how easy or difficult a vulnerability is to exploit, although that also important information once we determine that a vulnerability is significant.

Calculating CVSS helps practitioners identify those items that warrant deeper analysis. Unfortunately, due to the way that a CVSS base score is averaged across the exploitability and the impact dimensions, CVSS in some instances fails to sufficiently assess risk, especially in cases where utility to an attacker appears to be relatively insignificant.

The McAfee PSIRT uses CVSS as a critical tool for triaging vulnerabilities and for gauging response times. Still, CVSS is no substitute for a deeper risk analysis when it is warranted.


[1] We did not have access for this analysis to an OpenSSL code graph, which would have allowed a definitive examination of calls to the vulnerable code. However, it appears from a cursory examination that the module is primarily called upon user instigation, from command-line tools, not during protocol processing.

[2] There are numerous cases of scores being inflated or deflated to fit the agenda of the scorer. How can cross-site scripting scores range from 1.8 to 9? That seems impossible, but a simple search will return that range of scores from Mitre’s CVE data.

[3] Vendors may calculate alternate scores for their products, which will be dependent upon particular vendor circumstances.

[4] One published description seems to vary considerably. The following does not seem to match our reading of the code or the behavior of a single-byte heap buffer overread:

“Successfully exploiting this issue will allow attackers to bypass security restrictions and perform unauthorized actions; this may aid in launching further attacks.”

The post Don’t Substitute CVSS for Risk: Scoring System Inflates Importance of CVE-2017-3735 appeared first on McAfee Blogs.