Microsoft dicht 111 kwetsbaarheden tijdens Patch Tuesday

Microsoft heeft tijdens de maandelijkse Patch Tuesday 111 lekken gedicht in Windows en andere software. In 13 gevallen gaat het om lekken die als 'kritiek' worden aangemerkt. Het is de derde maand op rij dat Microsoft meer dan 110 lekken in het besturingssysteem repareert.

In tegenstelling tot eerdere maanden zitten er in de huidige Patch Tuesday geen actief misbruikte zerodays. Dat was in april nog wel het geval. In totaal heeft Microsoft 111 kwetsbaarheden verholpen in Windows 10 en Windows Server, maar ook in eigen softwarepakketten zoals Edge en het .Net-framework.

Van de 111 kwetsbaarheden merkt Microsoft er 13 aan als 'Kritiek'. 91 kwetsbaarheden zijn 'Belangrijk', 3 zijn 'Moderate' en 4 hebben een 'Low'-prioriteit. 3 van de kritieke kwetsbaarheden zitten in Microsoft Edge. Met CVE-2020-1056, CVE-1059 en CVE-2020-1096 zijn respectievelijk privilege escalations, spoofing en remote code executions mogelijk door gebruikers op een geïnfecteerde link te laten klikken.

Er zitten daarnaast drie remote code executions in SharePoint: CVE-2020-1023, CVE-2020-1024 en CVE-2020-1102. Ook zit de remote code execution met CVE-2020-1067 in Windows zelf.

Reacties (67)

[Verwijderd]

Iemand enig idee of Windows steeds verder gaat op de huidige code?
Of worden er ook stukken helemaal opnieuw geschreven? Want uitbreiding van huidige code levert vaak toch slechtere kwaliteit, dan wanneer hier vanaf het begin rekening mee werd gehouden.

[P_Tingen]

Opnieuw schrijven is een idee dat vaak opkomt bij oudere applicaties (en ook bij operating systems denk ik) maar is zelden een goede oplossing. In de code zit jaren en jaren aan kennis. Lees voor de aardigheid maar deze post van Joel Spolsky, die ondanks van ruim 20 jaar geleden nog steeds actueel is:
https://www.joelonsoftwar...u-should-never-do-part-i/

[RobIII]

Want uitbreiding van huidige code levert vaak toch slechtere kwaliteit, dan wanneer hier vanaf het begin rekening mee werd gehouden.

Dat is nogal een brede uitspraak die lang niet altijd op hoeft te gaan. Soms is een rewrite van bepaalde delen prima te verdedigen en levert het een kwalitatief beter resultaat. Soms niet.

Iemand enig idee of Windows steeds verder gaat op de huidige code?

Ja, (natuurlijk) schrijven ze windows niet elke keer opnieuw. Er zitten nog flarden MS-DOS en Windows 3 in Windows 10.

[Reactie gewijzigd door RobIII op 22 juli 2024 14:45]

[Alfa1970]

Er zitten nog flarden MS-DOS en Windows 3 in Windows 10.

Ik denk dat je er toch een beetje naast zit. Windows 10 is een afstammeling van Windows NT.
Niet van DOS, Windows 3, 95, 98 en ME. Het lijkt in niets op die oudere OS'en en er zitten ook geen flarden van die OS'en in Windows 10.

[RobIII]

Ik weet donders goed waar ik 't over heb en dat Windows 10 afstamt van NT. Maar dat betekent niet dat er geen resten code van oudere OS'en in (kunnen) zitten. Dat kan een enkele regel code zijn, dat kunnen complete functies zijn. Maar (flarden, zoals ik zei) code delen ze wel degelijk. Wat jij bedoelt is dat NT niet meer afhankelijk is van MS-DOS en/of een MS-DOS meer bevat. Of dat bepaalde DLL's, executable of whatever niet meer in Windows 10 zitten die er vroeger wel in zaten. Dat klopt. Maar dat neemt niet weg dat er stukken code 'geleend' / 'meegenomen' / 'gejat' / 'ge-copy/paste' zijn en al die jaren meegenomen naar afstammelingen. Er duiken soms nog steeds 30, 40 jaar oude bugs op in recente(re) versies van Windows; en dat is bij Linux en andere OS'en niet heel anders.

Lees maar eens een paar avondjes The Old New Thing (Raymond Chen is een held ) en je zult zien hoeveel legacy MS meezeult (en dat is niet altijd negatief, mocht 't zo klinken).

[Reactie gewijzigd door RobIII op 22 juli 2024 14:45]

[ReneX]

Volgens mij (althans zo lees ik het) bedoelt hij toch echt dat er geen resten van de code van MS-DOS en Windows 3/95/98/ME in zitten.
Van 95/98/ME is dat niet onlogisch aangezien die na Windows NT kwamen. En MS-DOS en Windows 3 code .. tja ... als daar al iets van meegenomen is dan was het hooguit code om Windows 3.1 programma's compatibel te houden (in de WoW hoek). Maar dat zou ik even na moeten kijken.
In ieder geval niets cruciaal als bv een protocol stack oid.

Dus nee ik zou dit niet wil betitelen alsof er flarden in zitten die je nog steeds gebruikt.
(En anders is een bron altijd welkom )

[Reactie gewijzigd door ReneX op 22 juli 2024 14:45]

[RobIII]

Je bent ontzettend naïef als je denkt dat ze bij Windows NT met een schone lei begonnen zijn en élke regel code from scratch geschreven hebben. Ok, hier volgt misschien niet het beste voorbeeld want Notepad/Paint maken natuurlijk niet echt onderdeel uit van de kern van Windows, maar het spreekt wel 't meest tot de verbeelding: denk je dat Microsoft Paint of Notepad opnieuw geschreven heeft voor NT? Of her-en-der aangepast en daarna opnieuw gecompiled en klaar ermee?

Code die bewezen goed werkt wordt gewoon hergebruikt; dat is doodnormaal bij ontwikkeling van dergelijke producten.

Dat neemt niet weg dat ze met NT "met een schone lei" begonnen zijn; dat zijn ze -tot op zekere hoogte- zéker. Maar niet zo schoon als hier geïnsinueerd wordt.

[Reactie gewijzigd door RobIII op 22 juli 2024 14:45]

[ReneX]

Windows NT is niet gebaseerd op MS-DOS en Windows 3 (of ouder). Dat zijn feiten en heeft niks met 'naief zijn' te maken.
Men is wel degelijk met een schone lei begonnen, maar de start daarvan zat al bij DEC - toen nog een project voor de Alpha processor (pas later ging Dave Cutler richting MS).

Ik denk wel dat je onderscheid moet maken tussen applicaties (bv notepad/paint) en het OS. Dit soort applicaties vallen voor mij niet onder het OS.
Hou er trouwens rekening mee dat veel van dit soort applicaties in de tijd nog in assembly (of gedeeltelijk) waren geschreven - en ook dat betekende vaak een rewrite.

[RobIII]

Windows NT is niet gebaseerd op MS-DOS en Windows 3 (of ouder). Dat zijn feiten en heeft niks met 'naief zijn' te maken.

Waar heb ik beweerd dat dat zo zou zijn Maar dat betekent evenmin dat code voor, zeg, een malloc() niet door de jaren heen geport en geport en geleend en geport en gekopieerd is naar wat nu Windows 10 is.

Er is een wereld van verschil tussen "gebaseerd op" en "een (paar) regel(s) code ge-copy/paste". Why is that so hard?

Zoals elders al aangegeven: er zit zelfs nog BSD code in Windows (en als 't er nu niet meer in zit dan was 't in ieder geval tot vrij "recent" zo).

Ik denk wel dat je onderscheid moet maken tussen applicaties (bv notepad/paint) en het OS. Dit soort applicaties vallen voor mij niet onder het OS.

Dat gaf ik notabene zelf al aan in mijn post...

[Reactie gewijzigd door RobIII op 22 juli 2024 14:45]

[ReneX]

Even terug naar het oorspronkelijke bericht "Ja, (natuurlijk) schrijven ze windows niet elke keer opnieuw. Er zitten nog flarden MS-DOS en Windows 3 in Windows 10. "

Dat leest toch echt alsof men met Windows NT heeft voortgeborduurd op MS-DOS en Windows 3. Of je dat dan 'gebaseerd op' of wat dan ook wil noemen - het is niet juist.
Men schrijft Windows zeker niet elke keer opnieuw - maar dat is met Windows NT 3.1 dus wel gebeurd en men emuleerde daarin de 16-bit omgeving tbv MS-DOS - en Windows 3.1 programmas's zonder dat daar code voor is herbruikt (men vertaalt de 16-bit calls - zowel naar API als direct hardware - naar de 32-bit omgeving). Dat verklaart bv waarom er in het begin (nog voordat 3.1 was vrijgegeven) nogal wat issues waren met niet goed afgehandelde calls (dwz niet goed genoeg geemuleerd).

In het begin is Windows NT ook helemaal niet als 'Windows' begonnen, maar als een soort van opvolger van VMS voor de nieuwe DEC Alpha processor (dat was dan wel in het hele prille stadium). Vervolgens verhuisde de architect naar Microsoft waar dit in het begin nog OS/2 3.0 zou gaan worden. Een opvolger en rewrite van OS/2 (assembly), maar nu in C om het portable te maken. Uiteindelijk konden MS en IBM (samen verantwoordelijk voor OS/2) niet meer door 1 deur - en ging het verder als Windows NT (met daarin ook nog het oorspronkelijke OS/2 subsysteem voor OS/2 1.x programma's). Verder werd de Windows 3.1 API opgewaardeerd (wel een rewrite van de code) en uitgebreid tot de Win32 API (welke als subset vervolgens weer in Windows 95 kwam). Eea verklaart waarom Windows NT ook op de Alpha processor draaide (en in het begin zelfs het main platform voor de ontwikkeling was).

[Alfa1970]

er zit zelfs nog BSD code in Windows

Nou, nee, Windows NT 3.1 is gebaseerd op VMS van DEC hoewel BSD ook op VAX draaide.

VMS is echter purpose built voor VAX terwijl BSD voor VAX een port was en geen gebruik maakte van de virtuele memory mogelijkheden van de VAX architectuur.
VMS de naam zegt het al 'Virtual Memory System' dat purpose built was voor VAX had dat vanaf het begin al aan boord.

Later is er een port van VMS gekomen voor DEC Alpha, Intel/HP Itanium en zelfs AMD/Intel x-64 platform.

[RobIII]

quote: https://en.wikipedia.org/wiki/Berkeley_Software_Distribution

These, in turn, have been used by proprietary operating systems, including [...] Microsoft Windows, which used (at least) part of its TCP/IP code
[...]
For example, Microsoft Windows used BSD code in its implementation of TCP/IP

quote: https://lwn.net/Articles/245805/

There's BSD-derived code in Windows for implementing TCP/IP. A trivial hunt on Windows XP with "strings" showed that \WINDOWS\System32\nslookup.exe includes "Berkeley"

[Reactie gewijzigd door RobIII op 22 juli 2024 14:45]

[Alfa1970]

Winsock is gebaseerd op de API van Berkley, en dat is waarom er een plain text copyright bericht van Berkley in de code voor Winsock (2) terug te vinden is.
Echter er zit géén code van BSD en/of Berkley zelf in Winsock (2). Winsock (2) is 100% Windows Native code en wijkt op belangrijke punten af van Berkley's implementatie, en is daar ook niet volledig compatible mee. Daarnaast heeft Winsock voor Windows belangrijke toevoegingen die niet in Berkleys TCP/IP stack zitten.
Een van de veelgehoorde klachten dat Microsoft zich niet aan de (industrie) standaarden houdt heeft hier zijn origine.

Winsock (1) zat origineel niet in Windows maar was een apart te installeren driver verkocht onder de naam Trumpet. Ook die versie, weliswaar ook gebaseerd op de API van Berkley is Windows Native code en bevat geen code van Berkley zelf.

[heuveltje]

Windows NT is niet gebaseerd op MS-DOS en Windows 3 (of ouder). Dat zijn feiten en heeft niks met 'naief zijn' te maken.
Men is wel degelijk met een schone lei begonnen, maar de start daarvan zat al bij DEC - toen nog een project voor de Alpha processor (pas later ging Dave Cutler richting MS).

Niemand ontkent jouw "feiten".
Maar er is een groot verschil tussen opnieuw beginnen en alles herschrijven, of opnieuw beginnen, de core engine herschrijven, en vervolgens kijken wat je van alle overige spullen kunt aanpassen/lenen voor de nieuwe versie

Maar dat neemt niet weg dat er nog wel flarden en legacy bitjes terug te vinden zijn. Er zit nog steeds een ms-dos in windows 7. En nee dat is niet meer dezelfde als in dos 6.1
Maar toen ze de nieuwe x-copy schreven hebben ze vast flarden code uit de 1 voor de ander hebben gebruikt. en zo zijn er nog tientallen voorbeelden te bedenken.

[ReneX]

Je kan veel voorbeelden bedenken, maar geef dan eens een referentie waaruit blijkt dat er MS-DOS in WIndows 7 zit ... (nee de 'DOS BOX" heeft niets met MS-DOS te maken - compleet andere code).
Ook de xcopy is een rewrite - en daar zit niks van de oude code in.
Men heeft in het begin de look and feel van de MS-DOS command line overgenomen (maar dus geen code). Er werden bv virtuele device drivers geschreven om 16-bit code die rechtstreeks naar de hardware ging nog te kunnen draaien.

En waarom ik dit weet ... misschien heb ik wel wat meer met Windows NT gedaan nog voor de eerste versie (3.1) werd vrijgegeven (waaronder een heleboel tickets ivm emulatie van de DOS omgeving en problemen met commando''s).

[RobIII]

Je kan veel voorbeelden bedenken, maar geef dan eens een referentie waaruit blijkt dat er MS-DOS in WIndows 7 zit ...

Nogmaals: Niemand zegt of heeft gezegd dat "er MS-DOS in Windows" zit. Je leest behoorlijk selectief. Wat er gezegd wordt (en ik noemde het juist flarden omdat het geen complete onderdelen zijn!) is dat er stukken code, je weet wel, regeltjes tekst. geleend/geport/ge-copy-paste zijn door de jaren heen. Harde bronnen zul je nooit vinden, Windows is namelijk closed source. Maar je kunt er gif op innemen dat 't zo is; zo werkt software ontwikkeling nou eenmaal.

En waarom ik dit weet ... misschien heb ik wel wat meer met Windows NT gedaan nog voor de eerste versie (3.1) werd vrijgegeven (waaronder een heleboel tickets ivm emulatie van de DOS omgeving en problemen met commando''s).

With all due respect; tenzij je bij MS werkt zegt dit ook helemaal niks. Als je zo een wedstrijdje ver-pissen wil houden komen we allebei niet heel ver en staan we over onze schoenen te druppelen

Ik weet wél - tig jaar geleden - toen de source code van Windows 2000 uitlekte daar diverse analyses op los zijn gelaten en daar kwam wat ik beweer toch écht in naar voren; helaas is dat behoorlijk outdated en kan ik sowieso de links niet meer vinden en al was dat zo, dan nog kon niemand -hard- bewijzen dat het al dan niet waar was wat hier beweerd wordt of dat daar nog delen van in Windows 10 zitten.

Als je een definitief antwoord wil hebben dan stel ik voor dat je 't aan Raymond Chen vraagt* - dé autoriteit op dit gebied. En anders is het in ieder geval een behoorlijk veilige aanname dat er flarden (al is het maar een enkele losse regel code; dat is de definitie die ik erop na hou) straatoude meuk aanwezig zijn in Win10. is het niet in de kernel dan is 't wel in de 'bijgeleverde' applicaties als paint, notepad of format.com of weet-ik-veel. En dat was 't héle punt van mijn initiële bericht; dat 't daarna helemaal semantisch ontleed moest worden en op elke slak zout gelegd moest worden...

*Done

[Reactie gewijzigd door RobIII op 22 juli 2024 14:45]

[ReneX]

"Als je een definitief antwoord wil hebben" - waarom zou ik een antwoord willen hebben op iets dat ik al weet (lees: er zitten geen flarden MS-DOS code en Windows 3 in Windows NT).
Het aan Raymond vragen lijkt mij weinig zinvol, aangezien hij - voor zover ik weet - nog niet bij MS werkte toen Windows NT werd ontwikkeld en daar dus ook niet bij betrokken was. Dave Cutler (en oud collega) lijkt mij meer voor de hand liggen als je het aan iemand zou willen vragen.

Ja, software ontwikkeling is vaak incrementeel, en het "lenen" van stukken code is ook gebruikelijk - maar vergeet niet dat dit 30 jaar geleden vaak niet het geval was, alleen maar om dat zaken vaak in assembly waren geschreven en dicht tegen hardware aan zaten ipv een stuk abstractie met APIs - kortom onbruikbaar voor herbruik. En zoals gezegd, had Windows NT in het begin helemaal niets met Windows of DOS (compatibiliteit) te maken.
Het begon zelfs buiten MS, bij DEC - en de eerste jaren bij MS was alleen OS/2 op Intel/Mips/Alpha in de picture.

Je ziet na NT 3.1 wel een stuk herbruik bij de nieuwe GUI code (hier kwam ook C++ om de hoek kijken). Deze was als 'preview' versie beschikbaar voor Windows NT 3.5 (ipv de Windows 3 achtige GUI) - en deze code uit de "NT hoek" is vervolgens eerst gebruikt voor Windows 95 GUI - en later pas in Windows NT (4.0).

[dehardstyler]

Ja, (natuurlijk) schrijven ze windows niet elke keer opnieuw. Er zitten nog flarden MS-DOS en Windows 3 in Windows 10.

Ja klopt inderdaad. Daarom kun je ook niet "con" of "lpt1" gebruiken in een bestandsnaam. Dus ook geen con.txt bijvoorbeeld.

[latka]

Alleen via de commandprompt. Via de Windows API lukt het wel en NTFS heeft er ook geen last van. Dat is de kracht en zwakte van Windows en de backwards compatibility: er zit zoveel code in Windows die nauwelijks meer een rol speelt maar omdat je (bijna) alle Windows software uit het verleden nog steeds kunt gebruiken moeten zie die legacy instand houden.

[Mangu429]

Niet alleen via cmd prompt.

[latka]

Het kan wel, maar je moet volledige paden gebruiken.

[heuveltje]

Dat kun je daar niet uit concluderen.
Ze hebben hele stukken herschreven, oa de MS-DOS engine in WIn7.

En daarvoor hebben ze heel bewust backwards compatibility aangehouden.
Dus alle functies die zijn teruggebouwd of gekopieerd.

Maar juist omdat heel de MS-DOS herschreven is zonder direct geheugen acces, lijkt me het sterk dat specifiek die functies zo maar zou kunnen overnemen.

[dehardstyler]

Verkeerde draadje?

[ReneX]

Nope - con en lpt1 zijn er in gekomen (net zoals drive letters trouwens) ivm de compatibiliteit en niet omdat er MS-DOS code oid in zit. Maar het OS zelf kan eigenlijk alle willekeurige namen aan.

[StefanJanssen]

Ja, (natuurlijk) schrijven ze windows niet elke keer opnieuw.

Ik denk dat hij bedoeld "op het moment dat ze een beperking tegenkomen, gaan ze dan de oude code gebruiken en de nieuwe functie erin "hacken" of herschrijven ze dat gedeelte"

[RobIII]

Ook dan: dat is afhankelijk van de situatie. Altijd.

[StefanJanssen]

ah, de edit heeft die vraag inderdaad beantwoord.

[Cergorach]

Dat is wel heel simplistisch gesteld, naar mijn mening werkt programmeren niet zo. Elke wijziging is immers een nieuwe functie er in 'hacken' = herschrijven. Als je een post schrijft en vervolgens een stukje midden in de tekst toevoegt dan moet je soms omliggende stukken tekst ook aanpassen en soms niet. Wat ga je 'hacken' noemen en wat herschrijven?

Je gaat toch ook niet elke keer als je iets wilt veranderen in een lap tekst het hele document verwijderen en helemaal overnieuw beginnen? Je gaat pas overnieuw beginnen als dat absoluut noodzakelijk is en/of je wil hetzelfde ding doen op een andere manier (omdat je denkt dat het netter/efficiënter is). Dat ga je niet met heel Windows doen, want zo een nieuw stuk code heeft een veel grotere impact op de rest van de code dan een stukje aanpassen.

[StefanJanssen]

Ik weet dat het simplistisch is alles waar wij het over hebben zal simplistisch zijn vergeleken met de code van Windows (en de kernel). Maar pak een component als de taakbalk. De functies zijn grotendeels hetzelfde sinds Win 95 (en misschien nog eerder?). Zou deze ooit volledig herschreven zijn of is de zoekbalk bij de code van 25 jaar geleden zijn toegevoegd?

[Cergorach]

Zou deze ooit volledig herschreven zijn of is de zoekbalk bij de code van 25 jaar geleden zijn toegevoegd?

De vraag zal eerder zijn, is dat nodig? Er zijn zat bedrijven die de hamer en de spijker opnieuw hebben 'uitgevonden', maar het gros van de mensen gebruikt nog steeds een heel oud design hamer en spijker. Zo zijn er zat bedrijven/personen die nieuwe implementaties van bv. de startbalk opnieuw hebben 'uitgevonden', die opties zijn er, de vraag is of het nodig is in Windows zelf dat volledig te herschrijven.

Gezien ik de afgelopen maanden heb gemerkt dat zoeken in W10 wel anders is gaan werken, vermoed ik dat daar stevig in is herschreven, of alles is herschreven: no clue. Maar weer de vraag, is dat nodig?

[DutchKevv]

Vaak veranderd de hardware / opties ook.

Tegenwoordig hebben veel computers bv SSD's waardoor indexering bijvoorbeeld compleet anders opgezet kan worden omdat I/O veel sneller verloopt.

Alleen dat is al een goede reden om gedeeltes van search overnieuw te schrijven (maar zelden alles)

[StefanJanssen]

Dat was denk ik de orginele vraag ook niet, ik was niet de orginele vraagsteller. Wanneer is het "nodig"? Dat was namelijk ook wat ik met het "erin hacken" bedoelde. Als het beter is om het grotendeels te herschrijven doen ze dat dan ook of "hacken" ze het erin? Dat is de "nodig"/"hack" vraag die we hebben. Ik denk niet dat iemand daar hier antwoord op kan geven.

[Wolfos]

Er zitten nog flarden MS-DOS en Windows 3 in Windows 10.

Zelfs nog een stuk BSD (de TCP/IP stack).

[field33P]

Ik meen dat de TCP/IP stack volkomen herbouwd werd voor Windows Vista.

[vide]

Anderzijds: in bestaande code zijn (hopelijk) de fouten ondertussen gevonden, opnieuw beginnen betekent dat je helemaal terug aan het begin staat qua bug tracking.

Afhankelijk van wat je moet doen, kan verderbouwen of opnieuw beginnen allebei een juiste strategie zijn: een bug repareren ga je (meestal) niet doen door grote herschrijf operaties, maar als de gevraagde functionaliteit drastig verandert, is dat waarschijnlijk wel de beste optie.

Edit: voldoende software tests (kan geautomatiseerd worden) kunnen uiteraard helpen om te zien of een herschreven stuk aan de specificaties voldoet. Maar bugs (die tot privilege escalation en remote code execution zouden kunnen leiden in sommige omstandigheden) zitten vaak natuurlijk in onverwachte input. Daar kan iets als "fuzzing" wel helpen: gooi willekeurige invoer (dus vaak slecht gevormd) ertegenaan en zie waar dat tot onverwacht gedrag of crashes leidt.

Edit 2:
- uiteraard zit je met problemen als je software heel oud is en bepaald vreemd/ongewenst gedrag actief wordt gebruikt door applicaties/gebruikers (Windows API eigenaardigheden bijvoorbeeld, maar bijvoorbeeld ook Java applicaties die net die specifieke versie van de JRE nodig hebben.
- het is niet omdat alle tests correct doorlopen worden dat alles werkt. Vergelijk het met lego blokjes: al je blokjes/delen gebouw zijn juist, maar het geheel kan nog steeds verkeerd op elkaar gestapeld worden

[Reactie gewijzigd door vide op 22 juli 2024 14:45]

[latka]

Bij Windows is het iets complexer, zeker in de API. Als een belangrijke/grote applicatie leunt op het verkeerd geimplementeerd zijn van een Windows API kan het zo maar zijn dat de documentatie/specificatie aangepast word. Bij Windows is backwards compatibility vrij hoog. Daarnaast is de Windows API heel groot en zit er global state in het OS wat het vrij lastig maakt om een complete unit test coverage te maken die alle condities taakt. Windows is nooit TDD ontwikkeld zeg maar.

[cracking cloud]

Aangezien er nog user interface onderdelen van windows 95 in zit verwacht ik dat ze niet zozeer aan vervangen doen maar vooral aan erbij plakken.

[ReneX]

De user interface van 95 kwam eigenlijk al van NT af. Die was weliswaar nog niet beschikbaar in NT (althans niet standaard - wel als test versie in een soort van 'add on' pack) en kwam als eerste beschikbaar met het eigenlijk niet geplande Windows 95 en daarna pas in Windows NT 4.0.
Dit was eigenlijk ook het eerste stuk code waar men C++ is gaan gebruiken (NT zelf was in C geschreven).

[DarkJack]

De code herschrijven kan compatibiliteitsgevolgen hebben.

Microsoft's sterktste en zwakste punt is net dat ze altijd "nieuw" en "backwards compatible" combineren. Zo hoeven vooral hun zakelijke klanten niet noodzakelijk bepaalde oudere software of applicaties te updaten om toch mee te kunnen met de nieuwe dingen. Microsoft weet goed genoeg : don't bite the hand that feeds you. Dit is ook de reden waarom Windows zo sterk blijft in het bedrijfsleven, toch aan de client kant.

Zie ook: de "Internet Explorer mode" van Chromium Edge.

[batjes]

Microsoft veranderd constant code aan Windows. Er zit nog wel wat legacy in, maar dit zit er voornamelijk nog in voor backwards compatibility redenen. Er is amper code over gebleven uit het vorig millenium dat nu nog actief gebruikt wordt. Hier is eigenlijk maar 1 grote uitzondering op, de Win32 API zelf. Hier zit nog wel veel legacy meuk in van decennia geleden. Er zit her en der nog wel wat verdwaalde antieke code, maar hier geldt vaak het idee, dat als ze het opnieuw programeren, wordt het resultaat hetzelfde. (Wat ook de reden was dat MS lange tijd de BSD network stack gebruikte). Er is ook nog wel veel legacy meuk te vinden omdat redelijk wat zaken in Windows 10 dubbel uitgevoerd zijn (om de overgang te helpen) zoals het control panel bv, wat nog uit XP dagen stamt.

De rest van het OS onder de motorkap wordt elke 2-3-4 Windows releases voor een groot deel herschreven. 1 van de laatste stukjes code in Windows uit het vorig millenium was de BSD network stack, dit is met Windows 8 eindelijk vervangen door iets dat MS zelf geschreven heeft. Voor de rest lijkt Windows 10 onder de motorkap nauwelijks nog op voorgangers Windows 7 en 8(.1), zo'n beetje elk onderdeel van Windows is opnieuw gebouwd.

[ReneX]

Bron? Ja er verandert veel (uiterlijk) maar veel concepten zijn nog identiek aan de 1e versie. Zo af en toe gaat er wat grondig op de schop (driver model etc., GUI) - maar ook in W10 is er onder de motorkap nog veel terug te vinden van vorige versies.

[mvrhrln]

https://www.joelonsoftwar...u-should-never-do-part-i/

[AW_Bos]

Er zit volgens mij nog zelfs wat legacy code van Windows 95 in, of misschien nog wel iets van 3.11.

Pas kwam ik de dialer.exe nog tegen in Windows 10. De oude telefoonkiezer.....

[Reactie gewijzigd door AW_Bos op 22 juli 2024 14:45]

[latka]

De legacy komt voornamelijk uit Windows NT 3.1. Dat is de eerste echte Windows geweest. Daarop is toen de (16-bit) Windows API gezet en een win32 api erbij. Die win32 api is weer richting Windows95 gegaan en verder ontwikkeld. Deze ontwikkelingen zijn weer heen en weer tussen Windows NT 3.1/3.5/3.51 gegaan. Na Windows98 was dat voorbij en Windows 2000 (de lijn na Windows NT) is doorgezet naar wat we nu hebben. Dus ja, het zit vol legacy, maar voornamelijk uit de NT3.1 t/m Windows 2000 tijd. Kun je testen door de Windows 1.0 versie van Paint.exe te pakken: die doet het nog steeds (dus de API van Windows 1.0/2.0/3.0/3.1 zit in Windows 10).

[EXX]

Windows 1.0 was toch een 16 bits applicatie? Die worden IIRC door Windows 10 x64 niet meer ondersteunt.

[latka]

Kan zijn dat de Windows Paint.exe test gedaan werd met Windows 8. Mijn geheugen is fuzzy. Ik dacht op youtube iemand gezien te hebben die een test deed.

[EXX]

Maakt niet uit, Windows 7, 8 of 10: de 64 bits versie ondersteunt geen 16 bits applicaties meer. Het lijkt me waarschijnlijker dat de 32 bits versie gebruikt is: die bevat nl. wel nog de ondersteuning voor 16 bits applicaties. Helaas zit je dan wel vast aan de beperkingen van de 32 bits versie.

[Simon Weel]

Iemand enig idee of Windows steeds verder gaat op de huidige code?

Als je geheel op afstand bekijkt - en de geschiedenis daarbij dient als voorbeeld voor de toekomst van Windows: Ja.

Windows kent de nodige fundamentele problemen. Vergelijk het met een huis. Is de fundering niet goed, dan kan je dat op verschillende manieren oplossen. De beste, duurste en meest rigoureuze oplossing zou een geheel nieuwe fundering zijn. Maar dan haal je nogal wat overhoop. Om over de kosten nog maar te zwijgen. Dus kiezen we voor een alternatief herstel; we laten de oude fundering zitten en gaan daar omheen een nieuwe maken.Dat geeft de nodige hoofdbrekers - hoe zorg je dat de nieuwe fundering netjes aansluit op het bestaande gebouw etc. Een paar jaar later bedenken we dat we een extra verdieping op het huis willen zetten. Maarja, daarvoor is de opgekalefaterde fundering niet stevig genoeg. Weer zijn lapmiddelen nodig om dat te ondervangen.

Dat is grofweg de manier waarop Windows in elkaar zit - veel lapmiddelen om de fundamenten te ondersteunen. De vrees voor fundamentele ingrepen is de heilige compatibiliteit. Ook programma's uit 19 flintstone moeten nog kunnen draaien op hedendaags Windows. Zal wellicht een trauma van OS/2 zijn. Neemt niet weg dat wel aan de fundamenten wordt gesleuteld, maar dan langs de weg der geleidelijkheid. Dat blijkt wel als na een 'feature-update' sommige zaken plots niet goed meer werken.

[Anthonie Smit]

Dit vind ik wel een erg flauwe vergelijking... Windows als huis met een verkeerde fundering.

Als ik het met een gebouw zou moeten vergelijken, dan eerder met International Airport. Het heeft een prima fundering. En veel in- en uitgangen. Beveiliging is complex en maandelijks moeten veel worden verbeterd.

[ToolBee]

We zouden zonder corona-ellende toch inmiddels een verse win10 moeten hebben, de 2004 of hoe ze het willen noemen?

[dehardstyler]

Zo dan! Is iedereen ineens thuis aan het hacken geslagen tijdens corona of zo?
Dat zijn wel erg veel kwetsbaarheden in een keer.

[wildhagen]

Valt op zich wel mee, het komt wel vaker voor dat er meer dan 100 bugs gefixed worden. Vergeet niet dat het vaak alleen al om meerdere versies van Windows gaat.

En lang niet alle bugs zijn voor iedereen interessant, het zijn vaak ook bugs in exotische produkten als Microsoft BizTalk, Microsoft Dynamics etc, produkten die niet zo bekend zijn. Het zijn dus zeker niet alleen lekken in Windows, Office etc.

En sommige bugs hebben een low of intermediate risk, lang niet alles is critical. Bijvoorbeeld omdat ze alleen te exploiten zijn onder zeer specifieke condities, die in de praktijk zelden voorkomen.

[Reactie gewijzigd door wildhagen op 22 juli 2024 14:45]

[RobIII]

Daarbij: Soms kun je door 't oplossen van een bug in, zeg, 1 DLL of ander gedeeld bestand tientallen applicaties / services / componenten / onderdelen die daar gebruik van maken fixen. Ik zeg niet dat dat hier het geval is, maar dat kan natuurlijk wel ooit meespelen.

[DancingMonkey]

Door de titel denk je dat Windows 111 kwetsbaarheden had maar het gaat dus om allerlei verschillende software producten van Microsoft. De meeste in dev tools maar ook browser, office en meedere besturingssystemen.

Netjes dat ze het nu zo transparant rapporteren dat was vroeger wel anders met de low impact issues.

[IStealYourGun]

Officieel is die informatie vertrouwelijk voor premier klanten en partners. Bovenaan de mail met die informatie staat er mooi: "Confidentiality: DO NOT REDISTRIBUTE."

Die pool van bedrijven is echter zo groot dat het snel naar buiten komt. Ik vermoed zelfs dat de IT department van sommige media bedrijven dit gewoon ontvangen.

[TijsZonderH]

Er staat in de titel dat Microsoft lekken dicht, Windows wordt er helemaal niet genoemd...

[Zornar]

In de eerste regel van de dikgedrukte samenvatting staat "Microsoft heeft tijdens de maandelijkse Patch Tuesday 111 lekken gedicht in Windows.". Waardoor je wél de indruk krijgt dat het alleen om Windows gaat.

[s.lenders]

Het is de derde maand op rij dat Microsoft meer dan 110 lekken in het besturingssysteem repareert

Ik zou als Microsoft Consultant graag zien dat Tweakers nuance aanbrengt. Dit zie ik als paniekzaaierij. Het aantal CVE's wat gepatcht wordt is geen graatmeter. De CVSS score van de updates is belangrijker.

Het aantal CVE's wat gepatcht wordt is sterk afhankelijk aan de detectie er van. Microsoft is de laatste tijd juist goed bezig door de security programs voor het detectie van dit soort lekken te verhogen. Maar wij hebben klanten die na het lezen van dit soort artikels totaal in paniek opbellen.

En in vergelijking met eerdere maanden vind ik de lekker die gedicht worden deze maand minder spannend dan een aantal in eerdere maanden.

[TijsZonderH]

Ik denk dat dat vooral ligt aan de manier waarop je het als lezer interpreteert. Hoeveel cve's er gepatcht worden kan meerdere oorzaken hebben. Dat is geen paniekzaaierij, het zegt niet dat cve's per definitie superernstig zijn - in de rest van het stuk staat daarvoor gewoon aangeduid hoeveel er Kritiek of Belangrijk zijn.

Ik denk dat het een belangrijke trend is (drie maanden op rij hoogste aantal cve's ooit gerepareerd). Aangezien Microsoft er zelf geen verklaring voor heeft zou je met de 'nuance' die je noemt vooral speculeren en dat is niet aan ons. Daarom schrijf ik het zo op, gewoon als feit.

[fapkonijntje]

Ik vind dat je als schrijver hier wel heel kort door de bocht gaat en dit artikel had wat meer aandacht mogen hebben. Wat mij betreft dien je je lezers te informeren en niet in de war te brengen met een onsamenhangend verhaal zoals dit. Je hebt er namelijk best wel wat twijfelachtige zinnen instaan, zoals de 111 kwetsbaarheden in Windows, terwijl een deel van die kwetsbaarheden in Visual Studio zitten. Dat is geen Windows. Iets vergelijkbaars geef je later in het artikel weer wel een soort van aan, door Edge e.a. te noemen, maar hier spreek je jezelf tegen in je eigen artikel.

Juist van een website als Tweakers mag een lezer iets meer duiding, samenhang en achtergrond verwachten, met op z'n minst een iets meer samenhangend berichtje. Anders kunnen we beter de bedroevende technieuwtjes van nu.nl gaan lezen.

[s.lenders]

He Tijs

Ik zal ook zeker niet ontkennen dat de interpretatie van een aantal lezers het maakt dat men in paniek raakt. Dat zal afhankelijk zijn van de persoon die het leest. Maar ik zou het daarom mooi vinden dat Tweakers als nieuws platform daar juist extra toevoeging aan kan geven.

Want wat betekend het nu dat Microsoft 111 lekken dicht? Is Windows nog wel veilig?
Ik ken de antwoorden omdat ik er dagelijks mee werk.

Speculatie hoeft er niet te zijn. Microsoft zal die vragen wel beantwoorden mag ik hopen als jullie ze als nieuwsoutlet stellen.

Anyway thanks voor je responce

[Globefrotter]

Tja, hoe meer toeters en bellen in het besturingssysteem, hoe meer kans op kwetsbaarheden...
Ik herinner me nog dat Windows '95 t/m Windows XP op een CD-Rom pasten, dus vanaf ca. 600 MB. Ik zie nu alleen al in de Windows map van Win10 dat er een grootte is van 19,6GB.
Volgens mij is dat ook vragen om problemen.
Van mij mag Win10 stukken slanker met veel minder onzin-functies die ik van mijn levensdagen niet ga gebruiken.
Laat ze een slanker OS maken met uitbreidingsmodules voor wie het nodig denkt te hebben.
Dan wordt Windows waarschijnlijk een stuk veiliger en een stuk stabieler.
(Ik zie in de eigen Freewall firewall die ik heb geïnstalleerd dat Windows letterlijk bij elke handeling die ik verricht contact legt met internet, zelfs wanneer ik in de verkenner iets zoek op mijn eigen harde schijf: dan liggen kwetsbaarheden op de loer)

[pang-frang-punk]

Dag Henri, ik heb even de tijd genomen om je bericht te onderzoeken hier in een computerlabo. Wat mij opvalt is dat de windows install iso kleiner is dan 4 GB. Dat wil zeggen dat het grootste deel van de gegevens zeer compact wordt opgeslagen op de DVD of Install USB. Wat er vervolgens gebeurt is iets bijzonder krachtigs. Windows 10 1903 (welke ik als voorbeeld heb gepakt, en 1909 heeft dezelfde codebase maar iets meer up-to-date cumulatieve updates aan boord) heeft de mogelijkheid om uw software te ondersteunen van eender welke leverancier, soms zelfs teruggaand tot het begin van deze eeuw, die ondertussen 20 jaar oud is. Dat is in computertermen een eeuwigheid. Daar komt nog bij dat u deze Windows 10 op zo goed als elke computer kunt installeren die in het grootste deel van de afgelopen 10 jaar is uitgekomen, kunt installeren. Er is een gratis stuk software beschikbaar waarmee u kunt zien hoe veel van de schijfruimte in welke map gebruikt wordt. Dat programma heet WinDirStat en is zo verkrijgbaar na een korte google opdracht. Wel zijn lokale administrator rechten vereist. U gaat zien dat het grootste deel van uw windows installatie zich gaat bevinden in de mappen WinSxS en Installer. De WinSxS map houdt specifiek voor uw systeem de gegevens bij van de belangrijke windows update bestanden die voor uw en alleen uw systeem gelden. Alle andere updates die niet van toepassing zijn worden hier niet bijgehouden. De andere map, namelijk Installer, bevat een kopie van alle installatiebestanden en patches van programmas die u zelf geïnstalleerd heeft. Dit wordt bijgehouden om de deinstallatie mogelijk te maken. Mochten deze mappen erg groot zijn (standaard schommelt het ongeveer rond de 7 GB voor WinSxS op dit moment en ±5.5 GB voor de Installer map), dan kan u het volgende proberen. Voor WinSxS, voer een disk cleanup uit via de eigenschappen van de c schijf, en voer hierbij de systeembestanden cleanup uit, of run het volgende commando in een administratieve cmd prompt. Doe dit wel enkel indien u zeker bent dat u geen windows updates of servicepacks wilt deinstalleren in de toekomst:
DISM.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
Voor de Installer map kan het zijn dat na intensief gebruik van Windows hier bestanden achterblijven die u inderdaad niet meer nodig hebt. Op sourceforge is een opensource tool beschikbaar die uitzoekt welke van de installerbestanden er niet langer verwant zijn aan programmas die ook daadwerkelijk geinstalleerd zijn. Deze tool heeft de naam PatchCleaner, en is te vinden op https://sourceforge.net/projects/patchcleaner/
De portable versie vereist zelfs geen installatie, wel zijn ook hier lokale adminrechten noodzakelijk.
Deze tools zijn allen uitgebreid getest, maar zoals altijd, voer enkel programmas uit waarvan u het niet alleen het resultaat begrijpt maar ook waarvan u het proces begrijpt.
Ten slotte hebben we nog de assembly map onder C:\Windows. Hierin staat grotendeels de verzameling benodigde bestanden voor het draaien van .NET tools. Bij mij is deze map 3 GB op een systeem waar visual studio op staat. Zo bij elkaar geteld komen we dan aan een 15 GB. Give or take. Dan is er nog de System32 map. Op mijn systeem bestaat de helft hier van uit de driverstore, speciaal voor mijn systeem. Deze gaat bij u dus mogelijk uit compleet andere inhoud bestaan, maar zal qua omvang ook ongeveer 1 GB zijn. En dan zien we iets geks. Het gaat hier om een 64 bit besturingssysteem, maar omdat u software wilt kunnen gebruiken die wellicht is geschreven begin deze eeuw, hebben we ook 32 bit versies van zo goed als elk besturingssysteemonderdeel. Onder de System32 vinden we de 64bit versies, omdat het hier om een 64bit besturing gaat, en onder de SysWOW64 (system windows on windows 64bit) vinden we de oude 32bit onderdelen. Deze lijken overbodig, maar in realiteit zijn beiden zeer hard nodig.
Terug optellen: 7 GB WinSxS, 5.5 GB Installer, 3 GB (grotendeels .NET) assembly, 1 GB driverstore (kan bij u verschillen), 1 GB x64 (64bit) besturingssysteembestanden, 1 GB x86 (32bit) besturingssysteembestanden. Zo komen we al aan 18.5 GB, waarvan slechts ongeveer 2 GB er gecomprimeerd op de installatieschijf staan.
Op mijn systeem blijft er dan 4 GB over, waarvan nogmaals 1 GB voor het .NET framework.
Een laatste tip: is de map SoftwareDistribution erg groot op uw systeem? Schakel dan via services tijdelijk de wuauserv uit, verwijder de inhoud van deze map, en schakel de service hierna terug in. Zo blijft er na een update check op mijn systeem 250 MB over.
De rest van de windows map bevat allerlei zaken die windows maken tot wat windows is: een systeem voor zo goed als elke consument en zo goed als elke zakelijke gebruiker, waarover volledige controle kan worden genomen door de IT afdeling, of waar het de enige- en hoofdgebruiker vrij staat te doen en laten wat die wil.
Waarom is dit 19,6 GB? Omdat opslagruimte goedkoper is dan hypergeoptimaliseerde code genereren die ook nog eens onderhouden kan worden. Efficiënt programmeren vereist efficiënte programmeurs. En die zijn veel duurder dan een harde schijfje voor een eindconsument.

[Kalief]

Wat is het toch met die updates die een uur lang op 73% blijven hangen; wat is het toch aan het doen?

[Toff]

Geen idee...

Ik houd hier voor de lol nog wat oudere systeempjes bij. Geen idee waarom, maar hoe ouder c.q. minder krachtig het systeem, hoe langer het lijkt te duren. Eén uur is nog aan de snelle kant. Soms laat ik een systeem maar een nachtje met rust, waarna het uiteindelijk wel goedkomt.

Een ander, maar mogelijk verwant probleem is, dat oudere systemen na een Windows update vaak niet meer willen opstarten, de eerste keer. Na een reset gaat het dan meestal wel weer goed.

Mijn over-the-top systeem (eind 2019) lijkt als een warm mes door de update-boter te gaan. Uren worden minuten. Wel fijn, maar geen idee waarom.

[Clemensmaxt]

Goeie service, die maandelijkse updates!

[winkbrace]

Eleventy-one problemen gefixt. I approve.