Flash 0-Day: Deciphering CVEs and Understanding Patches

Published: 2015-01-23
Last Updated: 2015-01-25 02:30:43 UTC
by Johannes Ullrich (Version: 1)
9 comment(s)

(updated with Jan 24th update)

The last two weeks, we so far had two different Adobe advisories (one regularly scheduled, and one "out of band"), and three new vulnerabilities. I would like to help our readers deciphering some of the CVEs and patches that you may have seen.

CVE Fixed in Flash Version  Currently Used in Attacks Advisory
CVE-2014-8440 (Nov. 2014) yes APSB14-24
several (mid Jan 2015) yes. APSB15-01
CVE-2015-0310 (late Jan 2015) yes APSB15-02
CVE-2015-0311 (Jan 24th 2015) yes APSA15-01

So in short: There is still one unpatched Flash vulnerability. System running Windows 8 or below with Firefox or Internet Explorer are vulnerable. You are not vulnerable if you are running Windows 8.1 and the vulnerability is not exposed via Chrome. EMET appears to help, so may other tools like Malwarebytes Anti-Exploit.

Johannes B. Ullrich, Ph.D.

Keywords: flash
9 comment(s)

Infocon change to yellow for Adobe Flash issues

Published: 2015-01-23
Last Updated: 2015-01-23 18:05:08 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)

We have decided to change the Infocon 1 to yellow in order to bring attention to the multiple recent Adobe Flash Player vulnerabilities 2 that are being actively exploited. There have been 3 patched vulnerabilities that have an update and applying them is highly recommended. 1 of the vulnerabilities has not yet been patched, and is expected to be released as an OOB (Out of Band) next week by Adobe 3

Our reasoning is that the Adobe Flash Player is very widely installed, the vulnerability affects multiple platforms, remote code execution gives the attacker complete control of the system, the patch is not yet available, it affects both organizational IT systems as well as home or soho users, a crimeware kit is actively exploiting the vulnerabilities, people might mistakenly believe that the patch from yesterday fixes all of the issues, and last but not least mitigation through the use of EMET or other tools/means is not normally feasible for home users or quick deployment in enterprise environments without testing. In short, the high impact of these vulnerabilities being exploited warrants raising the Infocon from now until Monday. 

1- https://isc.sans.edu/infocon.html

2- https://isc.sans.edu/forums/diary/Flash+0Day+Deciphering+CVEs+and+Understanding+Patches/19223/

3- http://helpx.adobe.com/security/products/flash-player/apsa15-01.html

Adrien de Beaupré
Intru-shun.ca Inc.
My SANS teaching schedule

0 comment(s)
PHP 5.6.5 is available

How Vulnerabilities Happen: Input Validation Problems

Published: 2015-01-23
Last Updated: 2015-01-23 13:29:27 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

We would like to thank Richard Ackroyd of RandomStorm for reporting a critical input validation error in our site to us. As we have done before, here is how it happened so hopefully you can learn from it as well.

Lets start with a bit of background. Our site deals a lot with IPv4 addresses. Most of the time, we store IPv4 addresses as a string. I know this isn't the most efficient way, but well, that decision goes back to "the beginning". To make sorting and indexing simpler, we "pad" IPv4 addresses with zeros, and you may have seen this on the site. becomes

Originally, I used a simple trick to validate IP addresses. I just converted the IP address to its long integer format, and then back to a string. This guarantees that you end up with a valid IP address. Later, we started using more of the standard "FILTER" functions in php to make some input validation easier, and modified the IPv4 validation function to use it. At the same time, to make the code a bit simpler,  we also added an "unpad" function to fix up the IP address by removing extra 0s first.

Here is a quick view at the vulnerable code:

if  ( is_ipv4($sIPAddress) {
   ... use $sIPAddress ...
} else {
   ... display error ...

function is_ipv4($sValue) {
   if ( filter_var($sValue,FILTER_VALIDATE_IP,FILTER_FLAG_IPV4) ) {
      return $sValue;

function unpadip($sIP) {
    if ( sizeof($aIP)<4) return false;
    return sprintf("%d.%d.%d.%d",$aIP[0],$aIP[1],$aIP[2],$aIP[3]);

So why is this wrong? The big problem is that I am modifying the value (unpad) before validating it, and then use the unmodified value, not the one I modified. At first, that doesn't look too bad in this case. But turns out that the "unpad" function does more then just remove extra 0s. Any other non-numeric character is removed. E.g. try:

printf("%d","123 this is an exploit");

and you will get "123" back. That is part of the point of %d. The end result was that we validated a value that was cleansed by "unpad", but then used the "dirty" value which still included the exploit code.

Our solution for now is twofold:

- add a bit more input validation to the unpad function, just in case we use it unsafely in other parts of the code
- remove the unpad from the is_ipv4 validation function. 

The ultimate solution would be to change how we store IPv4 addresses and store them as long integer, which is much more efficient, but will take some time as we got a lot of code that needs to read/write from those tables. For IPv6 we use two 64 bit numbers ("BIGINT" in mysql) which works very well as it splits network and interface part.


Johannes B. Ullrich, Ph.D.

0 comment(s)
ISC StormCast for Friday, January 23rd 2015 http://isc.sans.edu/podcastdetail.html?id=4325


Diary Archives