Kunnen ze de exploit niet gebruiken om de Windows servers wereldwijd te patchen?

Of tenminste off-line te halen, met een pop-up/bericht/log dat de machine een zeer kritiek gat bevat?

Het ramp-scenario is deze exploit i.c.m. ransomware.

O god. het is weer patch Tuesday. Dat betekent weer de gebruikelijke kritieke lekken. Zo af en toe ala, maar een systeem dat elke maand kritiek lek is kan je toch niet meer met respect voor de klant in een professionele omgeving inzetten? Wordt tijd dat die ransomware criminelen hier eens een keer een eind aan maken. Helaas gaat dat niet gebeuren want dan halen ze hun eigen verdienmodel onderuit, en de nietsvermoedende burger maar betalen.

Normaal gesproken houdt MS zelfgevonden bugs onder de pet (niet voor niks closed source) maar deze (willekeurige code met kernelrechten uitvoeren zonder dat de gebruiker iets hoeft te doen) achterhouden konden ze niet maken.

Allsj blieft zeg ... dan hebben we straks ipv een telefoon loos leve een serverloos leven :) Wel klimaat vriendelijk natuurlijk. Ik hou mijn hart al vast als er weer patches uitgerold worden want niemand kan foutloos werken. Het is wachten op een issue die letterlijk alles plat gooit.

Jajaja dat zou ontdekt moeten worden in het lab teststraten etc... Maar je hebt nooit de praktijk in een lab.

Wat kan wel volgens U?
Patchen per maand? Kwartaal? Half Jaar? Jaarlijks?
En de kritieke patches in dit schema meenemen?

Elk OS heeft vrijwel dagelijkse/wekelijkse/maandelijkse patches.. Windows is daar geen vreemde in.
Het maakt het juist makkelijker om hier rekening mee te houden, in plaats van updates maar willekeurig de lucht in te schieten.

En nee, leuk is anders soms. Dat ben ik dan wel weer met je eens.....

De HTTP protocol stack draait in Windows met kernelrechten??????
Okeeeeej....

Valt nog mee, enkel voor versie 2004 en 20H2 (server en Win10).
Dus enkel de recentere windows core versies. Dus volgens mij niet van toepassing op Windows 2016/2019 gui installaties. Of oudere core installaties.

Volgens mij is die HyperV CVE-2021-28476 veel erger met een score van 9,9! Windows systeembeheerder zijn is tegenwoordig geen pretje meer want ze rollen vaak van het ene in het andere probleem (gelukkig kan je tegenwoordig snapshots maken). Misschien moeten die eens een keer in het zonnetje worden gezet.

Kijk dit is ook een reden dat mensen niet direct willen updaten, terwijl het wel zou moeten: https://www.theregister.com/2021/05/12/outlook_outage_patch/ Notabene een eigen product.

Bij elke lek met cvss3 hoger dan 9 moet MS gelijk een boete krijgen van 1 euro / geinstalleerde machine

Verplicht gesteld door de open software www. Alles wat met poortnummer lager dan 1024 binnenkomt moet verplicht met rootrechten draaien. Een fundamenteel probleem in de tijd toen men de computers met moeite aan de praat kreeg en niet dacht aan een veilig ontwerp (1970).

Heel veel draait er in windows in kernel mode anders wordt het nog trager of is er niet mee te werken (indexing service is al uitgezet sinds het Vista debakel)
In dit geval ( http.sys ): Requests for cached responses are served without switching to user mode. Dat spaart dure context switching. Vroeger gebruikte men tenminste nog Winsock, dat was nog een user mode component.
Printer drivers doen het ook heel veel in kernel mode anders werkt het niet. Zelfs grafische dingen hebben ze in kernel mode gestopt sinds NT4.

Wat een onzin! Een webserver draait onder Linux als nobody, niks root rechten.
Hier staat waarom MS deze domme keuze zelf heeft gemaakt (snelheidswinst): https://docs.microsoft.com/en-us/iis/get-started/introduction-to-iis/introduction-to-iis-architecture

ik zeg FUD totdat er een referentie is gegeven want ik wete zeker dat mijn apache op RHEL luisterd op poort 80 maar NIET als root draait en onderhevig is aan SELinux.

Wel vreemd dan al die Apache vulnerabilities?! https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-66/Apache-Http-Server.html

Je weet dat Karma4 alwetend is en altijd gelijk heeft?
Voor degenen die nog niet zo wijs zijn en dus nog kunnen leren:
http://httpd.apache.org/docs/2.4/invoking.html
https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html

Nobody bestaat niet onder linux, id-jes root=0 systemd je moet er mee gewerkt hebben met all security uitdagingen om het te begrijpen. Daar gaan velen de mist in met het wijzen naar anderen.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/chap-managing_services_with_systemd

Zoek wat beter naar die domme keuze je komt echt uit bij: https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html, https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Daemon/User/PrivilegedPorts.html Die kernel mode in dat plaatje is een gevolg van die open standaarden. Nergens in je lnk staat dat het wegen performance redenen gedaan zou zijn. Draaien onder root want dan doet hij het .... komt uit de linux snel klaar afleveren aanpak.

Vooral geen security by design want dat is te lastig. Dat is mijn ervaring, jij onderbouwt die ervaring. Geen alternatief hoe het dan wel zou moeten enkel dat die ander het niet goed zou doen.

Leuk geprobeerd Karma4, maar uit je eigen link:

Under Unix

The Internet Daemon inetd (running as root) can listen for incomming conections on port 80 and pass them down to a process with a safer uid for the server itself. However, the httpd versions 2.14 and later can be safely run as root since they automatically change their user-id to nobody or some other user-id depending on server setup.

En waar staat dat Windows dit voorbeeld moet volgen? En sinds wanneer is het draaien als root hetzelfde als draaien in kernel mode?

Bovendien doe je weer eens aan whataboutism, in plaats van toe te geven dat dit gewoon een kwetsbaarheid is in Windows.

Het is je al diverse keren uitgelegd (op verschillende sites). Of je snapt het echt niet of je blijft bewust doortrollen omdat windows er positief van af moet komen. De webservers van www.microsoft.com draaien niet voor niets onder Linux: https://sitereport.netcraft.com/?url=https%3A%2F%2Fwww.microsoft.com

Ofschoon de webserver (apache,nginx etc) opgestart wordt als root, draaien de workers (die de requests afhandelen) niet als root maar als nobody of een willekeurige ander non-privileged user). Die gebruiker kan ook niet inloggen (jailed login).
Dit is een van de voordelen van een webserver op Linux boven windows.
Verdiep je eens een keer in UNIX!: It will spawn child processes and drop privileges for handling requests.

PS inetd en de secure replacement xinetd zijn oud. De meeste distro's gebruiken nu systemd om services op te starten.
systemd is begonnen als een init system. Tegenwoordig gebruikt men ook een supervisord (uiteraard opgestart door systemd) als een process control system om webapps (non root users) te managen. Onthoudt deze combinatie maar even want veel websites (webapps) gebruiken het en het draait niet onder windows: supervisor/django/gunicorn
Het grote voordeel is dat als er een app is gehackt, de app user geen enkele rechten heeft behalve toegang tot de files van deze user. Onder windows zou gelijk de hele machine zijn gehackt en dus versleuteld zijn. Daarom zijn we nog geen versleutelde Linux BSD etc tegengekomen terwijl bijna alle webservers Linux zijn.

Dat het Microsoft om de performance is te doen i.p.v.security staat wel degelijk in het genoemde document:
HTTP.sys provides the following benefits:
Kernel-mode caching. Requests for cached responses are served without switching to user mode.
Kernel-mode request queuing. Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process.
Hier gaan we helaas nog plezier aan beleven.

Dit heb je al ettelijke keren beweerd en het is al ettelijke keren onderuit gehaald. Alleen het openen van de poort vereist bijzondere rechten. Vanouds kwam je dan inderdaad bij root uit, maar aangezien een proces zijn rechten kan verlagen kan het netwerkverkeer dat vervolgens over die poort plaatsvindt onder een user met beperkte rechten gebeuren - en zo wordt dat ook gedaan. Daarnaast zijn tegenwoordig ook andere mechanismen beschikbaar waarmee hetzelfde bereikt kan worden. Wat je stelt is domweg niet waar, en na daar al vele keren op gewezen te zijn zou je dat zo langzamerhand moeten weten.

Je geeft oe dat die richtlijn er is en de praktijkervaring leert dat een gescheiden security context niet ingevuld wordt.
De paniek rond shellshock gaf aan dat er geen securitycontext scheiding is. Even wat extra inputvalidatie zonder aan het onderliggende probleem te werken. Bedenk dat als je elke website elk service geheel gescheiden wil inrichten je een boel service accounts nodig hebt. Die serviceaccounts worden opgesoupeerd door docker.
Je zou intussen moeten weten dat je niet elke bewering moet geloven dat het veilig is omdat iedereen het zo doet,

Proest .. Iot SMBV1 (pas in 2016 een aanpassing in Linux) de Nassen die gehackt worden webshells. Android dat geblokt raakt. Zorg nu eerst eens dat je eigen omgeving goed wordt. Je wordt er zelf echt iet beter van als je eigen toko moet promoten om af te geven op een ander. Citrix en pulse secure vergeten?

Je lult nu voor de derde keer uit je nek en je bent aan het trollen karma4. Shellshock was 7 jaar geleden een bash probleem en heeft helemaal niets met de http stack te maken waar dit topic over gaat. Service accounts opgesoupeerd door docker!
Je raaskalkt weer. Docker heeft helemaal niets met de http stack te maken, laat staan dat alle accounts worden opgemaakt (dat is trouwens altijd beter dan 1 windows admin account!). Daarnaast werken de meeste websites niet eens met docker en is Docker populairder bij MS dan in de Linux gemeenschap. Dat het veilig is omdat iedereen het zo doet is een karma4 verzinsels. Vervolgens troll je gewoon verder. SMB is geen Linux, maar een dramatisch windows service gebleken (WannaCry). Citrix en Pulse Secure zijn closed source oplossingen, daarvoor moet je bij die leveranciers zijn. Heeft 0% met het topic te maken, evenals de NASsen die jij bedoelt (closed source plus eigen OS)
Kortom een onsamenhangend waardeloos betoog en 100% offtopic.
Het topic gaat over een immens windows probleem, aub daar op reageren en niet wegtrollen!
Het is de keuze van MS geweest om het geheel in kernel mode af te handelen (tekst van Microsoft: responses are served without switching to user mode) om performance winst te behalen ipv security! Als jij security hoog in het vaandel hebt staan, wat jij steeds beweert hier, zou je dat moeten afkeuren. In tegendeel, je gaat andere systemen die wel voor security kiezen afzeiken met info die ook nog eens feitelijk onjuist zijn. Bah wat een armoe.

Proest...SMB is een Microsoft protocol.

Ik hou er niet van om op de man te spelen en je bent vast goed in het beheren van een Windows AD omgeving maar van Unix/Linux heb je duidelijk geen verstand.

Daarnaast gaat dit artikel over een Windows kwetsbaarheid, niet over Unix/Linux.

Met root kun je bij elk kernel proces, met de juiste tools of scripts.

/proc is toegankelijk als je root bent, en je kunt daar gewoon met je 'normale' tools in editen. Zo ook in /tmp

Remember folks: in unix is alles een file.

ik weet het is niet heel belangrijk, maar historisch gezien, de originele versies/varianten kwamen van IBM. Dat was in het DOS tijdperk en Microsoft heeft toen al grootte wijzigingen aangemaakt.

De nieuwere versies (2.x, 3.x ) komen uit de pijp van Microsoft.

Je weerspreekt zijn stelling niet. het is namelijk appels met peren vergelijken.
Wat we volgens jou moeten onthouden slaat als een tang op een varken, maar het is wel een geweldige vondst. in windows is alles een object, minder pragmatisch maar ook mooi bedacht.

Lol en ze hebben nog steeds het licht niet gezien.

Alle systemen zijn ook na deze patch lek.

Ze lijken het maar niet te begrypen. Ga maar verder met de digitalisatie de ramp wordt alleen maar groter.

Hoeveel signalen moet je krijgen?

grep nobody /etc/passwd
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

Bestaat WEL dus. En systemd is een grote ramp, een soort van COVID-19 voor Linux (de grote verWindowsifering), maar dat betekent nog niet dat het waar is wat jij denkt en schrijft.

Apart dat je dat als toegeven bestempelt, alsof de enige twee mogelijke posities die je kan innemen zijn om alles wat jij beweert volledig tegen te spreken of volledig te accepteren.

In werkelijkheid is er inderdaad een richtlijn om niet iedere gebruiker poorten lager dan 1024 te laten alloceren, maar de conclusie die jij eraan verbindt dat alles onder root draait klopt niet. Laat dat eens tot je doordringen.

Helemaal niet. De paniek kwam voort uit het feit dat het kunnen uitvoeren van willekeurige commando's met de rechten van een serviceaccount zelf al zeer problematisch is. Los van dat dat toegang geeft waar de serviceaccount toegang toe heeft, wat al vervelende consequenties kan hebben, betekent het kunnen uitvoeren van willekeurige commando's uit dat eventueel aanwezige lekken die local privilage escalation mogelijk maken opeens ook remote geëxploiteerd kunnen worden.

Als je deamonsoftware installeert op elke Linux-distro die ik ken wordt er volautomatisch een serviceaccount voor aangemaakt en wordt die volautomatisch gebruikt. De Linux-kernel kan miljarden accounts aan (al zal je de krapper gestelde defaults voor useradd in een configuratiebestandje even moeten aanpassen als je niet genoeg hebt aan zo'n 60.000 accounts), dus met dat opsouperen loopt het wel los.
Jij zou ondertussen moeten weten dat je dingen beweert die niet kloppen, je bent er vaak genoeg op gewezen. Je hoeft anderen niet op hun woord te geloven, je kan zelf verifiëren dat het zo is. Ben je zo overtuigd van je eigen gelijk dat je vindt dat je dat over kan slaan, of overstijgt het werkelijk zelf doen van dit soort dingen je capaciteiten?

Installeer Linux (bijvoorbeeld in een VM), installeer apache2 en zie voor je ogen gebeuren dat er een service-account voor wordt aangemaakt en dat apache2 daar ook onder draait. Probeer dat ook eens met Postfix, en je ziet hetzelfde. Bij ssh zie je dat de deamon als root draait en dat voordat een shell (zoals bash) wordt gestart de rechten worden verlaagd naar de zojuist aangelogde gebruiker. Het is steeds zo dat alleen de logica die ook echt root-rechten nodig heeft als root draait, en daarna onmiddelijk wordt overgestapt naar een account met minder rechten om daarmee requests en sessies af te handelen. Die hebben geen toegang meer tot root-rechten, en daar gaat het om.

Als op een systeem zelf ontwikkelde daemons draaien is het zo simpel om er een user voor aan te maken (door één commando uit te voeren) en in de systemd-servicefile de regel "User=..." op te nemen, en daarmee wordt die onder die user opgestart.
Op Debian en afgeleiden draait apache2 onder user www-data. Er bestaat wel degelijk een nobody-user, met minimale rechten, geen eigen home-directory en geen default-shell, die bedoeld is voor daemons die geen bestanden aanmaken of wijzigen.

Als je voldoende met systemd gewerkt had om het een klein beetje te begrijpen had je "user=..." in service-definitiefiles gekend en niet de zoveelste onwaarheid erover gespuid.

Het bericht waarop we hier reageren geeft aan dat in Windows de http-protocolstack kennelijk met kernelrechten draait. De recente problemen met Exchange maakten duidelijk dat dat onder de localsystem-account draait in plaats van een serviceaccount. Dit zijn dingen die Microsoft zelf zo inricht, niet eens dingen die incompetente beheerders veroorzaken. De manier waarop jij je in kronkels wringt om maar te kunnen doen alsof dit aan "de open software www" (wat dat ook mag zijn) of aan Linux ligt, in plaats van aan waar dit werkelijk optreedt, is ronduit bizar.

De kernel draait in ring 0 (kernel mode) en root werkt net als andere users in ring 3 (user mode). Er is dus een verschil van rechten op hardwareniveau. Zonder tegen te spreken wat root allemaal kan is het wel degelijk waar dat kernel mode en root-rechten verschillende dingen zijn.

Je toont enkel je onkende over systeemontwerp en hoe je daar met segmentatie de boel veilig moet houden.
Protocollen.https://en.wikipedia.org/wiki/OSI_model je moet aan de basis gesleuteld hebben om ze te begrijpen.
Was in de eerste jaren gewoon vereiste kennis, Daar refereer ik naar. In de media-layer (de poort hardware aansturing) ga je geen buffering in userland doen. Het hoort in de onderlaag met preemptive gedrag in de code. Het is een andere manier van met software omgaan dan zo maar wat code kloppen. Data was een van de onderwerpen bij E.Dijkstra.

Elke laag hoort volledig gescheiden van dan andere te zijn, enkel een api als interface.Het gaat op security gebeid echt mis indien daar wegen omheen te vinden zijn. Voor de scheiding heb je het beste afgescheiden security-contexts.

Deze zelfde gelaagdheid zie overal weer terugkomen als ontwerp in systemen, de laatste trend met microservices is niet veel anders. Tevens dezelfde soort fouten die zich blijven herhalen: - de paden er om heen, geen afgescheiden security context, de snelle oplossing bij de bouw alle eisen van scheiding negeren want het werkt toch en is veel goedkoper.

SMB een microsoftprotocol? Je kent de historie duidelijk niet. "The protocol that Samba implements was first invented by Barry Feigenbaum at IBM in early 1983. He initially called it the "BAF" protocol after his initials, but changed the name to "SMB" before the first official release. You may note that the name "Samba" contains the letters "SMB", and that is not a coincidence." https://www.samba.org/samba/docs/myths_about_samba.html De achtergrond van SMB-v1 is echt IBM https://cifs.com/

https://owasp.org/www-pdf-archive/Shellshock_-_Tudor_Enache.pdf open het publieke net en zo als root via bash naar binnen. Wat doet bash in hemelsnaam daar als scheiding tussen functionele lagen.
Veel te veel functionaliteit, wel snel werkend te maken.

Voor het andere als voorbeeld: https://www.tecmint.com/install-apache-web-server-in-a-docker-container/ Snelle uitrol maar geheel afhankelijk van wat daar een ander gedaan heeft. Je krijgt in grotere gebundelde software rare afhankelijkheden.
Als je daar nog niet tegen aan gelopen bent dan werk je niet echt met dat soort systemen.

Het wordt steeds gekker met jou. Je snapt en niks van UNIX en je bent geen security man anders had je de Microsoft implementatie van http.sys wel veroordeeld i.p.v. naar systemen wijzen die het wel goed hebben geïmplementeerd. Vervolgens kom je ineens met OSI ref model op de proppen. Ook weer totaal offtopic. Over het scheiden van oppervlakken gesproken. Heb je al eens bestudeerd hoe je onder LInux de GUI er met 1 commando uit haalt en hoe dat onder Windows moet? Voor de zoveelste keer houd je eens bij het onderwerp!

Een hard reboot is iets dat veel doet.

vulnix

De quote komt uit een boek uit een ver verleden 'Practical Unix'. En wanneer je snapt dat alles in unix een file is, dan begrijp je ook hoe networking, sockets, streams, pipes, etc werken.

Bovenop unix-like systemen kun je alles bouwen, dus ook object-geörienteerde talen.

UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity - Dennis Ritchie

Als alles een file is zou je ook een proces eenvoudig moeten kunnen copieren. Volgens mij kan dat niet maar misschien in plan 9 tegenwoordig wel?

Inderdaad en bij hun eigen internetbrowser hebben ze ook allang de handdoek in de ring gegooid. Edge is tegenwoordig gewoon een Chromium variant, waarmee Microsoft duidelijk aantoont en toegeeft zelf geen professionele software te kunnen ontwikkelen. Het miljoenenbedrijf dat zich genoodzaakt ziet om op een open source webbrowser te gaan verder bouwen. De blamage :-)

Dan lijkt mij wel dat het voor alle software leveranciers moet gelden, niet alleen Microsoft?
Dus ook voor alle open-source projectjes? Of kunnen die de boetes niet betalen, maar wel de schade maken?
Misschien moet je werken met een boete in percentage van omzet/winst?

En is het dan de software leverancier, of de hardware leverancier die de software meelevert? Bv. bij IoT waar je geen updates kan installeren? Of verouderde smartphones?

Die hebben niet elke maand een 9 te pakken!

Het zit 'm niet in de grootte van de maker v.d. software, het zit 'm in de bereidheid en snelheid waarmee patches worden uitgebracht. Een groot bedrijf heeft de middelen om zoiets snel en goed te doen. Zich verschuilen achter bv. 'patch Tuesday', nalaten een fatsoenlijk mechanisme voor updates aan te bieden, etc. kan écht niet meer, in deze tijd van malware, ransomware, hacks.