 Software is like a very long chain, made of millions of links.
It’s more or less impossible to check all links individually in detail. 
Some links are weaker than others and make the whole chain vulnerable.
But they’re needles in a huge haystack.
When a vulnerability is found, it’s critical to fix it. CORRECTLY.
So, a patch is created…
Of course, you need to apply the patch to keep your software secure! But most people don’t, choosing instead the “Remind me later” option — unaware that they are leaving themselves open to security holes exploitable by malware writers.
Releasing a patch highlights weaknesses
Once the patch is available, the weak link is now highlighted: it now stands out from the millions of other links in the chain.
Whether the vulnerability is documented or not, whether the patch is documented or not, it’s possible to reverse-engineer the patch and see the changes (there are several advanced tools for that). By checking out the changes, one can determine what is actually fixed rather than what should be theoretically prevented to fail.
By looking closely where the patch was applied, it’s possible that a related and smaller vulnerability which is still not fixed might be easy to find, thanks to the information provided by the patch.
That is, when comparing the changes introduced by the patch, it’s possible to quickly find what was fixed, and by doing this discover a new vulnerability that is still not fixed. And since patches are usually released once a month, it gives a person an easier 0-day, that could stay unpatched for a complete month!
Fixing bugs is hard
We can see the difficulties of releasing a patch: it has to be done fast, reliably, but it also has to cover more than the initial descriptions or test cases.
In a previous blog entry, we looked at how crafting an Adobe Flash file made of alphanumeric characters enabled an attack on many websites. The initial Proof Of Concept only used 0-9A-Za-z characters.
It’s actually possible to make a Flash file only made of printable characters.
This is what the patched fixed: checking if the flash file is made entirely of these characters.
However, the risk is more significant than the initial PoC: with the same technique it’s easy to craft a file just by letting it finish with another character ‘(‘. Just changing this last character bypasses the filter implemented by the official patch! This new vulnerability remained unpatched for a whole month (8th July -> 12th August) !
Another CVE was assigned to this new vulnerability, which is now patched, but this shows that releasing a patch is a double-edged sword: you give the defenders a new protection layer, but you also highlight a — previously — weak area for the attackers. Fixing bugs is hard.
Here is small chronology
- 8th July: the original Rosetta Flash PoC (made only of alphanumeric characters) is public, along with the patch and announcment (CVE-2014-4671).
- The patch is not enough! Just by letting the PoC end with “(” the filter is bypassed. This is way too weak.
- 12th August: the 2nd patch is released (CVE-2014-5333).
The post Fixing bugs is hard – Rosetta Flash is back appeared first on Avira Blog.