Als je wat meer info wil over de exploit techniek kan ik je een pb-tje sturen. Ik kan helaas niet vertellen waar de bug precies is.
Waar die exact zit maakt me niet uit, ik ken Linux toch niet goed genoeg om daar ook maar iets mee te kunnen
Maar als je een textfile oid hebt met de exploit techniek, dan wil ik die wel 's doorlezen...
Ok, hier komt ie dan :
Het komt er op neer dat je met deze bug op ieder gewenst geheugen address een integer decrement doen. Dit is genoeg om code in kernel land uit te voeren.
Onder linux (en onder eigelijk ieder ander modern os) is kernelland(geheugen waar de kernel in draait) gescheiden van userland (normale applicaties).
Op x86 heb je verschillende privileges modes; aangegeven met CPL. (Current Privilege Level) Kernelland draait in ring 0 (CPL = 0) en userland in ring3 (CPL = 3).
Linux gebruikt 'virtual memory'; dat wil eigelijk zeggen dat een geheugen address voor een applicatie niet overeen komt met het echte fysieke address in het geheugen. De kernel vertaalt dit.
Kernel memory begint vannaf het address 0xc0000000; alles eronder is voor userland.
Op x86 heb je een IDT (interrupt descriptor table). Dit is een tabel waarin staat hoe hardware en software interrupts afgehandeld moeten worden. Met de instructie 'sidt' verkrijg je het address van deze table. Deze table is een array van interrupt gate descriptors. Een interrupt gate descriptor houdt de informatie over een interrupt; het geheugen address waar naar toe gesprongen moet worden als de interrupt gegenereerd word, en welk CPL er vereist is. Een igd is 8 bytes groot; als je dus bijv. wilt weten hoe interrupt 0x80 wordt afgehandeld dat moet je het base address (wat je met sidt kan verkrijgen) + 8 * 0x80 doen.
Okee, ff terug naar de bug.
Met deze bug kon je dus een integer decrementen. Ik decrement de most significant byte van de interrupt gate descriptor voor interrupt 3.
Interrupt 3 wordt gebruikt door debuggers om breakpoints te zetten en kan worden getriggerd vannuit userland. Door de msb van '0xc0' (kernel land) naar '0xba' oid te decrementen, wijst de interrupt 3 handler ineens naar userland. De exploit mmap-ed dit address; en zet er eigen code neer, die dus met CPL 0 uitgevoerd gaat worden als er een int 3 getriggered word. De code die er staat verkrijgt het address van de task structure; een structure waarin de uid/gid/euid/egid/etc. staat voor het huidige address en zet deze op 0.
Het komt er op neer dat je met deze bug op ieder gewenst geheugen address een integer decrement doen. Dit is genoeg om code in kernel land uit te voeren.
Onder linux (en onder eigelijk ieder ander modern os) is kernelland(geheugen waar de kernel in draait) gescheiden van userland (normale applicaties).
Op x86 heb je verschillende privileges modes; aangegeven met CPL. (Current Privilege Level) Kernelland draait in ring 0 (CPL = 0) en userland in ring3 (CPL = 3).
Linux gebruikt 'virtual memory'; dat wil eigelijk zeggen dat een geheugen address voor een applicatie niet overeen komt met het echte fysieke address in het geheugen. De kernel vertaalt dit.
Kernel memory begint vannaf het address 0xc0000000; alles eronder is voor userland.
Op x86 heb je een IDT (interrupt descriptor table). Dit is een tabel waarin staat hoe hardware en software interrupts afgehandeld moeten worden. Met de instructie 'sidt' verkrijg je het address van deze table. Deze table is een array van interrupt gate descriptors. Een interrupt gate descriptor houdt de informatie over een interrupt; het geheugen address waar naar toe gesprongen moet worden als de interrupt gegenereerd word, en welk CPL er vereist is. Een igd is 8 bytes groot; als je dus bijv. wilt weten hoe interrupt 0x80 wordt afgehandeld dat moet je het base address (wat je met sidt kan verkrijgen) + 8 * 0x80 doen.
Okee, ff terug naar de bug.
Met deze bug kon je dus een integer decrementen. Ik decrement de most significant byte van de interrupt gate descriptor voor interrupt 3.
Interrupt 3 wordt gebruikt door debuggers om breakpoints te zetten en kan worden getriggerd vannuit userland. Door de msb van '0xc0' (kernel land) naar '0xba' oid te decrementen, wijst de interrupt 3 handler ineens naar userland. De exploit mmap-ed dit address; en zet er eigen code neer, die dus met CPL 0 uitgevoerd gaat worden als er een int 3 getriggered word. De code die er staat verkrijgt het address van de task structure; een structure waarin de uid/gid/euid/egid/etc. staat voor het huidige address en zet deze op 0.
Uitspraak van Ruben Swart op vrijdag 25 november 2005 om 15:02:novell
heb ik ooit mee gewerkt Noven 3.12
Zeker een fijn proggie
Uitspraak van Ruben Swart op vrijdag 25 november 2005 om 15:17:bsod's
komt meestal door al die HW die wij gebruikers erin trappen
Ik draai nu al kleine 2 jaar op me xp prof en nog nooit een bsod gehad
maar rave.. waarom kunnen *nix distro's er wel mee omgaan?? en windows niet
uuuhhhh
Ik denk dat MS hun systemen zoveel mogelijk compatibal wil hebben dat er drom ook zoveel probs mee komen.
Denk ik hoor ikzelf heb nooti probs. ik blijf er bij dat het aan de gebruiker ligt en niet percee aan de OS
Wat wel met MS is is hun security op de kernel.
Omdat MS hun systemen natuurlijk snelelr wilde hebben(eis van de gebruikers) is dat ten koste gegaan van de security van de MS Kernel.
De nieuwe OS van MS zal ook van scracht opgebouwd worden en niet de NT kernel gebruikt worden dus ben benieuwd
Maaruhh Agrixie ik ga eindelijk gebinnen met Linux 035 cursus eerst
Wat wel met MS is is hun security op de kernel.
Omdat MS hun systemen natuurlijk snelelr wilde hebben(eis van de gebruikers) is dat ten koste gegaan van de security van de MS Kernel.
Omdat MS hun systemen natuurlijk snelelr wilde hebben(eis van de gebruikers) is dat ten koste gegaan van de security van de MS Kernel.
Veilig coden hoeft niet per definitie een performance offer te zijn. De meeste security bugs komen door slordigheidjes van de programeurs. Bijvoorbeeld door het niet controleren van de lengte van data voordat het naar een buffer gekopieerd word of het niet goed locken van een globale variable.
Een check voordat data gekopieerd word levert misschien een paar extra instructies op, wat niet ineens merkbaar is.
Bij veel Microsoft producten lijkt het wel of de code nooit verbeterd is; sommige bugs treffen alle versies van Windows.
Leuk voorbeeld: http://esdee.netric.org/kapot/jolijt.jpg
Standaard stack overflow in Outlook 97 t/m 2003.
Of ze maken de fout steeds opnieuw of de code is jaren niet veranderd.
Ik denk btw dat windows vrij slecht uit een (lokale) benchmark tests zal komen, puur omdat het niet de beschikking heeft over directe system calls en erg afhankelijk is van libraries. Ik denk dat freebsd of linux 2.6.x qua performance beter uit de test zullen komen.
Een intressante benchmark test met (netbsd/openbsd/freebsd/linux 2.4 en linux 2.6):
http://bulk.fefe.de/scalability/
Leuk om te zien hoe openbsd belachelijk laag scored
laatste aanpassing
Ok, hier komt ie dan :
...
De code die er staat verkrijgt het address van de task structure; een structure waarin de uid/gid/euid/egid/etc. staat voor het huidige address en zet deze op 0.
Ik blijf altijd weer verbaasd hoeveel sommige (nog jonge) hackers weten. Deze bug zelf gevonden? Overigens, als je elk willekeurig geheugen adres kunt decrementen, dan zullen er toch veel meer mogelijkheden zijn voor privilege escalation?
En welke mogelijkheden zijn er eigenlijk om dit te beveiligen? Het lijkt me dat de kernel met een paar simpele instructies het adres moeten kunnen checken, voor te jumpen. Alhoewel dat misschien wel wat met je performance doet, interrups komen vrij vaak voor.
maar rave.. waarom kunnen *nix distro's er wel mee omgaan?? en windows niet
Ik denk dat het grotendeels tot ontwerp keuzes te herleiden is. Unix (en ook Linux) zijn gewoon met een wat ander idee ontworpen dan Windows. Bovendien zit MS rotsvast aan hun OS omdat ze veel backwards compatibility moeten garanderen.
Daarnaast is het ook een feit dat de meeste Unix/Linux gebruikers standaard niet als root werken; de meeste Windows gebruikers daarentegen werken altijd als administrator. Dit heeft zeker invloed op de gevolgen als malware op de machine terecht komt.
Uitspraak van Tha_RaveBeast op vrijdag 25 november 2005 om 16:04:De nieuwe OS van MS zal ook van scracht opgebouwd worden en niet de NT kernel gebruikt worden dus ben benieuwd
Heb je daar een bron voor? Afaik heeft Vista nog gewoon een NT kernel. Toevallig ben ik afgelopen woensdag ook bij een presentatie van MS over Vista geweest. Daar heb ik specifiek gevraagd naar interessante wijzigingen in de kernel, waar ik helaas geen antwoord op kreeg. Ik krijg het idee dat helaas de meeste wijzigingen zich wat 'hoger' in het OS bevinden, zoals WinFS, Aero en Indigo etc.
Veilig coden hoeft niet per definitie een performance offer te zijn. ... Een check voordat data gekopieerd word levert misschien een paar extra instructies op, wat niet ineens merkbaar is.
Een makkelijkere manier om dit te verhelpen is imho het gebruik van managed code (Java, .NET). Programmeurs zullen toch altijd fouten blijven maken en voor de meeste applicaties heeft managed code geen nadelen, maar wel voordelen.
Natuurlijk heb je voor een OS altijd nog stukjes assembly nodig (bijv. bootstrap), maar zoals MS aantoont met Singularity kan het overgrote deel van een OS best uit managed code bestaan.
k blijf altijd weer verbaasd hoeveel sommige (nog jonge) hackers weten. Deze bug zelf gevonden? Overigens, als je elk willekeurig geheugen adres kunt decrementen, dan zullen er toch veel meer mogelijkheden zijn voor privilege escalation?
De techniek om deze bug te triggeren komt van ilja (een mede netrican en collega
Ik heb in de tty layer van linux nog meer van dit soort bugs gevonden.
De techniek wordt binnenkort in een presentatie gedisclosed. (waar ik het overigens niet helemaal mee eens ben
Er zijn inderdaad veel meer manieren om dit te exploiten; alleen het mooie van de IDT approach is dat het compleet zonder kernel symbols kan; de instructie 'sidt' kan iedere userland applicatie uitvoeren om het base address te achter halen... Het probleem als je bijv. direct je uid wil decrementen is dat je het address van de task struct niet weet. Je zou bijv. ook een syscall in de systemcall table naar userland kunnen laten pointen, maar ook dit address kan je zonder kernel symbols niet weten. Opzich zou de kernel kunnen checken of interrupt niet naar userland pointed, maar dit is niet echt de oplossing; in eerste instantie mag een userland applicatie niet op deze manier data manipuleren in kernelland.
De idt is btw ook een evil manier om een machine te backdooren; je kan bijv. je eigen int 0x80 handler instaleren en zo system calls redirecten. De standaard tooltjes als chkrootkit checken alleen of de systemcall table nog in tact is en zullen dus niks zien.
Een makkelijkere manier om dit te verhelpen is imho het gebruik van managed code (Java, .NET). Programmeurs zullen toch altijd fouten blijven maken en voor de meeste applicaties heeft managed code geen nadelen, maar wel voordelen.
Dit zou inderdaad heel veel standaard security bugs verhelpen. (stack/heap/whatever overflows, formatstring bugs) (logic bugs/race conditions blijf je behouden)
Punt is natuurlijk wel dat het in plain c altijd wat sneller zal zijn. Voor sommige applicaties maakt dat niet uit; maar voor kernels of webservers kan dit heel veel uitmaken.
De meeste webservers worden zo efficient mogelijk geschreven; threading/multiplexing (select/poll, epoll, kqueue, etc) daar zou de overhead van java de boel alleen maar vertragen.
wat ik ook erg jammer vind is dat bijvoorbeeld laptop distributeurs je wel garanderen dat linux goed op de laptop draait maar dat ze nooit een goede .config aanbieden
ik heb bijvoorbeeld een fujitsu lifebook (s7010d) hier heb vreselijk veel problemen gehad met bouwen van een goede kernel.. hij zit nu vol onnodige modules (wat gewoon heel vies eruit ziet) en ik heb gewoon geen zin meer om te kijken waar precies het probleem zit
ik heb bijvoorbeeld een fujitsu lifebook (s7010d) hier heb vreselijk veel problemen gehad met bouwen van een goede kernel.. hij zit nu vol onnodige modules (wat gewoon heel vies eruit ziet) en ik heb gewoon geen zin meer om te kijken waar precies het probleem zit
laatste aanpassing
Uitspraak van verwijderd op zaterdag 26 november 2005 om 03:58:xp sp2 is traag als strong
Ik denk dat je stront bedoeld???
Nou koop dan eens een normale computer die van deze tijd is of minimaal een procesor van 2ghz enb 256 mb geheugen heeft want daar werkt het lkkr op.
Zelf heeft me pc een p4 3.2 ghz procesor en 2048 mb geheugen.
macos x86
virtueel mac osx?
Uitspraak van verwijderd op maandag 28 november 2005 om 21:29:minimaal een procesor van 2ghz enb 256 mb geheugen
het is echt wel moeilijk
Iemand anders een idee voor een virtueel mac osx?
tiger-x86.tar.bz2
VMWare image... wel een Intel CPU + Chipset nodig (duh).
Stuur maar een pb als je em wilt hebben.
Ohja: http://www.360hacker.net/forums/viewtopic.php?p=1108
laatste aanpassing
het is echt wel moeilijkheb je je zelf er wel eens over horen praten of het de gewoonste zaak van de wereld is
ik snap er de balle niet van ben blij dat ik de aan en uit knop al kan vinden
is mischien maar goed ook
het is goed dat je er niks vanaf weet, want dan weet je ook dat je niet gaat verkennen waarbij het mogelijk wordt dat je dingen kapot gaat maken
Uitspraak van verwijderd op maandag 28 november 2005 om 21:29:Zelf heeft me pc een p4 3.2 ghz procesor en 2048 mb geheugen.
me2 4 x 512mb DDR 400.
De nieuwe OS van MS zal ook van scracht opgebouwd worden en niet de NT kernel gebruikt worden dus ben benieuwd
Heb je daar een bron voor? Afaik heeft Vista nog gewoon een NT kernel. Toevallig ben ik afgelopen woensdag ook bij een presentatie van MS over Vista geweest. Daar heb ik specifiek gevraagd naar interessante wijzigingen in de kernel, waar ik helaas geen antwoord op kreeg. Ik krijg het idee dat helaas de meeste wijzigingen zich wat 'hoger' in het OS bevinden, zoals WinFS, Aero en Indigo etc.
Nee ik heb daar geen bron voor.
Mijn bron was een Princepal Engineer ik had het met um over de kernel en vond dat de security slecht is van MS.
Je kan via een.jpg in de kernel komen
Uitspraak van Tha_RaveBeast op dinsdag 6 december 2005 om 15:24:Je kan via een.jpg in de kernel komen
Dat kan op unix ook?!
Uitspraak van the man on the couch op dinsdag 6 december 2005 om 15:36:Dat kan op unix ook?!
Ik ken Unix niet
Gebruik het alleen voor onze ftp server that's all.
Dus geloof je best alleen MS is makkelijekr te hacken dan Unix d8 ik zo
Uitspraak van Tha_RaveBeast op dinsdag 6 december 2005 om 16:02:Dus geloof je best alleen MS is makkelijekr te hacken dan Unix d8 ik zo
Hoevaak hack jij?
Uitspraak van the man on the couch op dinsdag 6 december 2005 om 16:11:Hoevaak hack jij?
tijdens mijn it carriere bedoel je?
ongeveer never
Ik deed project management voor EMEA dus hoef niet te hacken
Maar er zitten hier Teckies
Uitspraak van verwijderd op zaterdag 26 november 2005 om 03:58:windows 2000 of een of andere linux
xp sp2 is traag als strong
Omg hou op zeg
Fedora Core 3 met Gnome, DAT is pas traag als dikke stront.
tja moet je ook geen fedora draaien draai dan debian ofzo
Debian... brr, stone-age software gebaseerd op een gaar package system.
cenobyte: check http://bulk.fefe.de/scalability/
2.6 komt goed uit de test
Ziet er goed uit, wel veel OpenBSD bashing though...
Zal wel geschreven zijn door een gefrustreerde Linux aap
Ken je deze al:
http://www.gnome.org/~lcolitti/gnome-startup/analysis/















