Often, only the more ubiquitous vulnerabilities with higher severity scores make the news or are talked about broadly. But many times, the less severe vulnerabilities can wreak havoc on development teams by undermining trust in the way data is accessed and handled. This is true of CVE-2017-5647, an information disclosure vulnerability that on the surface might appear less threatening, but can potentially expose sensitive data not meant for the users who can inadvertently (or deliberately) access it.
We chose this older vulnerability to showcase this month because of the prominence score and ease of accidental exploit.
In this case, the vulnerable component is buried where developers might not think to check for it; it is contained within the application container functionality serving the business content. Even if the development team isn’t using Apache Tomcat, this vulnerability could still rear its ugly head.
Name of the Vuln/Sonatype ID: CVE-2017-5647
Type of vulnerability: Information exposure
Prominence Across Ecosystems Number (PAE):
For the past 30 days - 60% of the components in use are known to be vulnerable
Apache Tomcat is vulnerable to Information Disclosure, as it sends the response of a "send file" request (request "A") in response to another request (request "B") that is in the pipeline when the processing of the previous request is completed.
The Attack Mechanics:
This seems like a simple case of object reuse and not adequately updating the reused object prior to handling subsequent requests. And while it is a very simple mistake to make in development, it can have disastrous consequences.
Let’s look at how this plays out in a real world scenario.
Let’s say you are an HR VP running a report for all employee pay information. After you type in your credentials and the request is processed, the result you get back matches what you expected. Now, let’s say your employee, Joe, sends a request for just his pay information and his request is next in the queue. If you are using a vulnerable component, Joe would end up getting the list of all employee pay information, instead of just his own. In other words, the data returned would be from the previous request, yours.
Not a good result for all involved. And, what if this instance is not an isolated case? How many more employees are seeing information they shouldn’t be? Perhaps it’s another employee attempting to access his pay statement information and getting pay statement information for the CEO.
While the above scenario is an inadvertent exposure of information, the attacker would use the same approach collecting most of the data accessed in normal use.
A common coding error when handling web requests is object reuse and this vulnerability is a fine example of object reuse gone wrong. This scenario assumes the sendfile functionality as used when APR or NIO is enabled is being used to service the requests.
Tomcat is reusing a socket depending on the keepalive state:
The VP’s request is received by the application and the connection is kept alive until the processing of the file requested is completed.
The employee makes a request while the VP’s request is being fulfilled and tomcat handles this as a pipelined request on the same socket.
Once the first request has been processed and the response sent back to the VP, it is time to process the pipelined request on the same socket. However, code does not exist to actually process the pipelined request, and thus the response object is not updated since the first request was processed and is returned to the employee containing the same data that was sent to the VP.
This results in the employee now having “timed” access to VP files being viewed. The VP got the response that he expected and is none the wiser.
To fix this, a new case to handle pipelined requests was included.
Why does it matter?
The user making the pipelined request could inadvertently or deliberately get back data they are not supposed to see. If you are using this popular application server component with APR or NIO enabled, you could be putting your sensitive data at risk.
What is the best remediation path?
Check your systems and verify whether or not you have this component in use with APR or NIO enabled and if the system is protecting sensitive information. If you are in either case, particularly if you are using it to protect sensitive data, upgrade to a component not impacted by the vulnerability or shut this feature off.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2017-5647 within days of the discovery. Their development teams automatically received step-by-step instructions to remediate the risk.
If you're not a Sonatype customer, and want to quickly find out if you're using the vulnerable version of Apache Tomcat in a specific application, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.