Bug in ssl-implementatie Windows laat aanvaller code uitvoeren

Alle recente versies van Windows bevatten een ernstige bug in de ssl/tls-software, heeft Microsoft bekendgemaakt. De bug laat een aanvaller eigen code uitvoeren door geprepareerde pakketten naar een server te sturen.

Servers die op Windows draaien zijn daarom het meest in gevaar voor de kwetsbaarheid, maar de kwetsbaarheid kan ook desktops en laptops treffen. Dat kan als ze software draaien die op een port luistert, bijvoorbeeld een ftp-server of de web-interface van een torrent-client.

Microsoft heeft weinig details bekendgemaakt over de bug, anders dan dat de aanvaller eigen code kan uitvoeren door geprepareerde pakketten naar een server te sturen. Het is niet duidelijk met welke rechten een aanvaller eigen code kan uitvoeren. Mogelijk hangt dat af van de rechten van het proces waarnaar de pakketten worden gestuurd. Als een aanvaller geen beheerdersrechten heeft, zou hij die kunnen verkrijgen met behulp van een andere kwetsbaarheid.

Microsoft heeft op zijn traditionele patchronde op de tweede dinsdag van de maand een patch uitgerold voor de bug. Volgens de softwaregigant zijn er geen aanwijzingen dat de bug in de praktijk is misbruikt. Een beveiligingsonderzoeker heeft het lek ontdekt. Nu de kwetsbaarheid overigens wel in de openbaarheid is, is de kans groot dat aanvallers hem zullen proberen te misbruiken.

De ssl/tls-implementatie van Microsoft, Schannel, is de nieuwste grote ssl/tls-implementatie die dit jaar met een kwetsbaarheid kampt. Eerder kampte de implementatie van Apple met de goto fail-bug, waardoor de inhoud van ssl-verkeer was in te zien, en kon via de Heartbleed-bug in OpenSSL het interne geheugen van een webserver worden uitgelezen. Chrome en Firefox accepteerden verder valse ssl-certificaten, terwijl GnuTLS dit jaar twee keer lek was.

Reacties (91)

[MAX3400]

MS14-066 vervangt in ieder geval MS12-049 en daar zit 2 jaar tussen. Het is dus opvallend dat er dus mogelijk al 2 jaar lang misbruik is gemaakt (of een verkeerde implementatie is geweest) op een aantal Windows-systemen en dat er nu weer/pas een patch voor komt.

Dat kan als ze software draaien die op een port luistert, bijvoorbeeld een ftp-server of de web-interface van een torrent-client.

Het kan erger zijn; de specifieke getroffen protocollen worden op Windows ondersteund door Schannel en ik denk dat een aantal beheerders toch echt zelf even heel goed moeten kijken of ze de implementatie van TLS/SSL op hun machines opnieuw moeten configureren, zelfs na de update te hebben geinstalleerd.

/edit: de bekende torrent-client uTorrent heeft wel een web-interface maar die wordt standaard niet aangezet en als je 'm al aanzet, heb je ook standaard alleen een http-interface.

[Reactie gewijzigd door MAX3400 op 24 juli 2024 06:40]

[Bacchus]

/edit: de bekende torrent-client uTorrent heeft wel een web-interface maar die wordt standaard niet aangezet en als je 'm al aanzet, heb je ook standaard alleen een http-interface.

De gesuggereerde manier om uTorrent's WebUI over https te krijgen, lijkt ook met behulp van een Apache proxy te zijn, dat suggereert meer OpenSSL dan Schannel.

[[Yellow]]

Heartbleed is ook 2 jaar ongepatched gebleven, dus wat dat betreft doet de open-source community het niet beter

[G4u]

Wederom het bewijs dat SSL beveiliging geen garantie is,
"Nu de kwetsbaarheid overigens wel in de openbaarheid is, is de kans groot dat aanvallers hem zullen proberen te misbruiken."
Ik vraag mij of hoeveel procent daadwerkelijk elke windows update uitvoert. en door het bekendmaken hiervan alsnog een gevaar lopen.

[MAX3400]

Wederom het bewijs dat SSL beveiliging geen garantie is,

SSL is per definitie geen beveiliging maar een encryptie. Door bepaalde communicatie door middels van SSL/TLS te encrypten, is er een verminderde kans dat bepaalde communicatie kan worden ondervangen door andere partijen.

Neemt niet weg dat security een geheel ander spel is; je kan nog zoveel implementaties van SSL op een omgeving toepassen en daardoor de systemen & gebruikers "verplichten" om dus een secure socket/channel op te zetten voor de communicatie; de integriteit van de omgeving zal er niet beter van worden zolang sommige mensen nog steeds hun password plaintext opschrijven op een Post-It, bijvoorbeeld.

[cyberstalker]

Die encryptie zou echter wel moeten zorgen voor een verhoogde veiligheid: Het is namelijk niet langer mogelijk om eenvoudig via een MITM-aanval code te injecteren in bijvoorbeeld webpagina's die een SSL-connectie worden geladen.

Zonder SSL moet je er eigenlijk vanuit gaan dat elke pagina gecompromitteerd is, omdat dat namelijk best wel zo zou kunnen zijn.

[Dorank]

Je verwart encryptie met identificatie, het gebruik van ssl/tls als encryptie techniek geeft geen garantie op het voorkomen van mitm. Om een mitm te voorkomen is er een externe controle nodig of je wel praat met de server met de corecte public key. En dat is op dit moment uitbesteed aan het uiterst fragiele CA systeem, wat in het verleden al bewezen is als onbetrouwbaar (diginotar, turktrust dir google certs uitgeeft, enz.)

BTW er zijn initiatieven (https://www.ietf.org/rfc/rfc3230.txt) om content te kunnen verifieeren, maar met een mitm kan je natuurlijk de headers aanpassen. Een simpele checksum is dus niet voldoende, deze moet weer gesigned zijn maar dan kom je weer bij trust van de pki zoals hierboven beschreven.

[flabber]

[...]
SSL is per definitie geen beveiliging maar een encryptie. Door bepaalde communicatie door middels van SSL/TLS te encrypten, is er een verminderde kans dat bepaalde communicatie kan worden ondervangen door andere partijen.

Neemt niet weg dat security een geheel ander spel is; ...

Volgens mij is encryptie en beveiliging wel degelijk één en hetzelfde spel....
Datasecurity rust op drie pilaren:
- beschikbaarheid : data moet (altijd) voorhanden zijn, anders heb je er niets aan.
- betrouwbaarheid : data moet origineel zijn en niet zomaar gewijzigd kunnen worden
- vertrouwelijkheid : data moet alleen toegankelijk zijn voor bevoegden

Afhankelijk van de data zijn een of meer van deze drie van toepassing.
Bij een testament is het niet noodzakelijk dat deze 24 uur per dag beschikbaar is, maar je wil wel dat deze betrouwbaar is en dat er niemand mee heeft zitten rommelen.
Bij medische gegevens gaat het dan weer meer om vertrouwelijkheid.

En juist bij vertrouwelijkheid is encryptie de enige mogelijkheid om data vertrouwelijk over een niet-vertrouwelijk medium (internet) te kunnen uitwisselen.

[Niemand_Anders]

En juist bij vertrouwelijkheid is encryptie de enige mogelijkheid om data vertrouwelijk over een niet-vertrouwelijk medium (internet) te kunnen uitwisselen.

Encryptie van gevoelige data moet niet gebeuren door het TRANSPORT protocol. De data moet al encrypted worden OPGESLAGEN. SSL is *NIET* bedoeld als bescherming van DATA, maar van de TCP sessie. Daarbij gaat SSL en de bijhorende certificaten uit van een bepaald vertrouwen in instantie welke deze certificaten vertrekken.

Ik kan op een core router bijvoorbeeld gewoon een MITM attack opzetten als ik bijvoorbeeld een certificaat als *.google.com (wildcard) weet te bemachtigen, ondertekend door een grote organisatie zoals Comodo. Er zijn honderden, zo niet duizenden resellers welke namens de grote certificaat providers certificaten vertrekken of zo'n reseller te hacken. Immers als jij een 'geldig' certificaat hebt, kun jij een relay opzetten waarbij de client niet met Google communiceerd, maar met jouw server en jouw server bouwt vervolgens een connectie op naar Google en blijft daar tussen zitten.
Op een dergelijke manier wist Iran gmail verkeer te monitoren. Gebruikt van client certificaten maakt MITM aanvallen wel heel erg lastig, maar worden helaas zeer weinig toegepast..

Echter werpt SSL/TLS wel een flinke drempel op om de TCP sessie over te nemen. Daarom wordt wel vaker gezegd dat SSL/TLS geen beveiliging is..

SSL encryptie is alleen transport beveiliging en is (kan) zelfs transparant naar de applicatie gebeuren. Web applicaties (niet de server zelf) zijn transport onafhankelijk en het transport kan wel of niet beveiligd zijn. Applicaties welke werken met gevoelige data moeten daarom uitgaan van een NIET-BEVEILIGD transport en dus dient de client en de server zelf voor de beveiliging (encryptie, ondertekening) van de data te zorgen.

Meestal gebeurt dit in de vorm van een PKI infrastructuur. Als je van elke user een eigen publiek key opslaat op de server (en de client zijn private key zorgvuldig bewaard) kan de server de data VOOR transport al encrypten en te ondertekenen middels de public key van de client. Daardoor kan ALLEEN de client de data valideren en decrypten.

Het zorgvuldig bewaren en beschermen van de private key van de client (user) valt buiten de scope van de data beveiliging zelf. Om de private key beter te beschermen is het mogelijk deze te beveiligen met een wachtwoord.

De communicatie gaat dan VEILIG over zowel HTTP, HTTPS of welk protocol dan ook wordt gebruikt. Wordt een beveiligd transport protocol gebruikt zoals SSL/TLS, dan wordt gedurende het transport de data als het ware dubbel encrypted..

Het is NIET de taak van SSL/TLS om jouw data te beveiligen, de taak van SSL/TLS is puur en alleen een veilig transport protocol te bieden. Aangezien SSL beveiliging niet aanwezig is als het document wordt opgeslagen op een USB stick is SSL dus niet adequaat voor de beveiliging van gevoelige data in het algemeen.

Websites vormen in dit verhaal eigenlijk een uitzondering omdat technisch gezien de applicatie alleen op de server draait. In deze tijd met HTML5, Ajax technologie en libraries zoals jsencrypt kun je steeds meer doen, maar web applicaties welke in een browser draaien, kunnen niet zomaar bestanden op de client computer openen. Dat maakt het dan weer lastig om een private key bij de client te krijgen (bijvoorbeeld via de post) en deze vanuit een Ajax applicatie te gebruiken..

En aangezien (HTML) cloud applicaties steeds populairder worden is het ook logisch dat men zich richt op een zeer vatbaar protocol zoals SSL/TLS of eigen meer de implementaties daarvan.

Dan de drie pilaren welke je noemt:
Beschikbaarheid: SSL heeft hier geen invloed op. Data welke je via HTTPS kunt benaderen kun je theoretisch ook via HTTP benaderen. Het is dan de webserver/webapplicatie welke je dan alsnog doorstuurt naar de 'beveiligde' omgeving. Maar dat valt buiten de scope van SSL/TLS

Betrouwbaarheid: SSL/TLS kan alleen de authenticiteit van data tussen twee endpoints garanderen. Bij een MITM attack zoals door de Iraanse overheid is de SSL verbinding met de relay server correct en valide. SSL/TLS kan dus niet garanderen dat data onderweg van applicatie client naar de applicatie server onderweg niet wordt gewijzigd aangezien het geen controle heeft over de route naar de applicatie server en de 'hops' daartussen.

Vertrouwelijkheid: Dit is eigenlijk een pilaar waarop SSL/TLS zou kunnen steunen, maar alleen als men gebruik maakt van client certificaten. Publieke websites maken niet gebruik van client certificaten en is dus het onderscheppen van bijvoorbeeld de Tweakers sessie cookie voldoende om over de SSL/TLS (HTPS) verbinding je als iemand anders voor te doen. Client certificaten worden vooral gebruikt bij extranet omgevingen.

[flabber]

Je hebt grotendeels gelijk, ik heb dan ook nergens beweert dat SSL (SSL/TLS) een goede manier van beveiliging is.
Maar de stelling was : "SSL is per definitie geen beveiliging maar een encryptie" en mijn reactie was dat encryptie ook wel degelijk bij beveiliging hoort.

Transportbeveiliging, of het nu via SSL/TLS of IPsec of nog andere methoden gaat, is weinig zaligmakend, maar helaas zijn er situaties waarbij er (nog) geen alternatieven zijn.
Een PKI met client certificaten werkt alleen bijvoorbeeld alleen bij reeds bekende gebruikers. Er zijn genoeg situaties te bedenken waarin de data (nog) niet versleuteld kan worden, maar wel beveiligd over het internet gestuurd moet worden.
En zelfs als data zelf al versleuteld is, kan het toevoegen van beveiliging op de transportlaag wat toevoegen.

[Zyppora]

Het feit dat SSL op deze wijze kwetsbaar blijkt is nog geen reden om het dan maar niet te gebruiken. Hoe meer gaten bekendgemaakt worden, hoe beter want dat betekent gewoon dat ze gedicht kunnen worden. Daarnaast: het feit dat in het artikel vooral over Windows gesproken wordt, doet mij sterk vermoeden dat het niet om het SSL/TLS protocol zelf gaat, maar om de implementatie daarvan op Windows machines.

[SuperDre]

Het is wederom het bewijs dat geen enkele beveiliging een garantie is...

[IceTeaGX]

Ik ken nochthans veel bedrijven waar patches zeer traag geïmplementeerd worden.
Die 1 jaar na het verschijnen van win7 sp 1 nog steeds op een VOLLEDIG ongepatchte Windows werkten.
Servers waren er al niet veel beter aan toe. Uiteraard met de nodige virussen etc. tot gevolg.

Dus ja, in de IT, wordt veel zonder gordel gereden.

[Reactie gewijzigd door IceTeaGX op 24 juli 2024 06:40]

[Atomsk]

Ja, want het is erger wanneer het hoofd van de HR afdeling boos is dat custom applicatie X niet meer werkt vanwege een patch, dan wanneer hackers inbreken op een server. In dat laatste geval kun je namelijk altijd een verhaal ophangen dat hier niets tegen te doen was. Bij een chagrijnige manager wijzen echter alle vingers naar jou.

[YopY]

Dan moet je ook geen custom applicatie X gebruiken, tenzij je daar een onderhoudscontract of developers voor hebt zodat je het bij kunt werken. Software dat niet onderhouden of bijgewerkt wordt is vragen om problemen.

[RGAT]

Dat het bijgewerkt kan worden is alles behalve een garantie dat je zomaar van alles en nog wat kan patchen en die applicatie door blijft werken.
En iemand op een testsysteem zetten om een voor een updates te testen, kijken of die applicatie nog werkt en zo niet de ontwikkelaars inlichten zodat die het kunnen aanpassen zou een 24/7 gebeuren zijn, anders ligt je applicatie er alsnog bijv. een ochtendje uit en ligt het werk stil...

[Enai]

Works both ways: ik werk in HR en erger me wel eens appelblauwzeegroen aan de policies van ICT.

[Plopeye]

Omdat je geen flauw benul hebt hoe die policies terugslaan op de werkelijkheid en waarom ze er zijn. Zien we vaak, als IT'er steek ik dan hand in eigen boezem en neem bij een gebruiker nog wel eens de moeite om dit uit te leggen en het onbegrip weg te nemen.

[mae-t.net]

En jij hebt dan weer geen flauw benul aan welke policies Enai zich ergert, dus nog best dapper om daar een uitspraak over te doen. Vaak is het een kwestie van ongbegrip, soms gewoon van onzin. Niet bij mijn klanten natuurlijk, maar ik lees The Daily WTF wel eens...

@hieronder: Daar heb je in principe gelijk in, al ligt de situatie in werkelijkheid soms vervelender. Zijn overweging moet weliswaar niet de doorslag geven, maar als werknemer kan je in een positie verkeren waarin je je afvraagt of je het je kunt veroorloven om ontslagen te worden, ook al kun je achteraf je gelijk halen. Dat iemand die overweging maakt, snap ik opzich wel.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 06:40]

[Plopeye]

Het feit dat Enai zich in een reactie iets eerder in dit draadje het volgende afvraagt geeft in mijn ogen al aan dat je er niet veel van snapt...

Hangt ervan af welke van de twee het snelst tot ontslag leidt.

Bij de beveiliging van persoonsgegevens in een HR omgeving dit als argument gebruiken? Dan heb je er niet veel van begrepen, sterker nog volgens de wet ben je strafbaar wegens het niet toepassen van adequate beveiliging. ( wat het bewust niet toepassen van een patch voor een bekend lek gewoon is.)

De HR medewerker / Manager die mij om die reden 20x30 uitreikt kan zijn baas gaan vertellen dat er een dagvaarding gaat volgen, een manager cq werkgever mag mij namelijk niet vragen de wet te overtreden.

[R4gnax]

Weet niet wie Plopeye hier aan het downmodden is geslagen, maar dat is dus echt onterecht.

sterker nog volgens de wet ben je strafbaar wegens het niet toepassen van adequate beveiliging. ( wat het bewust niet toepassen van een patch voor een bekend lek gewoon is.)

De HR medewerker / Manager die mij om die reden 20x30 uitreikt kan zijn baas gaan vertellen dat er een dagvaarding gaat volgen, een manager cq werkgever mag mij namelijk niet vragen de wet te overtreden.

Bewust en ingecalculeerd een systeem lek laten omdat dat financieel of anderzins zakelijk beter uit komt, is v.z.i.w. inderdaad criminele nalatigheid. Dat kan als het uitkomt het bedrijf aardig schaden. Wanneer de beslissing voor dat soort beleid ook nog eens bij een leidinggevend persoon vandaan komt, is er dacht ik daarnaast nog de mogelijkheid om deze persoon zelf (dus op persoonlijke basis) ook nog strafrechtelijk te vervolgen.

Wat dat betreft moet je echt op je tellen letten.

[halofreak1990]

Persoonlijk heb ik liever een chagrijnige manager, dan een lek. 't Is maar waar je prioriteiten liggen.

[Enai]

Hangt ervan af welke van de twee het snelst tot ontslag leidt.

[Pietervs]

Geen van beiden: als je ontslagen wordt omdat het systeem gehackt wordt terwijl je aan kan tonen dat je niet MOCHT patchen, zal de discussie bij de rechter vrij kort zijn. En duur voor de werkgever.
Als je ontslagen wordt omdat een applicatie niet meer werkt na het installeren van standaard (beveiligings-)updates zal de discussie bij de rechter ook vrij kort zijn (tenzij je een aantal keren van te voren gewaarschuwd was de updates niet te installeren)...

Als de HR manager loopt te piepen over een systeem dat niet meer werkt na het plaatsen van een standaard beveiligingsupdate, wordt het tijd om de leverancier van de applicatie eens uit te nodigen. En ondertussen eens te informeren bij de concurrentie of zij wel hun systemen up-to-date hebben (al dan niet door middel van een per ongeluk verkeerd gestuurde mail naar de leverancier van je huidige pakket )

[mashell]

Echt? Je kiest voor het afdichten van een onbekend risico met een onbekend gevolg (dat mogelijk een hacker binnendring en mogelijk schade aanricht) in plaats het afdichten van een bekend risico met een bekend gevolg (boze HR manager, geen loonsverhiogingen bij IT)? Dat is een dappere keuze.

[Plopeye]

Ja, want het is erger wanneer het hoofd van de HR afdeling boos is dat custom applicatie X niet meer werkt vanwege een patch, dan wanneer hackers inbreken op een server. In dat laatste geval kun je namelijk altijd een verhaal ophangen dat hier niets tegen te doen was. Bij een chagrijnige manager wijzen echter alle vingers naar jou.

Er is ook niets aan te doen dat die brak gebouwde custom applicatie omvalt. En inderdaad geef mij die boze HR manager maar en een ieder die vingers wenst uit te steken om te wijzen is heel simpel voor mij...

Publiekelijk tot op je veters en ik zoek zelf wel een andere baan. Bij een werkgever die met mijn persoonsgegevens bewust zo slordig omgaat wil ik niet werken.

[kritischelezer]

Hoe stom ook, maar bij sommige ongelukken is het dragen van GEEN gordel een pre.
Gaat erom hoe meer libraries er gebruikt worden, hoe meer kans op een (onbekende) exploit. Daarnaast is er het gevoel van schijnveiligheid. Oh ik draag een gordel en heb airbags dus ik kan wat meer risico nemen. Hier. Aha mjjn browser zegt veilige verbinding, dus het is goed...

[Verwijderd]

Ik draag wel een autogordel maar ook die biedt geen garantie.

[Woutske]

Ik vind het wel opvallend dat zo veel kritieke bugs in SSL voorkomen, op zo veel platforms. Ik krijg bijna het idee dat het een afgesproken protocol was voor backdoors

Ik ben altijd benieuwd hoe een protocol zoals SSL het voor elkaar krijgt om door een 'domme fout' code uit te voeren. Het lijkt mij niet dat je 'zomaar' programma's gaat aanroepen op basis van een dergelijk protocol?

[Ick]

Meestal gaat dit over kwetsbaarheden als buffer overflow. De SSL implementatie start dus zelf geen applicatie, maar door een specifiek opgestelde invoer wordt er in geheugen geschreven dat niet beschreven had mogen worden. Op die plekken kan code staan die in een bepaalde situatie aangeroepen wordt. Als je dan op de juiste plek andere code schrijft wordt die code uitgevoerd. Je overschrijft dus een stukje van het programma. Meestal komt dit door een vergeten invoer controle voor een hele specifieke situatie.

Er zijn overigens vele soortgelijke aanvallen mogelijk een ik weet niet of het in dit geval over een buffer overflow gaat.

[HooksForFeet]

Volgens mij heeft Windows al sinds Windows XP SP2 DEP wat specifiek is ontwikkeld om dit soort buffer-overflow kwetsbaarheden te voorkomen, dus zou dat nog echt een probleem zijn dat bestaat?

[goarilla]

DEP is een NX implementatie. Dit houdt in dat men de address space van een process gaat markeren als Read, Executable, Writeable. Men kan dus niet van iedere bufferoverflow profiteren om uitvoerbare code te kunnen draaien. Enkel de buffers die zich bevinden in uitvoerbare code stukken. Het wordt overigens ook niet uitgevoerd op ieder process maar enkel op diegene die ermee om kunnen (Optin).

[PjotrX]

Hier betreft het niet om een bug in SSL protocol maar in de implementatie ervan van Microsoft.

[Woutske]

Nee begrijp ik, ik bedoelde ook de implementatie van het protocol

[Verwijderd]

Na Heartbleed en dergelijke kijken er momenteel ook meer mensen naar, dus komt er ook meer shit naar boven. Ik zie dat als iets positiefs.

[Maurits van Baerle]

Het is eigenlijk juist wel te verwachten. Doordat er één spraakmakend probleem was dat veel ruchtbaarheid heeft gekregen is iedereen zijn eigen SSL/TLS code (of die van anderen, waar mogelijk) gaan doorspitten om te kijken of er daar ook problemen zijn. Dan kun je er donder op zeggen dat er op vrijwel ieder platform wel iets wordt gevonden en één voor één komen die problemen nu aan het licht.

[kzin]

In elke software zitten fouten. Soms komt het omdat programmeurs niet alles goed overzien, soms zijn we ook te vriendelijk omdat anders 'de gebruiker er last van heeft'.
- Buffer overflow: Zeggen dat je 10 bytes stuurt, maar in werkelijkheid 80 bytes sturen. De extra bytes bevat uitvoerbare code en overschrijft andere uitvoerbare code, zoals lck al beschrijft.
- Heartbleed: Zeggen dat je 80 bytes stuurt, maar je stuurt slechts 10 bytes. Vervolgens wel 80 bytes terugsturen met data uit het geheugen. (als ik het goed begrepen heb)
- Invoervelden/URL's die niet controleren op speciale characters of character combinaties, als \n of ); Dit gaat soms pas fout in de achterliggende code.

In de meeste gevallen wordt geprobeerd de data die terugkomt zo goed mogelijk te parsen, terwijl je voor maximale veiligheid beter de communicatie met die client kunt stoppen, de poort sluiten en de thread kunt sluiten.

[jvdmeer]

Ter aanvulling van het artikel, het gaat om deze patch: MS14-066 of kb2992611

offtopic:
Zie nu pas dat de patch gelinkt is onder het woordje 'kwetsbaarheid', terwijl ik 'm verwachtte onder het woordje 'patch'

[Reactie gewijzigd door jvdmeer op 24 juli 2024 06:40]

[Armin]

En een extra leuke aanvulling is dat Microsoft voor Windows 7 en 8.0 en Server-equivalenten dit kennelijk deels als een backport van Windows 8.1.1 heeft uitgevoerd. Windows 8.1.1 (en Server-equivalent) bracht namelijk 4 nieuwe TLS 1.2 ciphers en een nieuwe default volgorde. Dat laatste is het meest interessant, want de server bepaald de gebruikte cipher, hash en key-exchange. Omdat de meeste administrators dit nooit wijzigen, is de default dus belangrijk.

Na uitvoeren van deze patch is de default zo ingesteld dat het standaard forward secrecy met AES 256 uitvoert, waar de oude default AES 128 zonder forward secrecy was. Iets soortgelijks gebeurde toen mensen massaal de HeartBleed repareerde en nieuwe OpenSSL versies gebruikten. O.a. Tweakers ondersteunde toen ook opeens forward secrecy.

(Op Vista heb ik het nog niet kunnen controleren. Dat ondersteunt geen TLS 1.2 dus zal de 4 nieuwe ciphers niet krijgen, maar wellicht dat de default wel aangepast is.)

En uiteraard heeft de marketing afdeling van Microsoft hier ook mooie spin aan gegeven

http://blogs.microsoft.co...best-in-class-encryption/

[woekele]

Hmmmm, op stel en sprong een server moeten patchen en rebooten tijdens productie is nooit fijn. Helemaal als je niet hebt kunnen testen of die patch geen andere problemen veroorzaakt. Redundantie zou fijn zijn

[Reactie gewijzigd door woekele op 24 juli 2024 06:40]

[Thystan]

Mooi om te zien dat er toch naar SSL over de gehele linie van besturingssytemen is gekeken dit jaar. Zou dit komen door de zomer van snowden?

[goarilla]

Wel in dat geval op naar het decennium van Snowden. Software wordt er alleen maar beter op .

[Amito]

Microsoft heeft op zijn traditionele patchronde op de tweede dinsdag van de maand een patch uitgerold voor de bug.

Is er inmiddels al iemand achter gekomen welke update (KB artikel) hierbij hoort? Kan het zelf niet zo 1-2-3 vinden welke het zou moeten zijn.

@Brummetje: bedankt!

[Reactie gewijzigd door Amito op 24 juli 2024 06:40]

[Brummetje]

Staat in de tekst het eerste linkje:

https://technet.microsoft.com/library/security/MS14-066

Gaat dus om KB2992611

@Amito: Your welcome

[Reactie gewijzigd door Brummetje op 24 juli 2024 06:40]

[Soldaatje]

Nou gelukkig maar, ik was al even bang dat Windows veiliger zou zijn dan Linux, gelukkig niet.

[REDSD]

Je word gedownmod, maar ik kan me voorstellen dat meer mensen dit dachten met het nieuws van de afgelopen tijd.
Het laat wel zien dat er geen perfect systeem is.

Ik vraag me af wat tegenwoordig de algemene opinie is over de verschillende os'en, welke vind men het betrouwbaars?

[MAX3400]

Ik vraag me af wat tegenwoordig de algemene opinie is over de verschillende os'en, welke vind men het betrouwbaars?

Betrouwbaarheid is een samenstelling van een heleboel factoren. Denk hierbij bijvoorbeeld aan "out of the box security", "performance", "uptime", "long term support" maar ook zaken die wat minder meetbaar zijn zoals "user experience".

Betrouwbaarheid van een OS kan je paar beoordelen als vergelijkbare OS'en eenzelfde taak kunnen uitvoeren en waarbij die taak zeer specifiek is vastgelegd in zowel functionele als technische vereisten.

Ondanks dat ikzelf ben opgeleid om voornamelijk met Windows-machines om te gaan, denk ik zeker wel een lans te kunnen breken voor een Linux-installatie; zeker als mijn opdrachtgever met zeer specifieke functionele of technische vereisten komt waarbinnen zijn/haar verwachtingen liggen.

[goarilla]

Persoonlijk zou ik gaan voor RHEL Linux want het feit is dat de meeste updates van Windows een reboot vragen terwijl bij Linux een herstart van de geupdate services voldoende is.

Genoeg machines met hoge uptimes waarvan men niet weet of ze een reboot zouden overleven. Deze Linux machines hebben soms wel wat updates achter de rug maar bij de Windows machines is windows update pertinent op uitgeschakeld en nooit uitgevoerd sinds installatie.

Het zou niet mogen, maar dat is mijn ervaring.

[geertdo]

want het feit is dat de meeste updates van Windows een reboot vragen terwijl bij Linux een herstart van de geupdate services voldoende is.

Dat is niet mijn beleving, als ik zie hoeveel updates er zijn. 't Is eerder andersom.

Machines waar Windows Update is uitgeschakeld? Kom ik al jaren niet meer tegen.

En machines die een update niet overleven is in mijn ervaring: nooit
Ik vraag me af wat voor 'ervaring' je dan hebt (en uit welk jaar).

[Blokker_1999]

Het aantal keren dat je een linux volledig moet herstarten is verdomd klein te noemen. Bij Windows heb je het bij elke update ronde wel zitten. Ik heb linux machines met een uptime van meerdere jaren, moet jij eens proberen met Windows. Bij Windows kom je soms met 1 enkele reboot zelfs niet toe. Dan worden updates geïnstalleerd bij het afsluiten, verder geconfigureerd bij het heropstarten waarna Windows beslist om voor de zekerheid het systeem nog maar eens te herstarten.

Servers waar Windows Update staat uitgeschakeld bestaan zeker, en bij consumenten komt het nog meer voor. Hoeveel mensen zijn er hier niet die ofwel niet durven upgraden omdat ze een gekraakte versie hebben danwel dat ze niet durven omdat een update ook wel eens durft mis te gaan. Als jij ze niet tegenkomt is het eigenlijk een klein mirakel. Binnen een bedrijf worden updates vaak zelfs via een eigen server gedownload en ook pas enkel nadat ze door de eigen IT dienst zijn goedgekeurd.

[geertdo]

Mooi verhaal, maar dat maakt het geen feit dan 'bij de meeste Windows Updates een reboot nodig is'.

Gekraakte versies hou ik geen rekening mee inderdaad en WSUS updates zijn ook updates.

[goarilla]

Mooi verhaal, maar dat maakt het geen feit dan 'bij de meeste Windows Updates een reboot nodig is'.

Maar Windows Update komt het wel altijd melden. Evenals de Security bulletins: https://technet.microsoft...ry/security/ms14-nov.aspx. Mag je dit dan in de wind slaan ? Doe jij dat ?

[[Yellow]]

Ik ken het percentage niet, maar hoevaak zie je tijdens een reboot niet de melding 'installing updates' voorbij komen?
In mijn beleving redelijk vaak, alhoewel het voor windows servers lager lijkt (maar komt misschien ook omdat die minder vaak updates hebben)

[Pietervs]

Mooi verhaal, maar dat maakt het geen feit dan 'bij de meeste Windows Updates een reboot nodig is'.
Sorry, maar alleen al voor nagenoeg ALLE .NET (net-niks) updates moeten machines gereboot worden.
Geen idee hoe lang jij al in het beheer zit, maar in de 20 jaar dat ik er nu in meeloop zie ik dat het aantal herstarts bij Microsoft inderdaad wel afneemt, maar het helaas nog steeds vrij standaard is dat de Windows-machines na nagenoeg iedere patch-Tuesday herstart "mogen" worden. Het feit dat Google en Adobe tegenwoordig ook meegenomen worden in die updates helpt daar natuurlijk ook aan mee.

[geertdo]

Lezen svp. 'de meeste' updates vereisen geen reboot.
Dat er maar één bij hoeft te zitten die een reboot vereist maakt de stelling nog niet juist.

[Pietervs]

Lezen svp. 'de meeste' updates vereisen geen reboot.
Het feit dat "de meeste" geen reboot vereisen, maar je aan het eind van de dag toch weer de lul bent om te rebooten doet het hele update-proces volledig de das om.
Simpel voorbeeldje: je kan wel roepen dat je met 300 kilometer per uur in een uurtje van Maastricht naar Groningen kan rijden, maar gezien de wettelijke beperkingen en de drukte op de wegen mag je blij zijn als je 80 haalt. Ja, je kan 300 halen. Maar nee, in de praktijk moet je er nog steeds een goede 3 uur voor uittrekken. Dus dan is het leuk dat je 300 kan, in de praktijk is het nut: 0.

Zo ook de updates van Microsoft: "de meeste" updates (overigens lekker vaag begrip, waar ik mijn twijfels bij heb) vereisen volgens jou geen herstart, in de praktijk is het nut daarvan 0, omdat er altijd minstens 1 a 2 bij zitten die wel een herstart vereisen...

[goarilla]

Dat is niet mijn beleving, als ik zie hoeveel updates er zijn. 't Is eerder andersom.

Enkel kernel updates en kernel updates relevant voor je systeem vereisen een reboot.

En machines die een update niet overleven is in mijn ervaring: nooit
Ik vraag me af wat voor 'ervaring' je dan hebt (en uit welk jaar).

Wel ik zit in de academische wereld in een niche ingenieursrichting, een wereld waar m'n IT als kostenpost ziet. Waarin iedere cent in IT er een is die niet in "onderzoek" kan worden gestopt. Waar er tientallen professoren (bazen) en onderzoeksgroepen zitten.

Het gaat hier niet om dat IIS of AD rollen niet starten.
Wij hebben een Windows Server 2008 R2 licentieserver.
Deze server wordt niet geupdate want bij reboot is het vaak zo dat de flexlm licentieservers niet opstarten. Licentieservers voor software van 10-15K/jaar per stuk.

[KoeKk]

En ligt dat aan Windows, of aan FlexLM? (Hint: FlexLM is het juiste antwoord)

Maak niet de fout om het bij het system neer te leggen als het aan een product van een 3e partij ligt.

Verder wordt IT in meer dan 80% van de bedrijven als een kostenpost gezien (Want dat is het over het algemeen ook). Daarnaast is je specifieke probleem op te lossen met een scriptje van 3 regels, en/of de FlexLM services anders in te stellen. De machine 'dan maar niet updaten' is gewoon de slechtste workaround die je kan kiezen, en kan de organisatie meer winnen door een echte systeembeheerder in te huren.

[goarilla]

De machine 'dan maar niet updaten' is gewoon de slechtste workaround die je kan kiezen, en kan de organisatie meer winnen door een echte systeembeheerder in te huren.

Het probleem is dat ze niet zien dat er slecht systeembeheer is wanneer een Windows Server essentieel bevroren wordt qua software. Ze zien alleen uitstekende always on service. Maar kom, dit is ook eerder een uiting van mijn persoonlijke overwerkte frustraties met Windows Server en FlexLM.

[Reactie gewijzigd door goarilla op 24 juli 2024 06:40]

[KoeKk]

Hahaha, ach als ze dat al niet zien... Maar ik snap je gevoel dan helemaal, fuck FlexLM...

[djwice]

[...]
Het probleem is dat ze niet zien dat er slecht systeembeheer is wanneer een Windows Server essentieel bevroren wordt qua software. Ze zien alleen uitstekende always on service. Maar kom, dit is ook eerder een uiting van mijn persoonlijke overwerkte frustraties met Windows Server en FlexLM.

Wellicht eens FlexLM updaten?

27 aug. 2012 - FLEXlm has been replaced by FlexNet Publisher.

maar wat een bagger is het, ik leef met je mee :

Due to the way the digital rights management (DRM) works in FlexNet Publisher, FlexNet affects bootloaders; this makes FlexNet Publisher incompatible with drives encrypted with TrueCrypt and renders Linux-based systems unable to boot.

[goarilla]

Wellicht eens FlexLM updaten?

Idealiter zou ik denk ik de nieuwste FlexLM moeten kunnen draaien en dat word dan het harnas van alle vendorspecifieke daemons. Dit heb ik echter nooit werkende gekregen (het moet snel gaan niet goed).

Dus nu in de realiteit wordt bij iedere vendor daemon een eigen specifieke FlexLM gegeven die ik dan laat opstarten via een script met task scheduler onder een eigen user-account. Eerst draaide het als SYSTEM of Administrator, ik denk dat dit niet de bedoeling is (tips hieromtrend zijn altijd welkom - ik ben een Linux'er).

Dus er draaien 4 flexlm processen op elk hun eigen poort en elk hun eigen daemon . Alle 4 flexlm processen zijn tevens uitgegeven door een andere publisher (Flexera, Acresso, Macrovision, Reprise (een fork/opvolger)), nochtans zitten ze qua versienummer heel dicht bij elkaar .

Nu Safenet Sentinel is niet veel beter.

[Zezura]

zullen we het anders allemaal weer zonder IT gaan doen, eens kijken wat men dan ziet als kosten post.

geen flamebite!, maar ICT en automatisering wordt nu vortaan als kostenpost gezien, maar als we het zouden afschaffen zou iedereen het missen + zouden productie kosten weer flink omhoog gaan.

want werken met de computer win je toch veel mee, dan alles met de hand en met de koerier van hier naar daar.

het is gewoon niet meer weg te denken vandaag de dag, en daarom zijn veel bedrijven IT juist niet meer dankbaar, maar zo gauw als ze het zou wegvallen dan piepen ze wel anders.

[KoeKk]

Tja, helemaal mee eens, punt is wel dat als IT voor een bedrijf geen directe bron van inkomsten is, het dus een kostenpost is. Dit houd ook in dat het als zodanig behandeld moet worden, maar het moet wel de juiste aandacht krijgen. Als de leidinggevende laag beseft dat IT een tool is waarmeee je sneller en efficienter kan werken is dit juist een plus voor een bedrijf. Helaas is IT complexe materie, waarbij het moeilijk kan zijn om iedereen te overtuigen van het nut. Dit levert dan vaak weer arbitraire beslissingen op, die een juiste toepassing van IT weer in de weg staat.

Maar goed, dat is makkelijk praten, ik werk bij een bedrijf waar IT het product is.

[rob12424]

Wees gerust. Men is er eindelijk van bewust geworden dat kennis meer waard is dan geld aan het einde van de rit. Ik werk ook in de Akademische wereld en de wijze waarop er naar ICT wordt gekeken is in de afgelopen 1,5 jaar drastisch aan het veranderen.

Maar idd het is een draak als je een database programma op win 95 hebt draaien en niet kunt updaten omdat het niet meer compatible is met vorige versies en je dus niet meer bij je onderzoeksdata kan als je update (bij ons hangen die dus ook niet meer aan internet, wil je dat wel? Goed kosten voor de groep en onderhoud mogen ze ook zelf doen! )

[mae-t.net]

Als van een machine niet duidelijk is of hij een reboot overleeft, is niet rebooten puur uitstel van executie. Op enig moment is hij dan zodanig gaar dat hij het zonder reboot ook begeeft.

[xleeuwx]

neu denk eerder dat de running config anders is als de startup config, die daarna dermate veranderd is dat deze na een reboot niet meer werkt.

[EraYaN]

Dat is op zich niet zo'n goed plan lijkt me dan.. Er zijn meerdere redenen waarom men een running config zou moeten opslaan...

[mae-t.net]

Dat valt wat mij betreft ook onder gaar, alleen dan is de software matig inplaats van de hardware.

[xleeuwx]

Zeker

[Verwijderd]

Mijn Debian Linux servers hebben allemaal een hoge uptime, en zijn allemaal up to date. Ook voor een kernel update hoeft een Debian server geen reboot te hebben. Mijn Ubuntu desktop machine moet dat wel af en toe, maar ik heb nog niet uitgezocht wat het verschil is (de desktop gaat toch iedere dag uit als ik naar mijn werk ga).

We houden op het werk momenteel een uptime wedstrijd, mijn twee Linux doosjes (special cases Zabbix en Mediawiki / ticketsysteem) tegenover het hele Windows serverpark. En mijn up to date Linux doosjes staan bovenaan. Die redden het echter niet als we mijn eigen Debian webserver bij Hetzner erbij pakken. Op het werk hadden we 99 dagen geleden een stroomstoring waarbij de ups-en faalden (dat is natuurlijk inmiddels wel opgelost).

De Windows machines hebben een uptime van een dag na updates gisteren, en zullen ook het weekend niet halen. De centos Xenservers waar de hele meuk op draait staan uiteraard bovenaan, samen met .. Mijn Debian boxjes, sinds de stroomstoring met Hemelvaart.

Het klopt dus niet dat Windows minder moet herstarten dan Linux, als we het over servers hebben ...

[PowerToTheUsers]

Qua security kan je niet enkel vertrouwen op de betrouwbaarheid van het operating system. De betrouwbaarheid van applicaties die er op draaien, het gedrag van de eindgebruiker (telkens ja-klikken is niet de schuld van het OS, maar de eindgebruiker die zich niets aantrekt van security) etc heeft minstens evenveel impact.

Wat is trouwens het betrouwbaarst: een OS waar men problemen vindt en ze oplost, of een OS waar geen problemen van gekend zijn? Is dat dan een zekerheid dat er geen problemen zijn? Hoe betrouwbaar klasseer je dat OS dan? En zou je het dan iedereen aanraden enkel en alleen omdat van het OS zelf geen problemen gekend zijn?

[mae-t.net]

Een OS waar geen problemen van gekend zijn moet als onveilig worden beschouwd als het te weinig gebruikt werd om problemen fatsoenlijk te kunnen ontdekken. Als het gebruikt en getest werd, gaat het niet om een OS waarvan geen problemen gekend zijn, maar om een OS dat weinig (geen bestaat niet) problemen heeft.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 06:40]

[kritischelezer]

Ja zelfde gedachte, maar ook dat het voeren van een website http "veiliger" kan zijn dan https.

[FrankGNL]

Weet iemand of dit ook geldt als je webserver achter een reverse proxy hangt?

[Verwijderd]

Er is helaas een herstart nodig voor de patch, gelijk alles aan het aflopen.

[Eupeodes]

Dat is toch standaard bij Patch Tuesday?

[MAX3400]

Nee, niet elke patch of hoeveelheid patches op dag X hoeft in te grijpen op zaken die een herstart vereisen. Het kan namelijk ook zonder problemen voorkomen dat de zogenaamde Patch Tuesday alleen voor specifieke systemen kritieke updates bevat en voor andere systemen geen en/of recommended updates (zoals een Windows Defender Definition).

[Yggdrasil]

Klopt, maar dat komt in de praktijk toch niet echt voor. Tussen het dozijn patches zitten er eigenlijk altijd enkele die een herstart vereisen.

[Enai]

Tja, dan komt deze patch over een maand of twee wel aan de beurt.

[HansvDr]

Als een herstart al een probleem oplevert moet je misschien je infrastructuur aanpassen en zorgen voor failover.

Want een herstart duurt maar even, een kapot moederbord daarentegen....

[R4gnax]

Welkom in de wereld van Windows, zou ik zeggen...

Liever een herstart en 5 minuten later terug up zijn met gegarandeerd de exploit gepatched, dan een *nix proces dat seamless 'gepatched' wordt en vervolgens vrolijk nog met een extra maandje uptime ongepatched blijft doordraaien omdat draaiende instances niet mee bijgewerkt worden,

zou ik zeggen...