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!
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