Helaas legt Microsoft niet precies uit om welke bestanden het gaat (onderstrepen door mij toegevoegd om te accentueren): Het gaat dus om een deel van de door Microsoft in de periode 12 juli en 14 augustus digitaal ondertekende bestanden.

Het is onduidelijk of het daarbij alleen om de update "container" bestanden zelf (zoals MS12-053) gaat, of ook om de feitelijke bestanden die door zo'n update worden geïnstalleerd (vaak een hele reeks DLL's, soms exe-bestanden en drivers). Maar ook bij andere bestanden die Microsoft in die periode heeft gepubliceerd (muisdrivers, Fix-It's etc.), zou deze fout kunnen zitten.

Daarnaast is onduidelijk welke fout er precies gemaakt is: Met andere woorden, het timestamping certificaat is defect waardoor de timestamp geen toegevoegde waarde heeft. Echter, waarom niet, wordt niet verder uitgelegd dan "certificate used for timestamping was missing a critical attribute".

Ik weet niet hoe je dat laatste moet lezen. Certificaten bevatten extensies die je als "critical" kunt (of moet) "taggen". In mijn reacties onder https://isc.sans.edu/diary.html?storyid=14272 ging ik er nog vanuit dat het om timestamping certificaten zou gaan met daarin een relevante extensie is die, onbedoeld, niet als "critical" getagged is.

Voor de hand ligt dat het daarbij om de Extended Key Usage extensie zou gaan (zie https://tools.ietf.org/html/rfc5280#section-4.2.1.12), want daarmee geef je aan dat het certificaat voor time-stamping bedoeld is of juist niet. Echter, de Extended Key Usage extensie in nieuwe Microsoft time-stamping certificaten is ook niet als "critical" getagged!

Wat er exact mis was met de betreffende certificaten is te lezen in de FAQ sectie van https://technet.microsoft.com/en-us/security/advisory/2749655:Griezelige workaround: Microsoft heeft dus twee defecte certificaten ontdekt, maar sluit kennelijk niet uit dat er meer zijn.

Wat Microsoft doet door KB2749655 uit te brengen, is best griezelig (zie https://technet.microsoft.com/en-us/security/advisory/2749655). Door deze update te installeren zullen twee defecte timestamping certificaten als correct worden behandeld (we kunnen alleen maar hopen dat Microsoft met dit lapmiddel geen nieuwe kwetsbaarheden introduceert).

Zelf heb ik deze update bewust niet geïnstalleerd omdat ik wil zien wat er misgaat (op een productiesysteem kun je je dat wellicht niet permitteren). In elk geval vind ik het een slechte zaak dat Microsoft ons een ordinair lapmiddel laat installeren - notabene in een onderdeel van Windows dat alles met vertrouwen te maken heeft.

Geen best practices
Daarnaast constateer ik dat Microsoft zich bij haar nieuwe timestamping certificaten ook niet aan best practices houdt. Zo is het raadzaam om een extensie genaamd "Basic Constraints" in elk certificaat op te nemen en deze als "critical" te taggen (dat wil zeggen dat deze extensie gehonoreerd moet worden). Die "Basic Constraints" bevat een vlag die aangeeft of het een "End entity" certificaat of een "CA" certificaat betreft. Met een CA certificaat kun je sub-certificaten maken, met een End entity certificaat niet.

Aangezien een timestamping certificaat een "End entity" certificaat is, kun je simpel verhinderen dat deze ooit misbruikt wordt als CA certificaat (t.g.v. diefstal van de bijbehorende private key of het brute-forcen ervan) door genoemde extensie erin op te nemen.

Ten slotte is ook in de nieuwe time-stamping certificaten de extensie "Extended Key Usage", die aangeeft dat het certificaat bedoeld is voor time-stamping, niet als critical getagged. Daardoor is dit feitelijk niet meer dan een suggestie (die genegeerd mag worden).

In het licht van de door Microsoft in juni ingetrokken certificaten die Flame voor andere doeleinden kon misbruiken dan waar Microsoft ze oorspronkelijk voor had bedoeld (zie https://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx) vind ik dit onbegrijpelijk!

@Miriam4711: je hebt gelijk!

Echter PKI is -helaas- complex; softwaremakers zullen dit echter moeten begrijpen willen we de zaak veilig houden.

Uitleg voor eindgebruikers
Als een uitvoerbaar bestand (zoals een Windows Update bestand) door Microsoft van een digitale handtekening is voorzien, weet het updateproces op jouw PC dat het bestand echt van Microsoft afkomstig is en dat er, na het zetten van die handtekening, niets in de uitvoerbare code gewijzigd kan zijn (door eventuele aanvallers).

Je kunt een digitale handtekening vergelijken met dat de ondertekenaar een pen heeft met unieke inkt (denk aan specifiek DNA materiaal of zo) die in de praktijk erg moeilijk is na te maken. Bij het bestand krijg je een certificaat meegeleverd en een chemisch goedje. In het certificaat wordt aangetoond dat het chemische goedje van Microsoft is (ook weer met een digitale handtekening trouwens). Als je het chemische goedje op de handtekening onderaan het bestand sprenkelt, wordt die handtekening uitsluitend groen als het het om de geheime inkt van Microsoft gaat, anders wordt de handtekening rood. Met de combinatie van het (vrij beschikbare) certificaat en het chemische goedje wordt dus aangetoond dat het bestand ondertekend moet zijn door Microsoft.

Het voert hier te ver om uit te leggen hoe wordt aangetoond dat de uitvoerbare code in het bestand boven de handtekening niet gewijzigd is, da's een erg technisch verhaal (Google naar "secure hash").

Geldigheidsduur
Probeem: zo'n handtekening maar korte tijd geldig, dat kan zelfs maar enkele maanden zijn. De reden voor die korte looptijd is dat het, na verloop van tijd, steeds aannemelijker wordt dat een aanvaller die handtekening kan namaken (zeg maar de inkt weet te na te maken of zelfs wat inkt weet te stelen). Als je na die verloopdatum zo'n update probeert te installeren, weigert Windows dat.

Om die reden heeft Microsoft een truc bedacht, genaamd "Authenticode". Microsoft voegt aan het bestand met handtekening nog een handtekening toe, alleen zit daarin een "timestamp" (datum en tijd stempel), d.w.z. het exacte moment van ondertekenen. Die timestamp wordt bij een superbetrouwbare server opgevraagd.

De redenering is vervolgens dat, in elk geval op het moment dat het bestand ondertekend werd, die handtekening geldig was. Dit voorkomt dat een aanvaller, die ondertussen de inkt heeft weten na te maken (of heeft weten te stelen), op zijn PC de datum flink terugdraait en onder zijn bestand een "geldige" Microsoft handtekening kan zetten.

Die extra handtekening met betrouwbare timestamp vormt een extra hindernis voor aanvallers. Om die reden stelt Microsoft dat je een feitelijk verlopen handtekening toch als geldig mag blijven beschouwen als je redelijk zeker weet wanneer die handtekening gezet is!

Wat is er nu aan de hand
Microsoft heeft op een deel van de bestanden die ze digitaal ondertekent, defecte aanvullende timestamp-handtekeningen gezet. Die werken daardoor niet. het gevolg is dat de feitelijke handtekening onder het bestand ongeldig wordt op het moment dat die verloopt. Bij sommige bestanden is dat al deze maand of november.

Het gevolg is dat die updates bestanden op je schijf hebben gezet waarvan de handtekening binnenkort niet meer geldig is, wat tot allerlei foutmeldingen kan leiden.

Hoe repareert Microsoft dit
Via twee wegen:

(1) Microsoft heeft aangegeven de updates die een defecte tinestamp handtekening hebben, opnieuw uit te brengen, maar dan met correcte handtekeningen natuurlijk. Alleen lijken deze tot nu toe nog NIET automatisch via Windows Update/Microsoft Update te worden gedistribueerd (je kunt ze wel handmatig downloaden). Waarom niet heb ik nog nergens gelezen op de Microsoft website.

(2) Eén van de updates deze maand (KB2749655) is een lapmiddel dat ervoor zorgt dat de defecte timestamp handtekeningen toch geldig worden verklaard. Als je die update installeert zul je geen problemen ondervinden, en hoef je de oude, opnieuw uitgegeven updates, ook niet te installeren.

Vooral als je (2) geïnstalleerd heb, zul je waarschijnlijk geen problemen ondervinden.