Wednesday, January 28, 2015

The last two days have been taken up with the glibc ghost vulnerability found by Qualys. They have a good description and a good detailed analysis.
Essentially this is the old "parsing untrusted input" problem -- a value comes in from a dubious source and the code needs to be robust against an attacker who can choose arbitrary malicious input.

Vulnerabilities like this are hard to classify. It's almost certainly exploitable by someone who has a local account on a box. But determining if it is remotely exploitable is difficult. This is what is called the "cone of uncertainty"; it takes time to do the research and find out if any code paths are directly vulnerable. Starting at the vulnerable gethostbyname() functions and working out is time consuming.
Many times this week I have wished for a rough equivalent to perl's taint checking -- let me flag a piece of memory as "tainted", and allow me follow it through the system to an arbitrary function call.

Since vulnerability classification is the first step in determining actions, use attack modeling techniques to determine exploit vectors. Enumerate all the ways untrusted input can make it through the system. For example, an attacker may be able to input an IP address into a field in a web app. In this case, an IP address text field could trigger the vulnerability.
Once all vectors are enumerated, determine if mitigations are in place. In the case of ghost, only 1024 or longer inputs may be vulnerable. When that work is done, there should be fewer code paths to analyze.

As Qualys proved, there are many possible attack vectors. If they cannot all be analyzed in a short amount of time, then prepare for the worst case.
Weigh the risks before deciding a plan of action. Often the fix for a new vulnerability is not immediately available and issuing an incomplete fix is worse than taking a few extra days to publish the correct fix.
In this particular scenario, the risk of patching glibc is relatively small -- the code has been patched since 2013 and there is a definitive test case that can be run easily. It is prudent to issue a patch as soon as possible.
Given the classifications published earlier, ghost would qualify as a severe vulnerability. Actions should be dictated by established policy.

Thursday, January 15, 2015

To reduce the time to develop products, many software shops include third party source — often open source — into their product. This is a liability when the source has vulnerabilities.

Step One: Set up a license review board. Before including third party source, consider how it will be used and the license. Since many licenses prohibit certain behavior, a license approval board should decide what licenses are acceptable and under what conditions.

Step Two: Set up an inclusion review board. Practice good risk management before including the source. Identify risk attributes and assign a score before inclusion. Quantify the risk by investigating and ranking these factors:

History of vulnerabilities. If a project had a high number of vulnerabilities in the past year, it has high risk. OpenSSL had 21 vulnerabilities in 2014.

Project maturity. Code that is abandoned by it’s authors carries high risk. If some technology or code is already stale, it is high risk. Even if it is a hot piece of technology, it may be still be abandoned in favor of other technologies. Mature and stable projects will have lower risk.

Ownership. If a team wants to include third party source but will not maintain it, it has high risk.

Exposure. If the source exposes an external interface, it has more risk.

For example, apache has high exposure, but relatively low risk because of it’s maturity and recent history of vulnerabilities. Third party libraries used to parse untrusted input, e.g. XML or JSON parsers, may have high exposure and high risk due to recent vulnerabilities.

Step Three: Track third party software in use. Appoint an owner and a backup to watch for security updates from each third party package. The build process can be used to track third party source and create tickets to upgrade software. If there is an upstream OS vendor, consider using their updates.

Step Four: Have a maintenance strategy. Consider how source will be maintained and updated by the owners. Consider purchasing an update service from a vendor. If an upstream vendor does not cover the desired packages, consider automating updates from upstream source repositories.

Also consider running security tests aimed specifically at functionality exposed by the third party source. Report the findings back to the vendor or open source project.

Step Four: When there is a vulnerability, assign severity and follow process to update it. Third party source should be treated no differently from proprietary source when there are vulnerabilities.

Following the above steps is an effective risk management process for third party source.

To reduce exposure, limit the software’s threat surface. Limit the number of services exposed externally, use a firewall, and ensure that untrusted user input goes through a trusted and secured code path.

It’s hard to reduce all exploitability vectors since attacks only get better and future attack methods can’t be reliably predicted. Host-based intrusion protection such as SELinux, stack protection, and ASLR work reliably but take diligence and effort to ensure they are always enabled and kept up to date.

Finally, consider exposure when assigning vulnerability severity. Often a vulnerability has severe consequences but can be mitigated by disabling a service or feature. Calculate the CVSSv2 score for different scenarios and consider how best to mitigate a vulnerability.

Monday, January 5, 2015

The two previous articles covered vulnerability tracking and secure development. This article will dive deeper into the final phase of the secure development lifecycle — vulnerability response. Responding well to vulnerabilities is a sign of a mature development shop.

The primary objective is to keep all customers as safe as possible. Update software and communicate mitigation information to customers to keep them safe.

Step One: Assign a severity to each vulnerability

See the earlier article on tracking vulnerabilities for example severities. When a vulnerability is critical, a response is required. Often, the cone of uncertainty for a vulnerability will linger for days with new information surfacing regularly. For example, Shellshock contained 6 CVE identifiers spread out over about 5 days. A dedicated team needs to continuously analyze vulnerabilities and watch for new information.

Step Two: Follow process and decide when to update

To keep all customers safe, coordinate the release of software patches so all customers have an upgrade path. Release any mitigation details at the same time as the software patch.

If the vulnerability is in third party source, there may be no pre-arranged coordination. Heartbleed and Shellshock are two examples of third party source that required immediate attention.

Step Three: Update

Release the update to customers.

Step Four: Communicate

Communicate to customers the severity of the issue and give them mitigation strategies if they cannot update immediately. Do not release details that will tell attackers how to attack the vulnerability. Be forthcoming about the vulnerability, do not hide information. Customers would rather patch than be hacked because of a vulnerability that was not well communicated. Finally, use CVE numbers and update CVE/NVD with the details so that customers can find information.

ISO 30111 deals directly with vulnerability response and can be consulted for more information.

Following these steps and rigorously analyzing vulnerabilities will greatly improve your organization’s response to vulnerabilities.