Sinds 1995 aanwezig, maar wanneer is het ontdekt? De titel suggereert nu dat het lek sinds 1995 misbruikt is. Is dat zo?

Beetje doorklikken op de linkjes doet wonderen.
Na 2 klikken kwam ik op https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10087
30-12-2016 ?

Nee, de titel suggereert helemaal niet dat het lek al die tijd misbruikt is geweest, alleen dat het lek aanwezig was. Je kan misbruik natuurlijk niet uitsluiten, maar als dat op een schaal van enige betekenis was gebeurd had dat meteen de kans vergroot dat het lek eerder was ontdekt. De CVE is van 30 december. Dat lijkt me een aardige indicatie van wanneer het lek ontdekt is.

Je kan niet eens uitsluiten dat de nullpointer dereference geen echte fout is. Het zijn vaak fouten die uit code reviews komen niet uit ontwerp van de logica of de functionele realisatie.
Async processing met locking is door timing een zeer lastig onderwerp.

Ik vind dit een hele grote aanname. De laatste tijd blijkt het tegenovergestelde waar.

Het woord "beveiligingslek" lijkt extreem zwaar in dit geval, want:
1) Dit "lek" (beter: deze bug) treedt niet op bij het renderen van PNG plaatjes en lijkt dus niet remote exploitable;
2) Een null-pointer dereference betekent dat een bewust aangebracht vangnet heeft gewerkt.

Een pointer is een variabele die een geheugenadres bevat (m.a.w. een pointervariabele "wijst" naar een adres). Eenvoudig gesteld: in een 32 bits computer is een pointervariabele 32 bits lang, je hebt dus 4 bytes wijzigbaar geheugen (RAM) nodig om zo'n pointerwaarde in op te kunnen slaan.

Jouw webbrowser heeft ongetwijfeld een pointer gebruikt naar de tekst die je nu leest, want die staat ergens in het geheugen van jouw computer, tablet of smartphone en is, letter voor letter, omgezet naar pixeltjes in het schermgeheugen waardoor je dit nu kunt lezen.

Het is best practice om, na gebruik, zo'n "pointer op nul te zetten" d.w.z. deze de waarde nul te geven (zodat deze "naar adres 0 wijst"). Dat doe je als programmeur omdat moderne computers zo zijn ingesteld dat de CPU een foutmelding geeft als je data vanaf adres 0 probeert te lezen of ernaar te schrijven. Die foutmelding leidt er, normaal gesproken, toe dat het programma gecontroleerd crasht.

Er kan dan sprake zijn van een lek, namelijk (debug) informatie die over de crash getoond wordt, of zelfs via internet wordt verstuurd (zie ook [1]), maar de kans dat een aanvaller daarbij kan en iets aan heeft is niet zo groot (maar ook weer niet ondenkbaar).

Het "op nul zetten" is veel veiliger dan de laatste waarde er maar in te laten zitten (of terugzetten naar het begin van deze tekst). Immers, zodra je een andere webpagina opent zal de webbrowser het geheugen voor deze tekst vrijgeven en wellicht meteen weer "alloceren" (aanvragen, en bij akkoord in gebruik nemen) voor andere tekst, plaatjes of instructies om rechthoeken te tekenen etcetera. Pointers horen dan natuurlijk weer correct geïnitialiseerd te worden (de juiste waarde te krijgen), maar soms gaat dat fout - zoals nu in libpng.

Mocht de programmeur dat (bij hergebruik opnieuw) initialiseren van zo'n pointer vergeten, dan helpt zo'n op 0 gezette pointer: het voorkomt namelijk dat het programma bytes in het geheugen verkeerd gaat interpreteren, bijv. tekst als een plaatje of andersom. En dat zijn nou net de omstandigheden waarbij veel ernstiger lekken zoals destijds heartbleed in OpenSSL maar ook remote code execution tot de mogelijkheden behoren.

Kortom, een null-pointer dereference klinkt misschien dramatisch, maar is dat zelden.

[1] https://www.security.nl/posting/498083#posting498270