Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 144 reacties
Bron: Slashdot

Op Slashdot is te lezen dat de methode waarop onlangs root-toegang werd verkregen op de servers van het Debian-project, is vastgesteld. De oorzaak bleek te liggen in een tot dusver onbekende bug in de Linux-kernel waardoor een gebruiker zonder root-rechten volledige toegang kon verkrijgen tot het kernel-geheugen, waardoor de gebruiker alle toegangsrestricties kan omzeilen. De exploit die werd gebruikt voor het hacken van de Debian-servers was in versleutelde binaire vorm achtergelaten op de getroffen servers. Nadat het versleutelde programma was bestudeerd door onder andere beveiliginsexperts van SUSE en Red Hat kwam de bug in de kernel snel aan het licht.

Inmiddels is er de 2.4.23-kernel voorzien van een fix die de bug verwijdert. Ook in de 2.6-kernel serie is de bug inmiddels geëlimineerd. De meeste distributies, waaronder uiteraard Debian, voorzien inmiddels in een nieuwe kernel die het probleem verhelpt:

Bug stampen (klein)Recently multiple servers of the Debian project were compromised using a Debian developers account and an unknown root exploit. Forensics revealed a burneye encrypted exploit. Robert van der Meulen managed to decrypt the binary which revealed a kernel exploit. Study of the exploit by the RedHat and SuSE kernel and security teams quickly revealed that the exploit used an integer overflow in the brk system call. Using this bug it is possible for a userland program to trick the kernel into giving access to the full kernel address space. This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Moderatie-faq Wijzig weergave

Reacties (144)

Al met al denk ik niet dat ik de komende jaren gebruik zal maken van Debian..
Deze keer was het ontdekt.. hoevaak is er iemand 'binnen' geweets die echt wist wat hij/zij deed zonder sporen achter te laten.. Open Source is cool, iedereen kan code toevoegen...
Sorry Jazzman, maar deze opmerking is niet juist.
De fout lag niet in Debian, maar in de Linux kernel. Elke distributie, SUSE, Red Hat enzovoorts heeft er last van.
En in elke besturingssysteem worden dit soort fouten gevonden, of het nu M$ is of Open Source dat maakt niet uit.
In dit geval duurde het idd uitzonderlijk lang (9 weken) voordat de fout gepatcht was. Lang voor Open Source tenminste, bij M$ weet je vaak niet hoe lang de fout al bekend was.
Volgens mij was de fout heel snel gepatched voor de nieuwe kernels, maar is die 9 weken alleen voor het backporten naar een oude kernel.
Zijn wel wat beveiligingen om te merken of iemand ongeauthoriseerd code probeert aan te passen.

Anyway. In dit geval had je username / password nodig om toegang te krijgen tot een server, en daarna is root verkregen, zoals slashdot meldt, via een programmeerfout in de kernel, die er al uitgehaald was, maar nog niet 'backported' in woody. Als je stap 1 kan vermijden is je desktopje thuis wel veilig.

apt-get update werkt nog steeds niet geheel, alhoewel security.debian.org wel weer apt-gets uitdeelt. :) Binnen een paar dagen is alles weer in orde.

Anyway, thuis draait SID (debian testing). Altijd de laatste bugfixes (en nieuwe bugs :P).
Even voor de duidelijkheid: sid = unstable. testing = sarge
Open Source is cool, iedereen kan code toevoegen...
yup. :Y) maar niet zomaar. Je moet er wel wat voor doen om jouw code in een project te krijgen hoor. Over closed-source worden er ook nuttige opmerkingen gemaakt:
closed-source is cool, je weet maar nooit wat voor een geniepige zaken een commercieel bedrijf in hun programma hebben gestopt

...of nog niet gefixt heeft |:(

Sorry dat laatste is wel een beetje trollig, maar ik kon het niet laten.. :P Met andere woorden, zoals open-source als closed-source ook niet alles, je moet voor jezelf uitmaken waar jij het meeste baad bij hebt in je business.
De bug was niet alleen in Debian aanwezig maar in de linux kernell an sich.. Als je hier zo paranoïa van wordt kun je dus beter alle linux distro's mijden...
De bug was niet alleen in Debian aanwezig maar in de linux kernell an sich.. Als je hier zo paranoïa van wordt kun je dus beter alle linux distro's mijden...
En microsoft windows moet je dan al helemaal mijden! Deze bug zit namelijk ook in windows en is daar zelfs niet oplosbaar vanwege compatibiliteits-eisen. Microsoft heeft die bug dus maar een feature genoemd :P

Debian is en blijft nog steeds het veiligste besturingssysteem imho. Alleen OpenBSD is daarvoor een alternatief.
Inderdaad.
Gelukkig maakt Debian gebruik van cryptografisch getekende packages. Dat jij er verder niet naar kijkt, en blind installeert wat je voor je kiezen krijgt is niet echt de fout van de distributie.
Als je het nieuws had gevolgd dan had je ook geweten dat de hele repository is gecontroleerd, en is goedbevonden.

Anyway, deze fout kun je niet op de distributie schuiven waarin hij toevallig in is ontdekt. Het is een kernel bug. Dat deze niet met een security advisory negen weken geleden al is gedicht kan verschillende oorzaken hebben. Dat de bug 9 weken geleden al is gevonden en opgelost hoeft niet te betekenen dat negen weken geleden ook al bekend was dat het een probleem betreft dat exploiteerbaar is. Iemand heeft blijkbaar LKML gevolgt, en een andere (juiste) conclusie getrokken. Vervolgens is 'ie ermee aan de haal gegaan, en heeft een paar mensen wakker geschud. Wees blij dat het probleem nu bekend is, en dat het is opgelost.

Om nu gelijk het toevallige slachtoffer links te laten liggen is m.i. ietwat kortzichtig. Als je zo redeneerd dan raadt ik je aan om je PC nu uit te zetten, en er nooit meer aan te komen.
Tja, hoe vaak komt het wel niet voor dat er passwords gesnifft worden, tis toevallig dat ze debian te pakken gehad hebben, voor hetzelfde geld hadden ze de up2date servers van Redhat of windows update te pakken gehad.

Overigens hadden ze dit kunnen voorkomen door een grsecurity kernel te draaien met de nodige opties. Hoe vaak ik smerige programma's wel niet afgeknald zie worden op onze servers vanwege overflows en geheugen waar ze niet aan horen te komen....
Whoei :)

Een hacker maakt gebruik van een bug in de kernel om nog een "bug" te programmeren. (En het voor hem makkelijker te maken om te hacken)

En nu krijgt hij op zijn brood dat de exploit die hij gebruikte en gemaakt heeft worden ontdekt en hij ze dus niet meer kan gebruiken. :)
Eigenlijk zouden we die hacker moeten bedanken ;)
We hadden de hacker pas kunnen bedanken als hij hier netjes en uitgebreid melding van had gedaan. Niet zoals het nu is gegaan.

Rest mij wel te zeggen dat het hier iemand met enige clue betrof. ;)
Eigenlijk zouden we die hacker moeten bedanken
In zekere zin wel.
Debian was altijd al een der beste keuzes voor een veilig systeem. Dankzij deze hacker zal dat zeker zo blijven. Eigenlijk geldt voor debian hetzelfde als voor OpenBSD:

Zowel Debian als OpenBSD zijn populair EN hebben de naam veilig te zijn. Hackers/crackers zien het als een uitdaging juist die besturingssystemen aan te pakken.

Een vergelijkbare hack is overigens enige tijd geleden bij microsoft geweest. Hackers uit rusland hebben 12 (!) dagen volledige toegang gekregen tot de windows-source. Korte tijd daarna zijn de dns-servers van MS eveneens aangevallen. Saillaint detail is dat door ms ingehuurde beveiligings-experts toen Gnu/Linux-servers hebben ingezet om microsoft beter te kunnen beveiligen. :)
Debian was altijd al een der beste keuzes voor een veilig systeem.
Zoals nu blijkt, is deze aanname onwaar gebleken.
Dankzij deze hacker zal dat zeker zo blijven.
Volgens mij begrijp jij niet goed wat hier aan de hand is. Deze bug was al gevonden en opgelost voordat deze hack plaatsvond. Dit is ook gelijk de reden waarom de aanname dat debian de beste keuze was ivm. security DUS niet waar is. Deze hele hack bewijst juist dat het debian systeem NIET secure is, omdat men:
a) deze patch niet in de stable kernel toegepast heeft
b) men de gebruikers niet geinformeerd heeft over het ontbreken van deze patch

Het enige waar we deze hacker voor kunnen bedanken, is het aantonen dat het debian systeem van kernelbeheer niet secure is.
Eigenlijk geldt voor debian hetzelfde als voor OpenBSD:

Zowel Debian als OpenBSD zijn populair EN hebben de naam veilig te zijn. Hackers/crackers zien het als een uitdaging juist die besturingssystemen aan te pakken.
Wederom imo een verkeerde interpretatie. Debian en OpenBSD zijn helemaal niet populair, het zijn niche producten. Het gros der OSsen is altijd nog windows, *nix, redhat (linux), en dan pas komt de rest. Debian en OpenBSD hebben een actievere community met veel zealots, dat is het verschil.

Juist doordat die zealots altijd om het hardst roepen dat hun systeem secure is, is het voor een hacker leuk om hiermee aan de slag te gaan.

Dit is echt de wereld op z'n kop zetten wat jij doet. Als MS een patch wel heeft, maar niet uitbrengt, en het heeft als gevolg dat de boel gehacked wordt, staat elke linux-zealot op z'n achterste benen moord en brand te schreeuwen, nu maakt Debian zo'n fout en is dat omdat 'ze zo secure zijn'.
Volgens mij begrijp jij niet goed wat hier aan de hand is. Deze bug was al gevonden en opgelost voordat deze hack plaatsvond. Dit is ook gelijk de reden waarom de aanname dat debian de beste keuze was ivm. security DUS niet waar is. Deze hele hack bewijst juist dat het debian systeem NIET secure is, omdat men:
a) deze patch niet in de stable kernel toegepast heeft
b) men de gebruikers niet geinformeerd heeft over het ontbreken van deze patch
op a: Debian maakt als policy gebruik van de kernels van kernel.org. De zgn. "Stock" kernels. Geen patch/fix in de stock, geen patch/fix in Debian. Of dat een goede of slechte zaak is mag je voor jezelf uitmaken.
op b: Hoe moet je een gebruiker informeren over iets waar je zelf niet van op de hoogte bent? Het feit dat de kernel developers zelf niet aan de alarmbel hebben getrokken heeft m.i. meer te maken met het niet onderkennen van het gevaar van de bug (onderschatting van de impact) dan met onwil/incompetentie van de debian packagers. Kan iemand mij uitleggen hoe je als administrators je servers moet beveiligen tegen gevaren DIE NIET BEKEND ZIJN? Nou kun je wel roepen de bug en fix al in september bekend waren, maar als dat niet gecommuniceerd wordt via de normale kanalen voor beveiligingsfouten, hoe moet men dan als beheerder weten dat er gevaar dreigt? Ik heb het (nog) niet kunnen vinden, maar het zou me niet verbazen dat de fix voor dit 'lek' meer een toevalligheid was dan dat er bewust is onderkent dat het gevaar oplevert. Iemand die mij de LKML post kan laten zien waar iets anders in staat (bijvoorkeur met de betreffende patch erbij) zou ik zeer erkentelijk zijn. Ik heb als beheerder namelijk geen tijd om alle patches die op LKML voorbij vliegen te controleren of er toevallig ook eentje bij zit die een misschien wel of niet gevaarlijk beveiligingslek oplost.
Debian was altijd al een der beste keuzes voor een veilig systeem.

Zoals nu blijkt, is deze aanname onwaar gebleken.
Hoezo? Debian is door deze exploit niet onveiliger dan andere GNU/Linux distributies. Het Debian archive is namelijk niet aangepast, dus Debian gebruikers hebben geen kwaadaardige packages gekregen, en de gebruikte exploit is niet Debian-specifiek.
Volgens mij begrijp jij niet goed wat hier aan de hand is. Deze bug was al gevonden en opgelost voordat deze hack plaatsvond.
Volgensmij begrijp jij niet goed wat hier aan de hand is. Toen de bug gevonden was, werd aangenomen dat hij niet exploitable is. Debian heeft hiervoor dus geen security updates gedaan, en de andere distributies ook niet.
Deze hele hack bewijst juist dat het debian systeem NIET secure is, omdat men:
a) deze patch niet in de stable kernel toegepast heeft
b) men de gebruikers niet geinformeerd heeft over het ontbreken van deze patch
Geen enkele distributie heeft A of B gedaan tot enkele uren geleden. In plaats van Debian af te zeiken kun je je misschien wat beter informeren.
<quote>Hoe moet je een gebruiker informeren over iets waar je zelf niet van op de hoogte bent?</quote>
Dat noemen ze nu Intrusion detection en prevention. Het laatste bussword bij security experts. Laat alleen dingen toe die "normaal" zijn en blokeer alles wat abnormaal is.

Deze bug zou hiermee niet tegengehouden worden aangezien het een local exploit was, maar andere onbekende problemen kun je wel voorkomen.
Mandrake daarentegen neemt bijna altijd de meest recente versie van packages. Hierdoor gaat er wel eens wat fout (opgeblazen CDRoms ) maar het voorkomt wel dat oude en al opgeloste problemen zich blijven voordoen.
Voor wie het nu nog niet weet:
1) die opgeblazen cdroms zijn weet tot leven te wekken
2) de oorzaak daarvan lag bij de foute implementatie van LG
3) het probleem kwam door UDF patches die bij SuSE vandaan kwamen
4) o.a. Gentoo gebruikers waren ook getroffen door het probleem, maar er waren er te weinig om statistisch te achterhalen wat nou precies fout was.
5) de patches dateren van juli, pas als een grote distro (in dit geval Mandrake) dergelijke problematische patches toepast komen dat soort problemen aan het licht; het had net zo goed b.v. SuSE kunnen overkomen.
Nee, je leest mijn post niet goed. :)

Dergelijk breed uitgemeten zaken werken stimulerend. Een door MS gesponsord onderzoek heeft bijvoorbeeld hetzelfde gedaan voor SAMBA. De opensource-community draait hier juist op.

Debian en OpenBSD zijn wel degelijk populair. Het wordt juist gekozen wanneer zaken echt goed beveiligd moeten worden.

Windows wordt veel gebruikt, maar is erg inpopolair. Je haalt die twee dingen door elkaar denk ik.
Ik lees je post prima hoor. Populair is bij producten synoniem aan marktaandeel, niets meer en niets minder.

Debian en OpenBSD hebben nauwelijks marktaandeel, dus zijn niet populair. Simpel as that.
OpenBSD is niet echt populair. FreeBSD is véél populairder dan OpenBSD. Het enige voordeel dat OpenBSD heeft ten opzichte van FreeBSD is dat OpenBSD op meer hardware werkt dan FreeBSD. Dit heeft natuurlijk weinig met veiligheid te maken.

Het voordeel van Free/OpenBSD ten opzichte van Linux is dat er een veel betere controlle is op de ontwikkeling van de software. (En dat SCO hier geen claim op heeft) Debian is van de Linux distributies de meest conservatieve. Hierdoor komen er minder vaak bugs voor maar ontbreken er ook vaak mogelijkheden ten opzichte van andere distributies. Mandrake daarentegen neemt bijna altijd de meest recente versie van packages. Hierdoor gaat er wel eens wat fout (opgeblazen CDRoms :( ) maar het voorkomt wel dat oude en al opgeloste problemen zich blijven voordoen.

Wat je nu moet draaien? Geen flauw idee. FreeBSD is vaak iets efficienter als server dan linux. Debian is vrij stabiel. Mandrake heeft de meest recente patches, Red Hat en Suse hebben de beste ondersteuning door commerciele bedrijven. Dus....
OpenBSD heeft als streven veilig te zijn. Debian heeft een hele andere agenda, hoewel veiligheid ook een punt daarvan is.

Ik vind OpenBSD en Debian verre van vergelijkbaar en ik begrijp eerlijk gezegd niet hoe je op zo'n ridicule uitspraak kan komen.

OpenBSD bevat ProPolice, W^X beveiliging etc. Debian heeft niets van dit alles (hoewel Adamantix, voorheen Trusted Debian, maar hernoemd op verzoek van Debian, hier wel oplossing voor biedt).

De rest van de verschillen is al door anderen aangevoerd.
Die hebben niet perse Linux servers ingezet. Maar aangezien de locatie hardcoded in de worm was hebben ze windowsupdate.microsoft.com tijdelijk uitbesteed aan een extern bedrijf met andere ip's. En die draait "toevallig" linux. Met hun hadden ze gewoon goede ervaringen ;)

offtopic:
ik vond het ook wel lache hoor, maar zo zat het nou eenmaal niet :(
Dat zeg ik toch ook :) Het is overigens een hele heisa geweest. Microosft heeft de FBI ingeschakeld maar daders hebben ze nooit kunnen pakken.

Dat de dns servers zo makkelijk down konden van MS was trouwens pure nalatigheid van het bedrijf. Een ontwerpfout.
Het probleem was dus al gevonden in september?
dan vraag ik me toch af waarom dit niet gelijk gefixed is in de kernel aangezien het toch een gevaarlijk lek is
Debian heeft niet altijd de laatste versies, omdat ze deze eerst uitvoerig testen. Is dit de reden geweest waarom ze Debian gepakt hebben..?

..hebben andere distro's deze bug als wel gepatched in hun kernel-sources? (of gewoon 2.4.23 geinstalleerd)
in unstable zit toch zeker de laatste zooi?

en dan nog, ze hebben wel security updates voor stable en testing

en daar zat voor zover ik weet deze fix ook niet tussen
Als die smiley sarcasme uitdrukt, dan hoor je me niks zeggen, maar anders...

Unstable is uiteraard het allernieuwste. Testing (sarge) is bijna klaar voor release (plan was om te releasen op 1 dec, maar dat wordt voor onbepaalde tijd uitgesteld ;)), en dus een stuk stabieler dan unstable (sid). Kernel 2.6 zit in sid, en 2.4 ook natuurlijk.
Of 2.6 al in testing zit vraag ik me af. Kan het nu even niet controleren, maar het klinkt me zeer onwaarschijnlijk in de oren dat in een bijna-release een test-kernel komt te zitten. De laatste 2.4 kernel zal wel in sarge zitten.

En wat deze patches betreft... die zijn nu dus doorgevoerd voor stable, en ook testing en unstable krijgen die binnenkort.
QuarkuS:
Dat is gewoon onzin. Testing is altijd de allernieuwste en geeft de minste garantie dat alles werkt. Unstable bevat alles dat door testing heen komt. Stable is de release waarin alles bijna zeker goed werkt.
de echt meest nieuwe zooi zit in testing. :)
De laatste 2.4 kernel zit in unstable en de laatste 2.6 zit in testing (omdat die niet nog final is).
Van: http://linuxtoday.com/security/2003120201026SCKNMD
A vulnerability was discovered in the Linux kernel versions 2.4.22 and previous. A flaw in bounds checking in the do_brk() function can allow a local attacker to gain root privileges. This vulnerability is known to be exploitable; an exploit is in the wild at this time.

The Mandrake Linux 9.2 kernels are not vulnerable to this problem as the fix for it is already present in those kernels.
Mandrake 9.2 heeft dus al de juiste kernelpatches. Ik kan me voorstellen dat dat bij andere Distro's ook zo is. Het is natuurlijk wel aan te raden dat even te checken, vooral voor alle serversystemen en pc die direct aan het net hangen.
Het is wel gefixed... Quote uit link:
http://lists.debian.org/debian-security-announce/debian-security-annou nce-2003/msg00212.html
This bug has been fixed in kernel version 2.4.23 for the 2.4 tree and
2.6.0-test6 kernel tree. For Debian it has been fixed in version
2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386
kernel images and version 2.4.18-11 of the alpha kernel images.
...niet gelijk gefixed...
Het probleem was dus al gevonden in september?
dan vraag ik me toch af waarom dit niet gelijk gefixed is in de kernel aangezien het toch een gevaarlijk lek is
Het is in september gefixt in 2.6.0-test6, maar toen werd niet gedacht dat het bugje exploitbaar zou zijn. Er zijn zo vaak kleine bugs die niet exploitbaar zijn.

Omdat het een bug was, wordt het ook opgelost in de 2.4 serie, namelijk in de 2.4.23-to-be kernel. Als toen bekend was geweest dat de bug exploitbaar was, dan was er meer haast achter gezet, en was misschien 2.4.23 gereleased met die bugfix als enige verandering t.o.v. 2.4.22.

Dat deze bug niet exploitbaar werd geacht is ook de reden dat de gecrackte Debian machines niet gepatcht waren (ze draaiden 2.4.22). Nadat deze machines gecrackt waren is men er dus achter gekomen dat de brk() bug wel exploitable was, en daardoor lees je nu dit nieuwsbericht.

Dit is overigens niet Debian-specifiek; niemand (behalve dus een of enkele crackers) wist dat de bug exploitable was, dus het is waarschijnlijk dat andere distributies ook nog vulnerable kernels draaien en/of aanbieden (ik heb de afgelopen paar uur ineens wat kernel security updates van een aantal distro's langs zien komen ;) ).

Van debian-announce:
Even though this kernel bug was discovered in September by Andrew Morton and already fixed in recent pre-release kernels since October, its security implication wasn't considered that severe. Hence, no security advisories were issued by any vendor. However, after it was discovered to be used as a local root exploit the Common Vulnerabilities and Exposures project has assigned CAN-2003-0961 to this problem. It is fixed in Linux 2.4.23 which was released last weekend and in the Debian advisory DSA 403.
Wat ik wel gaaf vind om te zien, is dat er zo lekker wordt samengewerkt tussen verschillende Distro's. Debian, een niet-commerciele Distro, wordt geholpen als er een hack plaatstvindt door beveiligingsexperts van Redhat en Suse. Het is natuurlijk allemaal Linux, maar het is toch erg gaaf om te zien dat eigenlijke concurrenten van elkaar, elkaar wel helpen, in plaats van keihard met elkaar te concurreren. Dat is in andere segmenten van de OS-markt toch wel een beetje anders ;).
In dit geval zijn het dus -geen- concurrenten. Een fout in de kernel is gevaarlijk voor -alle- linux distributies. Dus ook voor de commercielen.

Overigens geld deze bug ook voor de 2.0 kerneltree? (ik heb nog een Freesco routertje draaien vandaar ;) )
Overigens geld deze bug ook voor de 2.0 kerneltree? (ik heb nog een Freesco routertje draaien vandaar
LEZEN! Het is geen remote security hole.

Tenzij je Jan en alleman toegang verleent tot je servertje is er dus niets aan de hand.
LEZEN! Het is geen remote security hole.

Tenzij je Jan en alleman toegang verleent tot je servertje is er dus niets aan de hand.
Hoewel je gelijk hebt is dat natuurlijk wel een vrij gevaarlijke houding. Ja, het is een local exploit, maar als iemand nu toegang krijgt tot jouw systeem (exploit in bv. apache, of een gesnifft password, of een terminal die je open laat staan, of die persoon die je eigenlijk toch wel met een account vertrouwde, etc), dan kan hij ook root worden.

Een local root hole is lang niet zo ernstig als een remote root hole, maar dat betekent niet dat je er niks aan hoeft te doen.
Waarschijnlijk niet. Er is al bekend gemaakt dat 2.2 niet kwetsbaar is en lijkt me dat die code er dan nog niet inzat en daarmee ook niet in 2.0.
Oefje :)

Want ik denk niet dat ik mijn kerneltje nog een update voor zal krijgen. D8 dat 2.0.39 de laatste release in die tree was...
wat ik wel gaaf vind, is te constateren dat Linux ook over features beschikt... ;)
Je hebt gelijk. Microsoft zou meteen tot op de grond afgezaagd worden, Linux wordt dat niet.

Ik ben zelf een Linux liefhebber en ik vind het een slechte zaak waarom een 9 weken bekende bug niet eerder wordt gefixed.

Ze hadden de 2.4.23 kernel gewoon eerder uit moeten brengen, dan zou de huidige 2.4.23 kernel 2.4.24 zijn geworden.
De bug was al gefixt, meer bepaald in 2.4.23. Alleen hebben de Debian sysadmins nagelaten om die te installeren op hun servers.
Ik denk wel dat het een probleem is dat er geen duidelijke advisories door de Linuxkernelmaintainers zelf worden bijgehouden. Een overzicht van welke problemen ontdekt worden en wanneer en in welke versie die gefixt zijn, is dringend nodig.
De kernel developers maken changelogs en schrijven code, ze hoeven geen advisories uit te brengen, dat is de taak van diegenen die de code aan de man brengen: de distro makers.

Zie bv:
http://linuxtoday.com/security/2003120201026SCKNMD
http://linuxtoday.com/security/2003120200926SCDBKN

Lijkt me duidelijk.
Bovendien: het gaat hier nog steeds om een local exploit, niet om een remote.
http://www.kernel.org:
The latest stable version of the Linux kernel is: 2.4.23 2003-11-28 18:27 UTC F V VI C Changelog

Tja...nalaten om iets te installeren wat nog niet is uitgebracht. Hoe zie je dat precies?
Ik ben zelf een Linux liefhebber en ik vind het een slechte zaak waarom een 9 weken bekende bug niet eerder wordt gefixed.
Bug was al bekend, en al gefixed. Je kan je hooguit afvragen waarom de Debian systemen niet gepatched waren, maar dat staat los van Linux kerneldevelopment.

Maw: dit is niet vergelijkbaar met MS vulnerabilities en wordt dus dientengevolge niet zo aangerekend.
Al bekend en al gefixed. Maar dan even voor de duidelijkheid, was dat bekend, was er een losse fix?

En waarom is diet niet vergelijkbaar met een MS probleem?
Ja dat was bekend, want anders had Mandake 9.2 met de 2.4.22 kernel de fix NIET gehad. Maar Mandrake 9.2 heeft de fix wel.

Dit is niet vergelijkbaar met een MS probleem, omdat het probleem zich voordoet in systemen die niet up to date zijn gehouden. Er was allang een oplossing.

Vergelijk MS met de Linux Kernel devvers. Als die de zaken gefixed hebben kan je het 'Linux' niet meer aanrekenen.
Anders kan ik ook aankomen met dat win95 (standaard van cd) niet veilig is. Dat kan je net zo goed MS niet aanrekenen.
In FLOSS land is de code open source en gemakkelijk te downloaden. Dus als die code gefixed is, is het probleem opgelost.
Net zo goed als dat je het MSBlast probleem slechts ten dele aan MS kunt aanrekenen; daarvoor was immers ook een fix; dat MS die zelf ook niet overal had toegepast geeft dan weer andere zwakheden aan, maar goed, dat is een tweede.
Dan blijft vooral als conclusie over dat de maintainers van debian ongelovelijk hebben zitten slapen en met hun tal van andere distro's want als de exploit gewoon gepubliceerd is maar de fix daarvoor alleen toegepast op mandrake dat lijkt me dat toch wel een geval van nalatigheid.

En daarmee ook providers als WideXS trouwens die pas nu ineens halsoverkop gaan patchen, dat hadden ze dan ook wel 9 weken geleden kunnen doen, dat betekent gewoon dat ik als klant 9 weken lang kwetsbaar ben geweest door hun nalatigheid
Ehm, het is een local exploit waar het hier om gaat, niet vergelijkbaar met een remote exploit.

En ik zei nergens dat alleen Mandrake de fix heeft toegepast, het lijkt me sterk dat de nieuwe SuSE 9 en FC1 deze fix niet hebben. Daar heb ik alleen zogauw geen www adres voor, want die hou ik niet echt bij.
Ze hadden de 2.4.23 kernel gewoon eerder uit moeten brengen, dan zou de huidige 2.4.23 kernel 2.4.24 zijn geworden.
Dat is waarschijnlijk ook wat er gebeurd zou zijn als ze toen al geweten hadden dat de bug exploitable was. Maar dat is de afgelopen week pas duidelijk geworden.
Je hebt gelijk. Microsoft zou meteen tot op de grond afgezaagd worden, Linux wordt dat niet.
ik denk hier inderdaad een kern van waarheid in zit. Wazig is het wel iig. :? Maar, bekijk ook de trolls in deze reactielijst (laagste niveau), en de reacties daarop die gemod zijn met inzichtvol. ;)

(hierin is genoeg informatie te vinden, voordat er nieuwe trollen ontstaan.)
This problem was found in September by Andrew Morton, but unfortunately that was too late for the 2.4.22 kernel release.
Mnou dat schrijft linux dus af voor mij :+

Kijk eens hoe lang dit al bekend is, zo'n grote bug had toen al wat aan gedaan moeten worden. Nee zo zal linux zich lekker serieus laten nemen.

Dit was dus al bekend en de update is na de eerste keer dat dit misbruikt werd pas uitgebracht. en Dat duurde zelfs nog een week!

toch vraag ik mij af waarom er aan het begin van dit artikel staat dat het een tot dusver onbekende bug was terwijl er in de quote van het oorspronkelijke artikel staat dat 't al bekend was?

edit:
Ja nu is het flamebait, ik had niets anders verwacht, ga eens serieus op dit soort berichten in in plaats van blind zijn voor de overige informatie in dit geval. Dom kuddevolk
Het is een grote bug, maar geen kritieke bug. Het is een local root exploit. Een aanvaller moet zich dus langs andere weg eerst toegang tot het systeem verschaffen.

6 september is deze bug ontdekt en gerepareerd in de kernel. De exploit is waarschijnlijk daarna pas gemaakt. Dit is dus een nadeel van open source: niet alleen ontwikkelaars, maar ook potentiele hackers krijgen alle informatie over veranderingen, en de redenen daarvoor.

Echter, de patch was al wel beschikbaar. Mensen die doorhadden wat de implicaties waren van deze bug waren er alleen niet. Zowel bij RH (bv Alan Cox en David Miller) als "bij" Debian werken veel mensen die intensief bij de kernel ontwikkeling betrokken zijn. Als de implicaties van deze bug bekend waren geweest hadden deze mensen deze patch al wel in de productie kernel gestopt. Deze distributies gebruiken al geen standaard kernels, maar kernels met allerlei patches. 1 meer of minder maakt dus niets uit.

Wat deze "hacker" (of in ieder geval de programmeur van de exploit) dus beter heeft gedaan dan de lk-developers is inschatten wat de implicaties van de betreffende bug waren.

Dit betekent niet dat mijn vertrouwen in open source in het algemeen en linux in het bijzonder hierdoor geschaad is. Integendeel, er is weer meer bekend over de gevaren van het ontwikkelproces, en de problemen zijn op een goede manier opgelost. Ook is een gevaar geduid wat betreft de manier waarop blackhats te werk gaan.

Als een soortgelijke crack bij windows servers uitgevoerd zou worden, zou er geen community zijn om dit te detecteren. MS zou daar alleen voorstaan. Ze zouden lang niet de informatie en medewerking krijgen die ze nodig hadden om de crack op te sporen, met als gevolg dat deze heel lang kan blijven sluimeren. Ik zou er geen geld op zetten dat dit soort expoits er niet zijn voor windows servers.

edit: typo
Het is een grote bug, maar geen kritieke bug. Het is een local root exploit. Een aanvaller moet zich dus langs andere weg eerst toegang tot het systeem verschaffen.
Waarom krijg ik dan net een mailtje van WideXS dat ze NU alle servers direct gaan upgraden. Normaal hebben ze nooit zo'n haast.
Als een soortgelijke crack bij windows servers uitgevoerd zou worden, zou er geen community zijn om dit te detecteren. MS zou daar alleen voorstaan. Ze zouden lang niet de informatie en medewerking krijgen die ze nodig hadden om de crack op te sporen, met als gevolg dat deze heel lang kan blijven sluimeren. Ik zou er geen geld op zetten dat dit soort expoits er niet zijn voor windows servers.
Ik had uit de berichtgeving nou niet echt de indruk dat er miljoenen 'open source' communicty programmeurs liepen te rennen om het probleem op te lossen. Het waren gewoon de maintainers die het mochten doen om een probleem op te lossen wat al maanden bleek te bestaan.
Waarom krijg ik dan net een mailtje van WideXS dat ze NU alle servers direct gaan upgraden. Normaal hebben ze nooit zo'n haast.
1 mailtje, ik krijg er 4. (iets te veel handles aangemaakt, denk ik)

Maar even on topic:

De meeste Linux servers hebben een heel beperkt aantal gebruikers, meestal alleen de beheerders. Dat geldt echter niet voor de Linux servers bij hosting providers. DIe worden dus ineens heel erg zenuwachtig, want een local root exploit betekent voor hen dat al hun klanten m.b.v. een simpel programmaatje root rechten kunnen krijgen.

Dat soort 'echte' multi-user machines maakt maar een heel klein deel uit van alle in gebruik zijnde Linux bakken. Ter illustratie, ik beheer een dozijn Linux machines, maar ik wordt niet erg zenuwachtig van deze hack. Maar als je WideXS bent wordt je dat *wel*.

Goeie les...
Ja goed, maar had ze die fix dan gewoon 9 weken eerder laten toepassen ipv op het laatste moment...
als widexs het 9 weken eerder hadden geweten had het dat vast wel gedaan
Ja goed, maar had ze die fix dan gewoon 9 weken eerder laten toepassen ipv op het laatste moment...
Ze gaan de boel NU updaten, omdat het een LOCAL root exploit is waarmee IEDEREEN root kan krijgen.

Ik kan me best wel voorstellen dat ze GEEN zin hebben in een HELE lijst van gecompromitteerde SHELL bakken.

Want dat is WideXS toch nog steeds? Vette shell provider :P

DAAROM gaan ze nu zo snel updaten. Wat denk jij dan?
een multi user omgeving met een local root exploit IN de kernel?! Was het nou een suid binary, dan disable je ff die binary tot er een upgrade is.

Nu het bekend is geworden en wat de gevolgen kunnen zijn, is het van "onbeduidende bug patch" verworden tot "critical systems security patch"...
Mnou dat schrijft linux dus af voor mij :+

Kijk eens hoe lang dit al bekend is, zo'n grote bug had toen al wat aan gedaan moeten worden. Nee zo zal linux zich lekker serieus laten nemen.
een gevoel voor ironie heb je wel zo te zien. :)

gelukkig dat ieder OS op z'n tijd ergens last van heeft...
soms ook het hele Internet flood...
laten we met z'n alleen nu maar ICT afschrijven..
...daar is het volgens mij hoog nodig tijd voor ;)

Damn. we kunnen nu zowel op Windows als Linux meer bashen. sorry jongens..!
Kijk eens hoe lang dit al bekend is, zo'n grote bug had toen al wat aan gedaan moeten worden. Nee zo zal linux zich lekker serieus laten nemen.
Het was destijds niet bekend dat de bug exploitable was. Het was dus gewoon een bugje, net als heel veel anderen, en werd dus op dezelfde manier opgelost als heel veel anderen. Als ze toen hadden geweten dat hij exploitable was, dan was er veel sneller wat aan gedaan.
Ja nu is het flamebait, ik had niets anders verwacht, ga eens serieus op dit soort berichten in in plaats van blind zijn voor de overige informatie in dit geval. Dom kuddevolk
Ik gok dat dat komt door je "Mnou dat schrijft linux dus af voor mij" opmerking. Ook "dom kuddevolk" helpt niet echt als je serieus genomen wilt worden of hoog gemodereerd wil worden.
Waar ik naar benieuwd ben is of er ook een losse kernel patch bestaat tegen deze exploit/bug. Ik wil namelijk niet over naar 2.4.23 (heb ik mijn redenen voor).
Sure:

--- a/mm/mmap.c Fri Sep 12 06:44:06 2003
+++ b/mm/mmap.c Thu Oct 2 01:18:19 2003
@@ -1041,6 +1041,9 @@
if (!len)
return addr;

+ if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+ return -EINVAL;
+
/*
* mlock MCL_FUTURE?
*/
weetje wat ik nou vind...
kijk als deze bug was bij microsoft was t gelijk microsoft bashing enzo jaaa kut microsoft blabalbal
maare zodra ze zoiets vinden bij linux is t gelijk van jaaa eigenlijk moeten we de hacker bedanken valt me wel op dat exploits in linux minder erg op in word gegaan want aangezien er heel veel linux servers zijn is dit dus SLECHTE security die hacker kan dus overal in en enige reacties die je derop krijgt is bedank die hacker maar.
als t bij microsoft products was dan was t gelijk van jaaaaaaa klote microsoft met zijn brakke os
terwijl linux eigenlijk ook brak is.
maare zodra ze zoiets vinden bij linux is t gelijk van jaaa eigenlijk moeten we de hacker bedanken valt me wel op dat exploits in linux minder erg op in word gegaan want aangezien er heel veel linux servers zijn is dit dus SLECHTE security die hacker kan dus overal in en enige reacties die je derop krijgt is bedank die hacker maar.
Als je nou goed gelezen had, dan zou je zien dat die betreffende hacker een lokaal account zou moeten hebben/kapen voordat de exploit uberhaupt toegepast kan worden. Het is niet zo dat je even lekker vanaf een lokale machine nu 10.000 Linux servers kunt gaan cracken o.i.d.

Daarnaast was er zeer snel een patch beschikbaar en daar lijkt men hier volledig overheen te lezen. Er is de beslissing genomen om de patch niet meer in te passen in de 2.4.22 kernel, omdat de bug te laat voor deze kernel aan het licht kwam. Dat betekent echter dat het eenieder vrij staat om de 2.4.22 kernel te patchen met de uitgebrachte patch, waardoor je niet meer vatbaar bent voor deze local-root exploit.
als t bij microsoft products was dan was t gelijk van jaaaaaaa klote microsoft met zijn brakke os
Ten eerste komt Microsoft in erg veel gevallen pas zeer laat met fixes. Ten tweede is het altijd closed-source waardoor de kans op exploits die nog niet op grote schaal toegepast worden groter is. Dit zorgt ervoor dat het best mogelijk is dat men op dit moment bijvoorbeeld 10 verschillende exploits beschikbaar heeft die nog niet op grote schaal toegepast worden en zodoende nog niet bij het grote publiek en microsoft bekend zijn. Pas op het moment dat men de exploits op grote schaal gaat gebruiken zal het op gaan vallen.

Bij opensource heb je het voordeel dat enorm veel mensen de source in kunnen kijken. Veelal zijn dit getaleteerde programmeurs. Gevolg is dat veiligheidslekken snel opvallen. Door het grote aantal programmeurs hoef je ook minder bang te zijn dat dingen over het hoofd gezien worden zoals bij bovenstaande scenario wel het geval is.
terwijl linux eigenlijk ook brak is.
Als je ergens geen verstand van hebt lijkt het me sowieso beter dergelijk commentaar voor je te houden ;)
Bij opensource heb je het voordeel dat enorm veel mensen de source in kunnen kijken. Veelal zijn dit getaleteerde programmeurs. Gevolg is dat veiligheidslekken snel opvallen
Anders had het nog langer dan 9 weken geduurd bedoel je. Ik hoor deze argumentatie continu aan maar ik zie steeds meer voorbeelden van fouten die gewoon niet gevonden worden, sommige bugs bleken er al jaren in te zitten.
Natuurlijk zitten in elk stuk software bugs, ook in Linux.
Maar dan kan je nagaan: zelfs als de hele wereld de source code kan lezen blijven er bugs in zitten.
En bij closed source is deze groep nog kleiner...
Euh :? Ik weet niet waar jij normaal zit maar meestal zijn die updates er binnen 1 of 2 dagen bij een ernstig probleem, of het moet gewoon een moeilijke oplossing oid zijn.

En euh.. mja binnen een week... zo kan ik het ook:
This problem was found in September
Inmiddels is er de 2.4.23-kernel voorzien van een fix die de bug verwijderd
Volgens mij is dat langer dan een week?
Een vergelijkbare bug als deze zit sinds jaar en dag ook in windows en wordt daar gewoon helemaal niet gefixed. Microsoft heeft het een feature genoemd omdat ze die bug niet willen oplossen! ;)

edit: waarom wordt een relativerende post als troll gezien?

Een aantal MS fans doen wel heel moeilijk over deze bug, maar dezelfde bug heeft dus ALTIJD al in windows gezeten, en blijft er ook in vanwege compatilibiteits-redenen.

Hoe kan een feit nu een troll zijn :?

* 786562 Gotty
Lees het eens goed, het komt erop neer dat je via een applicatie met administrator rechten (in zijn voorbeeld een virusscanner), de security omzeilt. Het probleem is dus niet zozeer een windows probleem alswel dat bepaalde windows applicaties niet secure zijn.
Nee, lees jij het eens eens goed ;)

Het probleem van het Windows message systeem is dat ieder window een message kan sturen naar ieder ander window, en dat het ontvangende window niet kan controleren waar de message vandaan kwam (!). Daar komt nog bij dat sommige messages bijzonder lompe dingen kunnen doen zonder medeweten of tussenkomst van het doel-window.

Uit de tekst:
Yes, you read that right; you can send any window a WM_TIMER message with a non-zero second parameter (the first is a timer ID) and execution jumps to that address. As far as I know, the message doesn't even go into the message queue, so the application doesn't even have the chance to ignore it. Silly, silly, silly...
Dus je kunt een window van een andere applicatie een WM_TIMER message sturen, en dan gaat die ontvangende applicatie code uitvoeren op het adres dat jij aanwijst! En dat - voorzover de schrijver weet - zonder dat het doel-window dat kan weigeren.

Dat is gewoon lomp. En misschien zijn er wel manieren om daaromheen te komen (mogelijk ten koste van bepaalde functionaliteit), maar als het standaard zo makkelijk is om een andere applicatie te beinvloeden, dan is dat een probleem van Windows, niet van de applicaties.

Dat wil ik overigens wel even veralgemeniseren, want dat geldt voor andere situaties net zo goed: Als een platform zo in elkaar zit dat applicaties voor fatsoenlijke security om het platform heen moeten werken, dan is dat een probleem van het platform, en niet van de applicaties die er niet omheen werken.
Vergelijkbare problemen zouden ook onder *nix kunnen voordoen, als een applicatie onder Root Rechten draait, en kan communiceren met een "user", zou als het programma niet goed in elkaar zit, ook misbruik kunnen worden gemaakt.
Ja, maar dan gaat het specifiek om fouten in de applicatie.

Een goed voorbeeld is XFree86, de meest gebruikte X server op Free OSsen. XFree86 draait als root. Alle X applicaties (die doorgaans als een gewone user draaien) moeten met de X server comminuceren. Als er in de X server een fout zit waardoor een X client meer kan dan hij zou moeten kunnen, dan is dat een security probleem. Van XFree86 wel te verstaan.

Maar de standaard API die door de Linux kernel wordt aangeboden (voornamelijk POSIX plus wat misc. UNIX98 en BSD spul) maakt het niet mogelijk voor user processes om enige invloed op XFree86 uit te oefenen als XFree86 daar niet mee accoord gaat.

En daar zit het grote probleem met MS Windows' messages: windows kunnen een (te) grote invloed uitoefenen op andere windows zonder dat het doelwindow daar om vraagt of mee accoord gaat.
Daarnaast is het zo, dat het op windows machines niet erg gebruikelijk is om andere mensen zomaar visueel toegang te geven (zeker niet op servers).
Nou... Op desktops en workstations dus juist wel he :)

Wat betreft servers heb je gelijk, daar zal dit gebrek niet zo snel problemen opleveren, maar het is en blijft een fundamenteel win32 probleem.
het zou misschien helpen als je je "kritische feiten" met een beetje onderbouwing zou brengen. Windows en linux zijn weinig compatible mt elkaar, dus het komt op 99% van de gebruikers vreemd over dat een linux bug ook al lang in windows zit. Als je nou een linkje zou posten, met uitleg over dit probleem, of een fatsoenlijke uitleg erbij zet, dan kijg je in no-time een "+4 interessant". Als je in je post gaat lopen huilen over je moderatie dan zit er niet meer in dan een "0-gemodereerd"
Deze link is al eerder in deze draad genoemd.
http://security.tombom.co.uk/shatter.html
Het is best makkelijk om een windowsmachine op die manier te cracken. Een vriend van me heb ik het zien doen. Echt zo gepiept :) Kind kan de was doen.


Dat je die link niet hebt gezien is misschien omdat deze onder het maaiveld is gemod door een MS-fan. :( Mooie boel weer hier op T.net.

* 786562 Gotty
Veel Linux-fans kennen die beveiligingsgaten in windows namelijk wel. Oh, w8..... DAAROM gebruiken ze ook liever geen windows :P
Lees het eens goed, het komt erop neer dat je via een applicatie met administrator rechten (in zijn voorbeeld een virusscanner), de security omzeilt. Het probleem is dus niet zozeer een windows probleem alswel dat bepaalde windows applicaties niet secure zijn. Auteur geeft te kennen dat dit puur een windows probleem is, maar dat is bullshit.

Vergelijkbare problemen zouden ook onder *nix kunnen voordoen, als een applicatie onder Root Rechten draait, en kan communiceren met een "user", zou als het programma niet goed in elkaar zit, ook misbruik kunnen worden gemaakt.

Ik moet wel zeggen dat het windows messaging systeem alles behalve solide in elkaar zit, als ik de auteur mag geloven, maar om nou te gaan roepen dat windows dan niet secure is, is overdreven.

Daarnaast is het zo, dat het op windows machines niet erg gebruikelijk is om andere mensen zomaar visueel toegang te geven (zeker niet op servers).
Ja, Uiteraard probeert microsoft de onoplosbare beveiligingsgaten in windows te verdoezelen. Desondanks leveren ze zelf overtuigend bewijs om Linux te gebruiken.

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/col umns/security/essays/10imlaws.asp
MS en linux vind ik over het algemeen best snel met het patchen, maar het grootste probleem blijft hem toch wanneer de gebruikers zelf patchen....
(kijk maar naar blaster, was al maanden een patch voor)
Wat ik me nu afvraag:
Nu moeten de gebruikers zelf dit patchen (nieuwe kernel compilen?)
Maar ondertussen is wel openbaar gemaakt hóé deze bug precies werkt... dus totdat iedereen gepatched is, zijn alle linux server kwetsbaar, omdat de handleiding op straat ligt.
Had men dan niet beter kunnen patchen en even wachten met de uitleg hóé het gebeurt is, zodat iedereen de tijd heeft om te updaten?
Nu moeten de gebruikers zelf dit patchen
2.4.23 (die al enkele dagen uit is) is gepatcht.
2.6.0-test6 en hoger is gepatcht.
2.2 en 2.0 zijn niet vulnerable.

Alle trees die er (nog minstens een beetje) toe doen zijn dus al gepatcht.
Ik vraag me toch af of dit probleem vergelijkbaar is. Immers, men is eerst een tijd bezig geweest om te achterhalen wat de bug daadwerkelijk was.
Als je een admin wachtwoord steelt dan ben je binnen. Als je een wachtwoord steelt met restricties dan zal je flink moeten werken om 'root-access' op je eigen machine te krijgen, laat staan op een server.
Hm, ik denk dat dat bij windows nog wel meevalt. Er zijn genoeg dll bestanden te wijzigen die bij het opstarten van de computer als service dienen.
Wanneer je daar iets als een telnet service inbouwd of wat dan ook, dan heb je meteen root rechten, omdat zon service altijd op rootrechten loopt.

[edit = typo]
Hm, ik denk dat dat bij windows nog wel meevalt. Er zijn genoeg dll bestanden te wijzigen die bij het opstarten van de computer als service dienen.
Wanneer je daar iets als een telnet service inbouwd of wat dan ook, dan heb je meteen root rechten, omdat zon service altijd op rootrechten loopt.
Gebruik geen FAT32 maar NTFS. Zet dat soort dingen dicht voorzover dat nog niet zo is. Gebruik security templates. Zo moeilijk is het allemaal niet hoor. services kunnen trouwens ook onder een user account lopen.
NTFS moet je nooit gebruiken op een systeem. Het is ontworpen door MS en die houdt de structuur uiteraard weer geheim. Daardoor is het nog steeds niet perfect geimplementeerd.

Ik zou OF voor FAT32 gaan als je persee windows ernaast wilt, maar liever helemaal geen FAT of NTFS.

ReiserFS of Ext2/3 zijn de beste keuzen. Deze zijn ook speciaal voor Unices ontworpen.
Laatste keer dat ik keek werkte ReiserFS niet echt in Windows...
Laatste keer dat ik keek werkte ReiserFS niet echt in Windows...
Tsja, daar blijf je mee zitten heh. Tot het meer marktaandeel krijgt blijft die ondersteuning van volwassen serverpartitietypes onder de maat...
:P
(sorry, kon het niet laten)
Laatste keer dat ik keek werkte ReiserFS niet echt in Windows...
Beter kijken.

Overigens is het een ietwat andere situatie. Van ReiserFS zijn de specificaties gewoon open, dus als daarvan geen implementatie is voor een bepaald OS, dan is dat puur door gebrek aan belangstelling. In het geval van NTFS is de reden voor gebrekkige / afwezige implementaties dat Microsoft de specificatie niet wil geven.
[off topic]
Microsoft heeft een SDK om een file system driver te maken, zodat je een andere drive erbij krijgt. omdat deze SDK dermate veel kost, is er geen stabiele driver voor bijvoorbeeld ext2, of reiserfs.

en zitten we dus vast aan een externe verkenner, of in dit geval een command line voor reiserfs :( ik vind het dus niet echt een oplossing. Voor ext2 drives gebruik ik explore2fs.
Je gaat even voorbij aan de windows-integriteitswaakhond WFP...
Pleur de nieuwe DLL in dllcache, kijk es hoe mooi WFP je aangepaste DLL "terugzet" in de system32 directory ;)
...die over het algemeen uitstaat omdat je daar in het dagelijks gebruik helemaal strontziek van wordt.
Services hoeven niet met administrator (=root) rechten te lopen onder windows. Veel serieuze programma's vragen je bij de installatie expliciet welke account er moet worden gebruikt voor de services. In dat geval kun je zelf de rechten bepalen.
Programma's als IIS zijn ook deels geintegreerd in de kernel, onveiliger kan het haast niet.

Toch zijn er andere problemen in Windows; ik citeer:
...by Microsoft VP Jim Allchin who stated, under oath, that there were flaws in Windows so great that they would threaten national security if the Windows source code were to be disclosed.
http://security.tombom.co.uk/shatter.html

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True