Laat Ze ook gelijk eens dan die SPAM meuk aanpakken nu ze toch bezig zijn dan met Outlook/Hotmail beters te beveiligen.

Een gecompromiteerd certificaat is een nachtmerrie van elke software ontwikkelaar en bedrijf. (Vaak moeten ze die gecompromiteerde certificaten intrekken, en dat gaat niet altijd even soepel)
Helaas is Microsoft uberhaubt een nachtmerrie voor privacy, dus waarom politici nog steeds niet-transparante proprietaire software gebruiken is mij een raadsel, ze kunnen zelf niets eens zien wat de software doet.
Ook vreemd dat Microsoft geen airgapped systeem gebruikte, anders zou die bugreport geen certificaat bevatten.

wat Google betref die pakt het beter op..voor mij geen outlook meer...

Ik heb altijd begrepen dat bij een race conditie twee processen op elkaar gaan wachten omdat instructies niet 'atomair' (in een ononderbreekbare manier) worden uitgevoerd.

Het is goed dat Microsoft de dumps zo lang bewaart, want anders hadden ze niet eens de race conditie kunnen achterhalen lijkt mij.

Of is de crash toch veroorzaakt door een aanval van buitenaf? En staat de race kwetsbaarheid hier los van? De aanvallers waren er immers op het juiste moment bij. Code is immers altijd lek als deze groot genoeg is in omvang. Als Microsoft gaat zoeken vinden ze nog wel meer.

Klinkt als een smoes om een onderzoek te sluiten. Blijf het stuitend vinden dat mensen de club blijven vertrouwen die de hele cybersecurity wereld hun bestaansrecht geeft. Wat een bagger komt er toch iedere keer weer uit de koker van Microsoft.

Wat je omschrijft is geen race conditie maar een deadlock . (of soms een live lock)

Een race conditie is een 'race' (als in wedstrijd) waarin er een klein tijdswindow is waarin iets kan/bereikbaar is dat niet zou moeten .

Bijvoorbeeld :

proces a -
1 create /tmp/crash_dump.dbg
2 schrijf crashdata >/tmp/crash_dump.dbg
3 maak /tmp/crash_dump.dbg owned by root , read only voor alleen root.

proces b - tijdens stap 1 en 2 is die data nog wel leesbaar .
De race is tussen proces a (en het bereiken van stap 3) voordat proces b daar bij kan.

Volgens de omschrijving was hier de race tussen een proces/thread die de geheime key (en waarschijnlijk meer) moest wissen uit het geheugen _voordat_ het gedumpt werd door de crash-dumper .


Ze zullen het compromised account gevonden hebben, de data (waaronder de crashdump) waar die engineer bij kon , en in die crashdump de key .
En dan is de analyse "dat kon toch niet?" - en vinden ze de race waardoor het (soms) toch kan gebeuren.


De crashdump was van een heel geisoleerd systeem. Waarschijnlijk niet .

De aanvaller heeft geluk gehad waarschijnlijk - aan de andere kant, als je meekijkt met data waar development engineers mee werken kun je bijna zeker zijn dat er altijd wel _iets_ interessants tussen zit.
Kunnen ook zero days zijn - er zit normaal best een lange pijplijn tussen de developer die dingen aan het fixen is en de uiteindelijke release in patch tuesday. (testen, valideren, backporten naar tig versies ).

Als China dit soort zooi klaarspeelt zijn ze zeker wel een kracht die niet zomaar weggelachen moet worden.

Je moet natuurlijk geluk hebben om zo'n crashdump tegen te komen. Maar toch

De Chinezen zijn ook erg goed - of ze nu deze hack gedaan hebben of niet.
Ik denk niet dat er mensen zijn die enigszins bekend zijn in de security wereld en China weglachen.

Voor de publieke prestaties - kijkend naar winnaars van Pwn2Own zitten ook vaak Chinese security bedrijven bij.


Onder de werkdata van development engineers zit altijd wel wat interessants , kun je vanuit gaan.

Microsoft software stikt van de race conditions. Mijn tip is niet gebruiken. Elke crash is in principe een levensgroot probleem.

"Deze engineer had toegang tot de debugging omgeving waar de crash dump met de key stond. Microsoft zegt dat het geen logs heeft waaruit blijkt dat de crash dump door de betreffende aanvaller is gestolen, maar stelt dat dit de meest voor de hand liggende verklaring is hoe de aanvaller de key in handen heeft gekregen."

dit vind ik toch wel vreemd. waarom kan Microsoft dat niet zien? daar hebben ze toch allemaal Microsoft verdedigingsproducten waaronder Microsoft Sentinel voor?

Ik heb de uitleg van Microsoft nu gelezen, en ik heb alleen maar meer vragen.

Als de ontwikkelomgeving zo isolated is en niet op internet zit. Waarom zit er dan TPM op? Om te beschermen tegen collega's?

Het lijkt mij dat de computer gecrasht is en daarom er een kernel dump plaatsvond. Dan heb je geen tijd om al het geheugen nog eens te gaan sanitizen voor private keys. Als je niet snel genoeg bent met het schrijven heb je mogelijk helemaal geen controle meer over de machine en heb je geen dump (in tegenstelling tot een dump met een private key erin).

En de kernel dump is gemaild vanaf de productie machine naar een andere machine die wel op internet kan? Wat moet ik mij daarbij voorstellen?

Met de snelheid waarmee Microsoft met updates voor haar software komt, moet je sowieso bij het internet kunnen op de ontwikkelomgeving. Kennelijk heeft een programmeur daar een side channel voor gemaakt om zijn werk te kunnen doen.

Anoniem 11:19

Het kunnen intrekken van certificaten is een basisvereiste om deze op een veilige manier te kunnen gebruiken.
Als dit nog steeds niet soepel lukt, dan is is er een fundamenteel probleem met de implementatie.

TPM ?
Dat lees ik uberhaupt niet .

Er is een signing machine met signing key - die staat erg geisoleerd .
Daar crashte een proces van - en de signing key kwam in de crashdump terecht. (bug)

De crashdump werd ge-exporteerd naar de 'corporate environment' (aka normale werkplek) omgeving om de oorzaak van de crash te onderzoeken .
En die werkplek bleek gehacked waarbij de hackers dus ook bij de crashdump konden .

Waar - vanwege een andere bug (race conditie) toch de key inzat die er bij het dumpen van de data op de productie machine uitgehaald had moeten zijn.


Dat zijn design en development keuzes .
Het is helemaal nog niet gezegd dat het de kernel was die crashte - mogelijk een userproces.

Ook als het de kernel is kan het dumper (kernel) proces nog van alles doen . Je moet goed begrijpen dat die "tijd" waarin je denkt vanuit het perspectief van de gebruiker is .
In theorie (of praktijk) zou de kernel in plaats van een dump ook gewoon het hele systeem kunnen bevriezen zodat een logic analyzer aangesloten kan worden .
Uiteindelijk is een 'crash' _ook_ software die aangeroepen wordt als last resort , bij een conclusie "dit kan niet voorkomen maar we zien het toch" , en dan gaat het dump proces z'n ding doen - zoals allerlei status en registerwaarden op de console schrijven, indien mogelijk het filesysteem consistent afsluiten, en een geheugen dump schrijven.

Een user proces dat crasht wordt "gewoon" ge-core-dumped, en als het de kernel zelf is gaat ongeveer hetzelfde in werking.

Tenminste - bij Linux . Maar op hoofdlijnen zal dat hetzelfde zijn bij Windows.

Wat Microsoft doet weten we niet - maar je kunt de Linux kernel lezen (commentaar) voor keuzes en mogelijkheden bij bepaalde crashes. De developers hebben grosso modo dezelfde afwegingen.

Linus ramt er met regelmaat in de kernel crashen (bij 'onverwachte situatie') extreem ongewenst is .

Mijn interpretatie is overigens dat het een userland-proces is dat crashte op die signing server, niet de kernel.

Gezien de frase 'crashed process' . Ik zou 'snapshot of crashed system' verwachten als het een volledige systeem crash was.


Die systeem dump is dan van de erg geisoleerde productie machine overgezet (hoe ,kan van alles zijn - mail, shared filesystem, netcat ) naar een werkplek in de normale werkomgeving , waar een developer met alle debug analyse tooling - maar ook met e-mail, teams, browser etc etc aan het werk kan.

Dat is een nogal een misvatting.

De term "ontwikkelomgeving" is een schaduw/voorloper van een productie omgeving , waar kandidaat-productie ontwikkeld worden.

De "werkplek van ontwikkelaars" noem je geen "ontwikkelomgeving" . Dat zijn gewoon werkplekken - met, naast de normale mail/teams/browser etc ook "ontwikkel tools" (editor, compiler etc etc ) .
Die developers moeten net als iedereen kunnen mailen, kunnen vergaderen, en van alles kunnen opzoeken op Internet.

En hoewel ze dus (zoals ze schrijven) hard hun best doen om die werkplekken ook veilig te houden is dat moeilijker dan een geisoleerde productie server en was het hier misgegaan.

Google is heilig inderdaad: https://www.security.nl/posting/809230/Google+verhelpt+actief+aangevallen+zerodaylek+in+Android

Het is tegenwoordig niet meer de vraag wie het beter beveiligd en of je wel getroffen kunt worden, maar eerder de vraag wanneer wordt ik getroffen.

Consumenten weten niet beter of het interesseert het niet.
Het bedrijfsleven heeft zich door slaafs te volgen, zich met handen en voeten gebonden aan een gesloten software systeem.

Crashdumps zijn altijd al een gevaar geweest, ik zet het dumpen dan ook altijd uit op de Linux systemen.

Uit het artikel van Microsoft:
Dat is dus inloggen met MFA, en in de context van Microsoft dus Windows Hello. Dat de MFA op een hardware token zit en niet in de CPU, is een detail. Het doet immers hetzelfde.

Mijn vraag, als het een user proces is dat crashte, waarom kan dat user proces bij de private key waarmee toegang tot de Azure cloud van Microsoft kan worden verkregen? En waarom worden op een "ontwikkelomgeving" echte sleutels gebruikt en geen test sleutels?

Anoniem 11:19

Het was de productieomgeving die zo geïsoleerd was, de debugomgeving was dat juist niet.
Voor zover ik zie rept de uitleg van Microsoft niet over een TPM. Kan het zijn dat je in de uitleg van een race condition van de Anoniem van gisteren, 13:48 uur, "/tmp/" voor TPM aanzag? Wat je daar ziet is een verwijzing naar een directory (folder, map) voor tijdelijke bestanden op Unix/Linux-systemen.

Als daar het misverstand zit heb je de uitleg van een race-conditie vermoedelijk ook niet helemaal kunnen volgen. Bij Microsoft werd een crash dump gemaakt, een weergave van waar het proces was in de verwerking en welke gegevens op dat moment in het werkgeheugen stonden. Microsoft heeft daarvoor, schrijven ze, een voorziening die die privésleutel had moeten schonen voordat de dump naar een bestand werd geschreven. Als ze daar een race-conditie in hadden suggereert dat dat ze het schonen en het schrijven niet na elkaar maar parallel uitvoerden, waardoor het kon gebeuren dat de sleutel eerst naar een bestand werd geschreven en daarna pas werd gewist. Er was als het ware een race tussen die twee parallelle bewerkingen tussen wie het eerst bij die sleutel was, en als het opschoonproces "wint" is er niets aan de hand, maar als het schrijfproces een keer "wint" is het opschoonproces te laat en komt de sleutel in de dump terecht.

Vermoedelijk was dat niet het probleem. Meestal crasht een enkel proces, niet de hele computer, en dan kan het besturingssysteem in alle rust die dump schrijven. En als de crash wel de hele computer onderuit haalt dan lukt die dump van dat ene proces schrijven waarschijnlijk ook niet meer.

Microsoft schrijft "moved", niet "mailed". Juist in een goed geïsoleerde productieomgeving hebben ontwikkelaars alle ontwikkel- en debughulpmiddelen waar ze mee werken niet tot hun beschikking. Die crash dump werd dus overgebracht naar een omgeving waarmee ze ermee kunnen werken.

Dat had in mijn ogen nooit de normale werkomgeving van die ontwikkelaars mogen zijn. Bij signing keys heb je het over systemen die zelf maximaal geïsoleerd moeten zijn van de normale productieomgeving, hoe goed die ook is dichtgetimmerd, van waaruit niets in een minder goed geïsoleerde en beveiligde omgeving mag belanden, met als enige uitzondering de digitale objecten die met de signing key worden ondertekend, dat is nodig voor de functie ervan. Een crash dump mag dus ook niet naar een minder goed geïsoleerde en beveiligde omgeving worden overgebracht. In plaats daarvan moet men een even strikt geïsoleerde omgeving hebben waarin de crash dump onderzocht kon worden, voorzien van alle hulpmiddelen die daarvoor nodig zijn.

Het automatisch wegpoetsen van gevoelige gegevens uit een crash dump is daar geen goed alternatief voor, simpelweg omdat dat de logica daarvoor onvermijdelijk complex zal zijn, en dus moeilijk te doorgronden, waardoor er fouten in kunnen zitten die over het hoofd worden gezien, zoals ook is gebleken. Security is gebaat bij eenvoud, in de zin dat een mens moet kunnen overzien waarom het niet misgaat. Bij signing keys wil je extreme security en dat vergt extreme overzichtelijkheid, en dus moet je bij dat soort toepassingen streven naar maatregelen die zo simpel zijn dat iedere halve zool kan beredeneren waarom er niets mee mis kan gaan, ook als dat het werken omslachtiger maakt.

Er staat nergens dat er een TPM bij betrokken was, niet dat er een user-proces crashte en ook niet dat er in de debug-/ontwikkelomgeving normaal met "echte" sleutels wordt gewerkt. Azure wordt ook niet genoemd. En Microsoft heeft het niet over de ontwikkelomgeving, maar over de productieomgeving en de debugomgeving.

Het proces is gecrasht in de productieomgeving, niet in de ontwikkelomgeving. Misschien speelt hier een misverstand over wat met "productie" bedoeld wordt. Dat is niet de ontwikkelomgeving (waar software geproduceerd wordt) maar de omgeving waar die software het werk doet waarvoor die geschreven is, de operationele omgeving dus. Er staat ook dat de signing key helemaal niet in de debugomgeving had mogen belanden maar dat dat door een bug toch is gebeurd.

Ik weet nu wat beter wat een "highly isolated and restricted production environment" is. Het is niet wat OS programmeurs gebruiken om hun code te schrijven en te testen. Want daarbij moeten ze kunnen e-mailen en vergaderen. Hoe je dan een veilig OS moet bouwen?

We are doomed,
Anoniem 11:19

Uh ja - en ? Doen ze goed dan . Productie omgeving _heel_ strak afschermen , en de 'normale' corporate omgeving zo goed als nog bruikbaar is .


Je zou echt een stuk meer IT achtergrond moeten hebben , want je blijft dingen door elkaar halen. - laat dan tenminste de ondertoon weg die insinueert dat je allerlei problemen en inconsistenties denkt te zien.

User/userland proces is de tegenstelling van kernel land .

"apache" of "nginx" is ook een "user" proces , en kan heeft typisch de private SSL keys .
'pgp' is ook een 'user' proces, en als het coredumpt zijn er private keys te zien.

Waarschijnlijk was het juist het 'signing' proces of een component ervan dat gecrashed was . Gek veel anders zal er niet op die signing productie machine gedraaid hebben.

De machine met een crash was productie . Dus met productie-sleutels .
Die kwamen -onbedoeld - mee met de crashdump toen de oorzaak van de crash uitgezocht werd door de developers in de werkomgeving van de developers.

Het Is Niet Zo Moeilijk.

Mijn punt is dat PGP (dat als user draait) niet de private key hoeft te weten. Het moet alleen data kunnen aanbieden aan een routine die ondertekent en dat teruglevert.

Sure, met PGP 2.x was dat niet zo. PGP 2.x kon bij het hele adresseerbare geheugen van de PC in MS-DOS. Dat was ook wel leuk, maar niet erg veilig.

In de kernel is de private key veilig. Je moet alleen een API aanbieden vanuit de kernel naar de user. Of een driver. Ik geloof dat Windows Security (de virusscanner van Windows 10/11) ook zo werkt. De interface draait als user en praat met de kernel die het echte scanwerk doet. Anders zou de virusscanner van Windows adminrechten moeten hebben om overal te kunnen scannen. ClamAV draait ook normaal niet als root. Dat zou een risico zijn als malware de userinterface over neemt.

Mijn kennis houdt een beetje op na de 8086 processor. Heb overwogen een boek over assembly te kopen voor nieuwere processors, maar die waren f***ing dik en na een jaar obsolete. Ik heb wel boekjes van de PDP-11 en de Alpha processor. Ben ik nooit aan toegekomen en het is ook ingeruild voor Intel allemaal. Helaas. De Alpha was superieur aan Intel.

Microsoft heeft zelfs complete fonts in de kernel ondergebracht. Waarom zouden een paar private keys daar niet kunnen staan?

Anoniem 11:19

Je hebt echt geen punt.

Als je met PGP aan het decrypten bent WEET het de private key . Duh Duh Duh . Want die heeft het zelf moeten maken/lezen uit de keyring.
En als je aan het encrypten bent WEET het de (symmetrische) key waar het dat mee doet . Duh.

Dat is echt hoe PGP (moet het blijkbaar uitspellen : pretty good privacy , dat public key encryptie programma ) werkt.
Er was geen _andere_ routine waar PGP mutually untrusted data door liet verwerken.


Heeft niks met adresseerbaar geheugen te maken - alle code was van hetzelfde proces .


Voor normale userland functies biedt de kernel geen 'encryptie' API aan .
Of het nou PGP, encrypted zip of een webserver is - al het werk wordt door 'het' userland proces gedaan.
En daar is heel veel voor te zeggen - dingen X509 parsing wil je echt niet in kernel space doen .

Een kernel _kan_ bv symmetrische encryptie doen , voor een filesystem . Of voor (sommige) VPN protocollen.
Maar typisch zit allerlei handshake zaken in userland.

Ik geloof trouwens echt niet dat onder windows 'de' AV scanning door de kernel gedaan wordt. No way .
Die is er om files te lezen.

Als ClamAV niet als root draait kan het alleen files lezen die 't gegeven wordt . Ook een manier.



De Alpha was een tijdje erg hip, maar heeft uiteindelijk teveel shit die hardware _veel_ beter kan oplossen op het bord van de software geschoven.
Daar kun je zo af en toe ook Linus Torvalds nog over horen/lezen - Alpha's memory-consistentie model is het meest 'zwakke' van alle CPUs en dat is echt een fundamenteel probleem dat heel veel werk op low-level niveau geeft.
https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt
Alpha's (oorspronkelijke) keuze om geen byte-access (8 en16 bit) te bieden was ook , achteraf , verkeerd.

We begonnen het verhaal met een race conditie - Alpha's gebrek aan garanties met betrekking tot memory ordering maakt op dat niveau race condities _ontzettend_ makkelijk .

Iets moet die keys erin zetten .
En het excuus van een toch al bloated kernel gebruiken voor nog meer bloat is niet geweldig .

Dingen als certificaat parsing horen echt niet in een kernel - groot en complex - , en public key processing ook niet .
IPSec doet dat deel in een userland proces (IKEv2) .

Maar ben je nu degene die klaagde dat DOS PGP bij het hele geheugen kon, en als alternatief voorstelt om de zaak in kernel space te draaien die OOK bij het hele geheugen kan ?

Dat is echter precies hoe een smartcard werkt in PGP. Of TPM in Windows. Het enige wat ik voorstel is om het in kernel geheugen te doen in plaats van in 'userspace'.

Ik ben me gaan verdiepen in GnuPG. En het is redelijk slecht gedocumenteerd. Er was echter een functie voor secure memory in GnuPG. Dit voorkwam dat private keys in de swapfile terecht kwamen. Een kernel kan bij een geheugenpagina gewoon zetten 'do not swap'. Bijvoorbeeld omdat het de code betreft om de geheugenpagina terug te halen. https://www.gnupg.org/faq/gnupg-faq.html#insecure_memory


Ik heb games gecrackt in MS-DOS. En je kan echt overal bij. Tot het BIOS aan toe.
Je kan ook overal schrijven in MS-DOS. Segment aanpassen, Offset aanpassen. Overal bij.


Als Microsoft Defender geheel in userspace draait, dan kan het nooit en te nimmer een rootkit vinden. Ook Malwarebytes en HitmanPro, die ik wekelijks gebruik, vragen elke scan om een UAC bevestiging.


Daarvoor was het ook RISC (reduced instruction set computing). En Intel is allemaal CISC (waar Linus ook over klaagt als het over 512 bit vector berekeningen gaat). AVX-512 is een extreme uitwas van CISC. En de transistors van AVX-512 zitten ook niets te doen als je andere instructies aan het gebruiken bent.


Je moet het goed testen voor je het in de kernel stopt. Want het kan je hele computer BSOD-en als er een fout in zit. Dit gebeurt bijvoorbeeld veelvuldig met videokaart drivers. Die pas echt gigantisch zijn.

Anoniem 11:19

Shifting goalposts , als je over PGP praat opeens "maar met een smartcard" introduceren.

En waar een smartcard tenminste persistent is - een kernel moet bij ieder gebruik van 'een' key voorzien worden.

Je bent echt NIKS aan het oplossen qua security door een key in de kernel te duwen.

Dit soort amateur "redesign" is echt 'een gek kan meer neuzelen dan tien wijzen kunnen beantwoorden" .


Het programma doet z'n best om geen 'lange' exposure van de keys mogelijk te maken op die manier omdat een swap file lang bewaard blijft.
Sommige software doet ook nog z'n best om keys in het geheugen te wissen direct na gebruik .

Maar goed - actief in gebruik, keys zijn beschikbaar.



Dat is zo, maar zegt verder niks . Net zoals gnupg alles van zichzelf kan zien.



Dat volgt niet . low-level access is niet hetzelfde als 'scanning engine draait in kernel mode' .

Je snapt er echt veel te weinig van
Power, MIPS, ARM, RiscV - ook risc, deden en doen NIET fout wat Alpha fout deed.

Verder zijn floating point of vector instructies (Cray 1 ...) helemaal geen "definitie van CISC" -
memory ordering consistentie is niet wat 'risc risc maakt' - het overgrote deel van de CPUs deed dat beter dan Alpha.

Linus is geen fan van AVX512 inderdaad , maar dat heeft niet veel met 'cisc' te maken - wel met de niet-universele beschikbaarheid van de instructies, de overgrote beslag op cache/stack bij gebruik en meer van die dingen.

Als je wat meer lees/weet over computer architectuur moet je realiseren dat het fanboy narratief 'risc good and fast, cisc slow old bad' gewoon echt niet (of niet meer) klopt.

En dat wat er overblijft aan design criteria en design constraints waar computer architecten mee werken niet zo simpel samen te vatten is.



Je moet het dus NIET doen als het niet echt nodig is.
Je wint er gewoon niks mee.

Daar zijn passphrases voor. Na het booten van de certificate server van Azure vraagt die om een passphrase waarmee de opgeslagen private key gelezen kan worden. Deze staat in kernel memory zodat geen enkel user proces erbij kan. Maximale beveiliging. Stroom eraf, sleutel ontoegankelijk. Zelfs het invoeren van de passphrase kan buiten userspace om.

Ik heb PGP sleutels uitgeprint met een goed wachtwoord erop zodat ik nooit de toegang tot die sleutel kwijt kan raken. Ik weet alleen niet meer waar ik de print neergelegd heb :-p Gelukkig zit er een goed wachtwoord op dus het maakt ook niet uit.

Anoniem 11:19