Heb de patch zelf eens nagekeken. Doet precies wat gezegd wordt.

De bewuste strcat call wordt vervangen door een strncat call, met n = 160.

Ik ben ervan overtuigd Peter dat dit niet uitgebreid getest is. Waarschijnlijk hebben ze de exploit getest en daarna hooguit enkele onschuldige PDF documenten geopend.

Het is theoretisch mogelijk dat de stabiliteit van het OS ondergraven wordt door deze patch, maar hier acht ik dit zeer onwaarschijnlijk.

Vergeet niet dat jouw Adobe Reader voor het ogenblik reeds onstabiel is. Als je een PDF document opent waar de bewuste SING parameter te groot is (we spreken nog niet van een exploit), dan zullen variabelen op de stack overschreven worden en zal Adobe Reader uiteindelijk crashen.
Met de patch worden deze variabelen niet overschreven, en behoud de stack tenminste zijn integriteit. Of er verder in het uitvoeren van de code problemen zullen onstaan door deze patch, weten we niet.

Laat ons de verschillende scenarios bekijken:

- je opent een PDF zonder SING parameter -> de bewuste code wordt niet uitgevoerd. Dus geen verschil tussen origineel en patch.

- je opent een PDF met SING parameter die niet te groot is -> de bewuste code wordt uitgevoerd. Resultaat van strcat en strncat is identiek. Dus geen verschil tussen origineel en patch.

- je opent een PDF met SING parameter die te groot is -> de bewuste code wordt uitgevoerd.
Resultaat van strcat: stack variabelen overschreven -> Adobe Reader instabiel
Resultaat van strncat: stack variabelen niet overschreven -> Adobe Reader stabiel, maar wordt later mogelijks instabiel door ongekende gevolgen patch.

Dus in dit geval ben je er qua stabiliteit niet slechter af.

Persoonlijk acht ik het risico dus laag. Maar dit betekent nog niet dat het een goed idee is om deze patch in je organisatie toe te passen. Hangt ervan af hoe kostelijk dit is.
Maar voor thuis gebruik kan je dit gerust doen.

Opmerking: iemand van Adobe heeft mij ooit gezegd dat updaten een bijkomend risico van dergelijke patchen. Hij beweerde dat zulke patch het Adobe update process kan doen falen.

Ik heb niet naar de code gekeken, maar zo maar een strcat() vervangen met strncat() hoeft niet te betekenen dat het probleem opgelost is.

strncat() is een vreemde API die heel vaak verkeerd gebruikt word; het size argument is NIET de buffer size, maar het aantal bytes dat toegevoegd moet worden. strncat() schrijft ook nog een '\0' buiten deze size. Correct gebruik is dus:

strncat(dst, src, sizeof(dst) - strlen(dst) - 1);

Zonder de - 1 heb je een off-by-one. De size moet dus altijd berekent worden op basis van de al aanwezige data in dst.

strncat(dst, src, 0xa0); kan dus nog even goed een overflow veroorzaken tenzij 'dst' leeg is. Als er toevallig al een string in dst zit die heel sizeof(dst) - 1 in beslag neemt schrijf je dus bytes buiten de boundaries van dst.