Debugger Windows 2000 geeft administrator-access

Extreme Tech meldt dat er een veiligheidslek is ontdekt in Windows NT en Windows 2000. Door middel van de debugging interface is het voor elke gebruiker mogelijk om administrator-access te verkrijgen. Hierdoor zijn de besturingssystemen ook kwetsbaarder voor aanvallen van buitenaf, aangezien een indringer, die als ongeautoriseerd gebruiker toegang heeft gekregen, zichzelf administrator rechten en daarmee volledige controle over het systeem kan geven. De exploit maakt gebruik van de standaard ingebouwde en gedocumenteerde debug feature waarmee een programma (de debugger) controle uit kan oefenen op een ander programma:

The exploit doesn't use esoteric techniques such as buffer overflows; in fact, it uses only the operating system's standard, documented debugging interface. This interface allows one program (a debugger) to gain control of another (a program under test) so that the behavior of the latter can be observed and/or altered. Alas, NT and Win2K allow any program to control any other; an unprivileged user can thus gain control of a privileged program and bend it to his or her will.

Er is nog geen officiële patch van Microsoft beschikbaar. Meer informatie en een onofficiële patch is hier beschikbaar.

Reacties (103)

[EfBe]

Gaan we nu ook alle root exploits van Sun, Linux, FreeBSD etc hier posten?

De newsposter begrijpt verder weinig van waar de bug over gaat, want de NT debugger start je niet op van buitenaf:

Hierdoor zijn de besturingssystemen ook kwetsbaarder voor aanvallen van buitenaf, aangezien een indringer, die als ongeautoriseerd gebruiker toegang heeft gekregen, zichzelf administrator rechten en daarmee volledige controle over het systeem kan geven

De debugger start je op de bak zelf, niet van buitenaf. Hoe zou een 'guest' user dat moeten doen dan? Via een NULL connectie? Ik denk het toch niet. Lees meer over de bug hier: http://online.securityfocus.com/cgi-bin/vulns-item.pl?section=info&id= 4287

Dat XP deze leak niet heeft komt omdat de NT/Win2k debugger is vervangen in XP. De debugger, Dr. Watson genaamd (degene die dat bedacht heeft is hopelijk ontslagen) is vervangen door een betere variant in XP.

Het is niet zo moeilijk, meneer Aneke, om wat info te vinden over hetgeen je post, je moet alleen wat verder kijken dan de page waar de URL in de dsp naar wijst. Wellicht was het ook verstandig geweest om dit topic niet door een Unix-fanaat te laten schrijven.

(yeah, mod me down, I can handle it)

[RetepV]

Hmm, kun je niet de debugger opstarten door iets smerigs te doen in VBSCRIPT, javascript of zelfs java m.b.v. een webpagina? Ik dacht dat je ook via het netwerk aan de debugger kon connecten?

Dus een website met een pagina waardoor de debugger opstart, een progje dat regelmatig scant of de debug poort open staat (dwz. de debugger opgestart) en automatisch een backdoor installeert en registreert (service) zodat je op die manier op een later tijdstip altijd op het systeem kunt aanloggen?

Het is maar een idee hoor, ik heb geen idee wat die debugger allemaal precies kan.

edit:

Ik moet er even bij zeggen dat ik de exploit niet bestudeerd heb, ik ben zomaar wat aan het redeneren.

Te zien aan de reacties zat ik er niet ver naast iig. .

[EfBe]

Nee. Dr Watson start op bij een GPF in een stuk code. Van buitenaf die GPF veroorzaken kan wel (Dit heet een Denial of Service attack) maar Dr. Watson is niet remote controllable. Je moet dus expliciet lokale toegang hebben tot de machine, iets wat bij windows servers niet gebruikelijk is.

[RetepV]

De kernelmode debugger heeft een remote port maar je moet eerst de debugger opstarten van binnenuit. (bekijk de code maar).

Daarom had ik het over een stukje VBSCRIPT op een webpagina die iets smerigs doet, waardoor de kernel-mode debugger opstart. Vanaf dat moment staat er een debug-poort over (denk ik) waar je aan kan connecten. Als je via die poort nog iets anders kunt doen, bijvoorbeeld een backdoor als service met System rechten op het systeem zetten, dan heb je volledige toegang.

Tel daarbij op dat deze bug/feature er al 6 jaar in zit, en je zou kunnen beredeneren dat de beveiligde informatie van een heleboel bedrijven al 6 jaar op straat ligt.

[EfBe]

Dat van dat VBScript kan niet. Dat stukje VBSCript zou dan de scripting engine opstarten en via de smss.exe een remote debugger requesten. Dat lijkt me niet mogelijk, daar VBScript's scripting engine niet om een remote debugger vraagt wanneer hij op zn muil gaat (mocht dat uberhaupt kunnen, er zijn geen crashes bekend)

Wat jij op doelt lijkt leuk, maar is niet mogelijk, nogmaals. Het is ALLEEN mogelijk wanneer een user, bv Jan, kan inloggen lokaal op de server en via een applicatie die de bug exploit een shell opent met security descriptor settings van SYSTEM. Echter op WinNT en win2000 hebben normale users geen local inlogrecht of het recht in te loggen via het netwerk. Dat de beveiligde info in feite al 6 jaar op straat ligt is dus onzin.

Wat WEL teniet wordt gedaan zijn de restricties die middels policies zijn geinstalleerd op winnt/win2k workstation/pro installaties: door lokaal de exploit te gebruiken kun je in principe admin worden op je lokale systeem en zo de policies omzeilen. Echter een beetje sysadmin heeft de policies zo ingesteld dat je geen exterme .exe's kunt installeren.

[jeroen|IA]

DrWatson Heb JIJ de details van die exploit eigenlijk wel goed bestudeerd?

Uit de documentatie die te downloaden is van de urrel uit het bericht bovenaan:

Principle: Ask debugging subsystem (lives in smss.exe) to create (duplicate) handle(s) to Target for you:
1. Become dbgss client (DbgUiConnectToDbg).
2. Connect to DbgSsApiPort LPC port (ZwConnectPort).
Everyone has access to this port.
3. Ask dbgss to handle CreateProcess SsApi with client id (or pid or tid only) of Target (ZwRequestPort).
4. Wait for dbgss to reply with CREATE_PROCESS_DEBUG_EVENT (WaitForDebugEvent). Message contains duplicated handle(s).
5. When debugger's thread terminates (e.g. on logoff), Target process or thread is terminated too (like it was regularly debugged).

Ieder lokaal proces kan dus gewoon aan de debugging interface gaan hangen (op api niveau). Combineer dit met een exploit die je in staat stelt arbitrary code te runnen op een remote NT machine, en voila.

[EfBe]

Ik had de exploit niet bekeken, je hebt 2 debuggers, de kernelmode debugger en de userland app debugger(drwatson). Die laatste is het idd niet. De kernelmode debugger heeft een remote port maar je moet eerst de debugger opstarten van binnenuit. (bekijk de code maar). Werkt niet vanaf buiten.

(edit)
Komt er in feite op neer dat je de remote debugger opstart op een productieserver. Dat doe je normaal gesproken niet. Wat het nare van deze bug is, is dat je lokaal als user wel tot SYSTEM kan evolueren. Netwerken met policies op hun nt workstation systemen hebben nu (in theorie) een probleem.

[jochemd]

Komen de debug priviledges die je in de user manager kan instellen ook nog ergens in het verhaal voor of gaat dat ergens anders over

* 786562 Yoshi

[jeroen|IA]

Deze bug is juist zo gevaarlijk omdat er ook security holes in win2k zitten/zaten die het mogelijk maken om op de target machine arbitrary code te laten uitvoeren. Je moet een security hole nooit op zichzelf bekijken, maar altijd als onderdeel van het grote geheel. In plaats van de boodschapper af te branden kun je ook realistisch onder ogen zien dat het hier toch echt om een kapitale blunder van MS gaat.

[EfBe]

Deze bug is juist zo gevaarlijk omdat er ook security holes in win2k zitten/zaten die het mogelijk maken om op de target machine arbitrary code te laten uitvoeren. Je moet een security hole nooit op zichzelf bekijken, maar altijd als onderdeel van het grote geheel. In plaats van de boodschapper af te branden kun je ook realistisch onder ogen zien dat het hier toch echt om een kapitale blunder van MS gaat.

Dat het een local exploit is is idd 'gevaarlijk'. Dat het NIET een remote exploit is is WEL een issue dat gemeld mag worden, omdat de boodschapper het hier brengt alsof elke NT/win2k bak nu open staat voor jan en alleman (wat niet zo is). Veel servers hebben geen local login accounts voor users (bv webservers) dus die hoeven niet met samengeknepen billen te gaan wachten tot een patch.

Security issues moet je niet negeren maar een beetje realisme is nooit weg. Een securityflaw in een zelden gebruikte en niet standaard geinstalleerde daemon binnen een Unixsysteem maakt dat merk Unix echt geen gatenkaas, maar de gebruikers van die daemon moeten hun ogen open houden voor een patch. Jij loopt te gillen alsof de wereld vergaan is, wat echt niet zo is.

[Mr.Aargh]

Hierdoor zijn de besturingssystemen ook kwetsbaarder voor aanvallen van buitenaf

Kwetbaarder, maar dan moet er wel eerst iets lokaal draaien, of er moet al een security hole zijn waardoor ze iets kunnen draaien en daarna pas admin. rechtenb kunnen claimen

[vassago]

En wat dacht je van b.v. Terminal Servers, voor deze toepassing is het echt funest tenzij je hem zo dichtspijkerd dat een gebruiker helemaal niets meer kan.

[pistole]

Als je een terminal server in productie zet die niet is getuned en dichtgespijkerd, vraag je sowieso om problemen..

[^Mo^]

als een programma een beetje uitgebreid is (wat je Windows toch wel enigszins kan noemen) dan vind je als programmeur nooit alle bugs. Wat security betreft, het is volgens mij niet moeilijker dan een linux bak configureren.. en als je daar ervaring mee hebt kom je volgens mij een heel eind in win2k.

En dan maar verwachten dat gewone gebruikers (zonder MCSE of andere bullshit) het wel snappen en weten hoe ze het OS dicht moeten timmeren

verwachten ze dat dan? Ik denk dat Microsoft als geen ander weet dat een duidelijke gebruikers interface wonderen doet. De nieuwe firewall in XP bijvoorbeeld, de gebruiker hoeft enkel een checkbox (geloof ik) aan te zetten

[RetepV]

Je vind als programmeur idd. niet alle bugs, dat is een onmogelijkheid. Wat security betreft: in Windows NT zit op alles een ACL. Dat is gewoon veel te veel informatie om bij te houden. Te meer omdat Microsoft slecht documenteert wat er allemaal aan default instellingen gedaan worden.

Bijvoorbeeld: Ik installeer SQL Server 7 op mijn systeem. Microsoft vertelt me in de docs amper iets over hoe de veiligheid geregeld is. Aangezien ze er niets over vertellen en ik Microsoft vertrouw(de), ga ik er van uit dat alles dichtgetimmerd is (tenslotte was het de _desktop_ versie van SQL Server 7). Krijg ik uit de community te horen dat ze gewoon vanaf het internet op mijn database kunnen komen (via poort 1430 ofzo)!

Ik bedoel: ik ben programmeur, ik snap iets van Operating Systems. Microsoft is een respectabel bedrijf. En toch trap ik zelf in dit soort dingen. Dat gebeurt me niet onder Unix. Onder Unix is alles over het algemeen standaard dichtgetimmerd. Het nadeel is dat de installatie en het aan de praat krijgen van de software vaak veel langer duurt, maar dat is niet erg als de veiligheid daarmee gegarandeerd is.

Bij Windows gaat de installatie vaak supersnel en werkt het allemaal direkt. Maar achteraf blijkt vaak dat alles doodgewoon open staat en ben je alsnog een paar dagen kwijt om de boel dicht te timmeren. Bij Unix ben je achteraf misschien een paar dagen kwijt om uit te zoeken hoe je dingen open moet zetten, maar in de tussentijd weet je dat je systeem veilig is.

Als je veiligheid niet meerekend is het beheer van Windows 2000 goedkoop. Als veiligheid belangrijk is, dan wordt het beheer van Windows 2000 ineens duurder dan het beheer van Unix. Al was het alleen maar omdat je voor EUR 150 boeken moet aanschaffen omdat niets gedocumenteerd is, en je een gedeelte van je vrije tijd op moet geven om het allemaal te lezen. De andere optie is MCSE, maar dat kost helemaaaaaaal handenvol geld.

Het grootste verschil tussen Windows en Unix is dat de ontwikkelaars van Unix zelf de verantwoording van veiligheid op zich nemen, terwijl bij Windows de verantwoording bij jou als beheerder wordt gelegd. Dat is leuk voor beheerders die MCSE hebben (waarvan dat geld dus ook direkt naar Microsoft gaat) en alles snappen, maar de gewone mensch trapt er dus keer op keer weer in. En dat terwijl de Workstation versies van Windows bedoeld zijn voor de gewone mensch.

Microsoft verdient miljarden aan hun software, je zou verwachten dat ze daardoor ook wat meer de verantwoording zouden nemen, maar nee hoor. De Open Source community die Unix/Linux onderhoudt heeft vele malen meer verantwoordelijkheidsgevoel dan Microsoft.

[Verwijderd]

Er is momenteel een security toolkit via MS beschikbaar waarmee je ook je SQL server goed kunt beveiligen !

[Jrz]

Niet alle Unix varianten zitten standaard dicht (redhat is zo lek als een mandje bijv.) maar ok, FreeBSD is meestal wel goed. Vreemd dat jij als programmeur dat soort dingen niet weet.

MCSE zegt helemaal niets. Je kan je MCSE in 3 weken halen, dan ben je MCSE, maar je snapt nog niets..

De verantwoordelijkheid ligt ALTIJD bij de beheerder.

Als windows standaard dicht zit, lopen alle mensen te klagen dat ze geen verbindingen open kunnen krijgen naar <vul hier een appie in>

Beheer van Windows 2000 is goedkoop. Emm 'veiligheid' is altijd belangrijk. je hebt namelijk niets aan een lekke / niet stabiele server.

De 'Open Source community' krijgen ook gewoon betaald hoor. En er zitten een boel buffer overflow bugs in die software ook, en vaak hebben ze geen benul van componentbased / modulaire code.

[Verwijderd]

Niet alle Unix varianten zitten standaard dicht (redhat is zo lek als een mandje bijv.) maar ok, FreeBSD is meestal wel goed. Vreemd dat jij als programmeur dat soort dingen niet weet.

Wat een bullshit. Kom met feiten, al die FUD over redhat als MS-look-a-like is nergens op gebaseerd. Redhat is niet minder of meer veilig dan een random andere linux distro (het is je vast niet ontgaan dat het allemaal linux is en dat het allemaal grotendeels dezelfde codebase gebruikt).

Ik ben linux programmeur (zowel kernel als applicaties) en ik weet dat dit onzin is.

Als windows standaard dicht zit, lopen alle mensen te klagen dat ze geen verbindingen open kunnen krijgen naar <vul hier een appie in>

Dan is het de verantwoordelijkheid van MS als softwarebakker om te zorgen dat dat beter is geregeld, door bv. tijdens de setup te vragen (zoals redhat en mandrake dat doen) of de firewall moet worden aangezet en hoe dicht dat ding moet staan inclusief begrijpelijke uitleg.

[Remenic]

Jzr:

De 'Open Source community' krijgen ook gewoon betaald hoor

Ik heb anders nog geen cent gevraagd en ontvangen voor mijn bijdrages aan de Open Source community... Maar misschien doe ik wel iets verkeerd, dus mijn vraag aan jou is: HOE KAN IK GELD VERDIENEN AAN MIJ OPEN SOURCE PROJECTJES?!!!

mail maar naar [e-mail], thanks.

[Verwijderd]

Wat een bullshit. Kom met feiten, al die FUD over redhat als MS-look-a-like is nergens op gebaseerd. Redhat is niet minder of meer veilig dan een random andere linux distro (het is je vast niet ontgaan dat het allemaal linux is en dat het allemaal grotendeels dezelfde codebase gebruikt).

Ik ben linux programmeur (zowel kernel als applicaties) en ik weet dat dit onzin is.

Helemaal geen onzin. Met die honeypot projecten had een red-hat server iets van 15 minuten overlevingstijd

(disclaimer: ik beweer niet dat het op enig ander platform beter is)

[Verwijderd]

Als windows standaard dicht zit, lopen alle mensen te klagen dat ze geen verbindingen open kunnen krijgen naar <vul hier een appie in>

Dan is het de verantwoordelijkheid van MS als softwarebakker om te zorgen dat dat beter is geregeld, door bv. tijdens de setup te vragen (zoals redhat en mandrake dat doen) of de firewall moet worden aangezet en hoe dicht dat ding moet staan inclusief begrijpelijke uitleg.

Ach joh, je weet toch dat het niet zo werkt? Eerst zitten de programmeurs een jaar te spelen op hun bakkie, dan moet het morgen de produktie in en blijkt het alleen te werken als de security open wordt gezet. De programmeur heeft ondertussen wel wat beters te doen en de beheerder mag het maar weer proberen aan de praat te krijgen. Dat is niet eens uniek voor Windows omgevingen, dit zie je overal met als gevolg dat ook Linux systemen niet altijd veilig zijn.

[RetepV]

Belachelijk hoor: de security zo ingewikkeld maken dat zelfs de maker van de software zelf niet eens alle bugs kan vinden. En dan maar verwachten dat gewone gebruikers (zonder MCSE of andere bullshit) het wel snappen en weten hoe ze het OS dicht moeten timmeren (ueberhaupt weten gewone gebruikers niet eens dat ze het moeten dichttimmeren).

Tegen de tijd dat je snapt hoe de security van Windows 2000 en consorten werkt kun je met pensioen.

[Verwijderd]

idd RetepV, het kan zelfs goed zijn dat één of ander bedrijf een gevaarlijke security-lek heeft gevonden en dat aan Microsoft gemeld heeft. Deze laatste kan dan ze wat zwijggeld ofzo gegeven te hebben en zal dan binnen enkele maanden de bug aankondigen en een paar maanden de patch al op de markt brengen.


Bij Open Source gebeurt dit een "beetje" sneller . Iemand ontdekt een bug in één of ander Opensource Programma. Is het een programmeur die niet lui is, over tijd beschikt en zin heeft om het te repareren, dan maakt hij een patch en upload hij die naar de ontwikkelaar(s) van dat programma, die het op hun beurt controleren en uploaden. Als de programmeur zelf aan het programma meewerkt dan kan hij dit zelf doen. Dit uploaden gebeurt dikwijls met cvs, waardoor iedereen die het wilt direct na het uploaden al de gepatchte versie kan afhalen(ze moeten hier zelfs niet voor doen).

Ben je geen programmeur, dan kan je de bug ergens melden zodat een programmeur er zich vroeg of laat(snelheid hangt af of er veel gevaar bij is) mee kan bezighouden.

Door dit systeem heb je soms binnen enkele uren(geen typfout!) al patches en omdat de broncode beschikbaar is zullen er ook meer fouten opgemerkt en opgelost worden. Ook "domme" code kan verbetert worden.

[vso]

Dit is best wel een AUW voor win2k en NT 4.0 etc
hoeveel bedrijven gebruiken dit wel niet ?

Dit samen met de *nix diskette die onder nt4 en lager
gewoon de root passwords achterhaalde ..

een debugger die je m..b.v elk prog zowat kan tevoorschijn toveren.

ik vind deze fout toch wel extreem. Dat je tijdens het inelkaar zetten van een OS wat VEILIG moet zijn zeker gezien zijn veel toepassing in VELE bedrijven.

*nix mag dan wel bv de concurrent zijn, maar als je ziet wat hun doen ten opzichte van, MS in dit geval MS heeft hier meer man achter zitten beter betaald dan de *nix progammeurs en dat ze dit over hun hoofd laten schieten. als niet gecontrolleerd. Dat vind ik onacceptabel.

Maar ja waar een wil is, is een weg. Alleen dit klinkt me zo gemakkelijk, voor de "gebruiker" dan.

Je begint je af te vragen of MS wel aan debuggen doet ?
Ze hebben zoveel geld, zouden ze geen hackers, beveiligings-experts etcera er op los laten

1 word SLORDIG

[Verwijderd]

Laten we gewoon eerlijk zijn, de hele enternal flame-war *nix-windows is grotendeels subjectief.
Vatbaarheid voor aanvallen heeft in de eerste plaats met de gebruiker/systembeheerder te maken en niet met het OS.En ja het is waar dat als er een bug/exploit in een *nix systeem is dat het over het algemeen sneller een oplossing voor wordt gevonden.En veel van deze programmeurs worden inderdaad minder betaald dan hun collega's bij microsoft.Niet allemaal overigens, geloof me.Maar het verschil zit erin dat MS een patch moet maken die voor de gemiddelde gebruiker gebruiksvriendelijk is(oftewel niet meer dan 5 muisklikken en twee aanvink vakjes).MS kan niet een patch uitbrengen voor win2k die enkel door sysadmins uitgevoerd kan worden.Komt er nog bij dat als je alles bij elkaar opteld, MS nooit zoveel mensen in dienst kan nemen als dat er aan open source bijdragen.Wat natuurlijk gewoon hun eigen schuld is
Verder is het gewoon een feit dat over het algemeen mensen die *nix OS' gebruiken iets beter weten waar ze mee bezig zijn.Simpelweg omdat diegene die geen intresse dan wel mentale vaardigheden bezitten om met *nix te werken, niet met *nix gaan werken.
En ga aub niet zeggen dat linux net zo gebruiksvriendelijk is als windows, ga jij maar even aan iemand die al moeite heeft met het veranderen van zijn desktop achtergrond vertellen hoe je ip-chains configureerd.

[vso]

erhm met die *nix diskette was het dus mogelijk om passwords van het netwerk te trekken bij nt 4.0 (en lager) dat bedoelde ik ermee.

*nix is redelijk veilig. (lees: out of the box) je kan natuurlijk vele security patches en toepassingen er oploslaten.

MAAR VOOR ZOWEL WIN ALS *NIX
De beste beveiliging is uitlaten DOH!
Maaruh ff serieus, fysiek toegang ontnemen, bioslock, kast lock, niet boot van diskette. Moeilijker maken dat het normaal is is de beste hindernis dan open en bloot.

En dit is juist mijn punt, deze lek is zo open en bloot beschikbaar voor elke gebruiker, hier kan je gewoon weg niet tegen beveiligen anders dan een patch en dat is wel lelijk.

hacken is niet moeilijk teminste als je weet wat je moet zoeken, linux heeft echt als voordeel, elke distro draait weer met andere tools en prog's
windows = 1 bundel, door juist die bundeling is het ook makkelijker om een gevonden gat bij 1000den pc's toe te passen.

Ik durf te verwedden dat over 2 a 3 jaar deze bug nog bij bedrijven te vinden is omdat men geen goeie security strategie hebben.(is dat wel ergens )

1 centraal systeem(terminal-servers) is beter te beheren als 2 of meer losse systemen

[metaal]

Niet dat ik zo'n windows fan ben, in tegendeel, maar één puntje dat je noemt vindt ik toch onredelijk. Dat je met een boot diskette rare dingen kan doen met de SAM file is niet meer dan logisch. Hoe zou je dat nou kunnen beveiligen??? Je kan ook gewoon bij de /etc/shadow file als je het systeem kan booten met je eigen flop.

Dat NT een zwakke K*T encryptie gebruikt voor de passwords is een ander verhaal. (Had het admin wachtwoord binnen 3 minuten op een P3 1GHz. Was een willekeurige reeks getallen/letters/tekens)

[CARman]

Ff over booten vanaf diskette >

Sja, je kunt natuurlijk een PC/Server zo configureren, dat je niet met een diskette kunt booten. En logischerwijs ff de BIOS met een password beveiligen.

Ja, natuurlijk kun je de kast openmaken ( als ie al niet op slot zit, zoals bij ons het geval is ) en dan de backup-batterij eruit halen voor een bepaalde tijd. Hierdoor de BIOS resetten en toch vanaf de diskette booten. Maar zeg nou zelf, dit is dus vrij eenvoudig te beveiligen, tenzij de hacker ( want dat ben je inmmiddels wel ) er echt veel moeite voor wil doen. En hij moet dan al op de plaats aanwezig zijn, wil ie ook maar iets willen uitrichten. Tot slot is de serverruimte normaal gesproken niet echt toegankelijk voor onbevoegd personeel.

Ik denk dat een bedrijf niet echt slim bezig is, als ze deze optie niet hebben uitgesloten.

[Reefer]

Misschien denken zij dat de hackercommunity dit soort werk voor hun opknapt en eigenlijk is dat ook zo, als je tenminste aanneemt dat de serieuze bugs zoals deze allemaal bekend gemaakt worden.

[frankvdtillaart]

[100% off-topic]

Dit ... [bold]SLORDIG[/bold]

2 (informatief) ??
WTF, waarom is dit geen ontzettende troll???
[/100% off-topic]
Waarom mauwt iedereen altijd zo op windows. Als er een keer een bug wordt gevonden in *nix hoor je niemand klagen (onder het motto: "dat is zo opgelost"). Het is dat M$ zo groot is, en iedereen probeert de bugs te vinden.
Wacht maar af tot ook de thuisgebruikers *nix gaan gebruiken, als alternatief op windows, ik beloof je dat er zeker net zoveel fouten in zitten. En dat ze ook gevonden worden, want dan gaat "iedereen" zich ook op *nix-fouten richten ...

edit:

Hmm, klinkt ook een beetje Windows-aanhangerig...
Ik ben geen Windows-fan, maar aangezien ik linux wel eens geprobeerd heb (jaja, een jaar geleden) en ik tot de conclusie ben gekomen dat windows (toen) nog wel makkelijker was/is, blijf ik daar nog even bij.
Oh ja, Flame intended Dan kost het me maar een paar punten, dit is een reactie op een nieuwsbericht, niet op alt.flamenmaar.microsoft.noobs

[vassago]

>Dit samen met de *nix diskette die onder nt4 en
> lager gewoon de root passwords achterhaalde ..
Die diskette achterhaald het pasword niet maar overschrijft gewoon de SAM.

>1 word SLORDIG
Bullshit! het zit er al in vanaf WinNT 3.x en het wordt nu pas gevonden.

[Verwijderd]

Ik lees hier dat het gaat om windows NT en 2000 maar is Windows XP ook affected?
Aangezien zoals iedereen weet XP volledig gebaseerd is op Windws 2000!

[stappel_]

Nee XP heeft de bug niet. Een stukje uit zijn tekst met oplossingen:
*) move dbgss to kernel like in Windows XP ;

[Nitroglycerine]

De waarschijnlijkheidskans is meer dan 95%. xCAT gaat door voor de magnetron

[Rene59]

Ik lees op hun forum dat XP er iig geen last van heeft. Vreemd, ik dacht dat XP volledig op NT/2k gebouwd was.
Microsoft is trouwens toch nog steeds bezig met 'bug-hunting' heb ik begrepen? Ben benieuwd hoe snel Microsoft nu dan met een patch komt hiervoor.

Zou dit dan het eerste voordeel van XP t.o.v. 2k zijn?

[Nielsz]

Nee, ze zouden zich maar 1 maand compleet met bughunten/fixen bezighouden, en daarna gewoon weer doorgaan met ontwikkelen.

[Belgar]

Ik heb de example code bekeken en het gevaar zit vooral aan het toekennen van 'debug rights' en heeft volgens mij niets te maken met dr.Watson. De exploit zit hierin dat je de system manager je eigen code 'debugger' kunt maken van andere code. De plaats innemen van dr. Watson dus. Dit is te gebruiken op twee manieren:

- Processes afsluiten (firewalls, scanners, etc)
- Processes overnemen en toekennen aan een andere user.

Het is ook geen stand alone bug, volgens mij, maar meer een manier om welk proces dan ook over te nemen, op het moment dat je toegang hebt. Let wel, je hoeft dus NIET de debugger zelf op afstand te activeren, je kaapt alleen de rechten die de debugger normaal krijgt..

De reden waarom het volgens de makers niet in XP werkt, is omdat daar de Kernel de debugger direct aanroept en niet een ander programma de rechten laat toekennen.

[MikeN]

Het is ook geen stand alone bug, volgens mij, maar meer een manier om welk proces dan ook over te nemen, op het moment dat je toegang hebt.

Het is zeker wel een standalone bug. Je kan een willekeurig programma, wat nog niet draait, gewoon starten met administrator access.

[Verwijderd]

Als windowsXP smss.exe heeft waarschijnlijk wel

Mocht je het op je eigen systeem willen testen:

http://www.anticracking.sk/EliCZ/bugs/DebPloit.zip

[Tonnes]

Readme.txt:

4. What about Windows XP?

As far as I know XP doesn't have this security hole.

Ik vraag me trouwens af of hierdoor 2k's sp3 nog later of juist eerder uit gaat komen

[lintux]

Deze doet me sterk denken aan het volgende:

http://groups.google.com/groups?selm=egu9s9.ti9.ln%40127.0.0.1

Bijna een half jaar geleden was dat al bekend.. Gaat het om hetzelfde probleem?

*sigh*

[EfBe]

Ja, laten we Wouter Verelst's mening verheffen tot iets inzichtvols... (in die thread sta ik ook zo'n 100 keer oid , ik weet wie het is)

Dat de debugger het process killt is logisch. Ik kan overigens in VC++ 7 niet attachen aan OS processes (zoals winlogon). Dus daar is het wat woutertje verelst oplepelt gefixt.

Dat iemand roept dat ddd veel beter is, tja... het is een mening, maar ook niet meer dan dat.

[lintux]

Blijkbaar heb jij een hekel aan Wouter Verhelst, die mening kan ik niet met je delen. (Wel ben ik benieuwd onder welke naam je daar postte)

> Dat de debugger het process killt is logisch.

Huh? Detachen zou ook wel handig zijn.. Dat kan strace/truss of gdb in Unix, dus dan zou dat in Windows ook moeten kunnen. Maar attachen aan een proces dat niet van jezelf is, is me al ziek zat..

En het ging me verder ook niet om DDD, die vinnik zelf ook maar niks.

[EfBe]

Detachen van een process dat je hebt gedebugged is in theorie onmogelijk, omdat je door je ge-debug, de process-state hebt gewijzigd (bv door local vars te wijzigen, breakpoints te zetten etc). Wat uiteraard fout is in de VC6 debugger is het attachen aan ALLE processen die draaien. Nu kun je alleen userland processen debuggen (dus eraan attachen) en dat is wel zo logisch.

Ik heb geen hekel aan wouter, maar wel aan zealot-meningen. That's all.

[tweakerbee]

Hij is wel leuk, maar het is niet hetzelfde probleem.

[tiguan]

Maar goed dat we die nooit installeren. Ik haat die debugger. Elke keer als je een website opent die een of andere fout bevat (misschien is het geeneens een fout) krijg je de vraag of je die debugger wil gebruiken.

[vassago]

Volgens mij snap je het niet helemaal, het heeft niets met de debugger te maken die je kan installeren met b.v. Visual Studio.

Het is een standaard funktie in NT 3.x t/m 2000.

[tiguan]

Oh ok, laat maar. Ik dacht het over de Script Debugger ging. Zit trouwens standaard bij Windows, hoef je niet Visual Studio voor te hebben hoor.

[Verwijderd]

The discoverer's public announcement of the bug (first link below) contains not only a complete description of the problem but a sample exploit.

Op zich logisch dat de 'ontdekker' zo probeert een reactie te krijgen maar zo maak je het de irritante kiddies wel erg makkelijk natuurlijk. Vraag me af of het zin heeft om morgen naar school te gaan, weet vrij zeker dat geeneen PC meer zal werken

[MikeN]

Daar heb je wel gelijk in. Ik heb het net even uitgetest en in die kit zit een programma waarmee je ieder gewenst programma als root (administrator onder windows ) kan starten. Hiermee heb ik op een win2k bak als "guest" user mmc als root weten te starten. Toen kon ik eigenlijk gewoon "alles".

Het is dus niet echt slim om dit op deze manier bekend te maken, aan de andere kant is de bug al oud en heeft Microsoft er nooit een fix voor uitgebracht.

[Verwijderd]

Zo'n berichten zijn wel degelijk nuttig Tong-Poh!

Het feit dat Microsoft nog geen patch heeft is omdat ze nog niet veel is misbruikt. Als er nu op grote schaal klachten binnenkomen moeten ze wel een patch maken! Anders zouden zij dat nooit doen....monopolie weet je wel? Als er voldoende concurrentie zou zijn, dan zouden die bugs wel snel klaar zijn als de website van een concurrent de bug opmerkt...