Windows NT/2k code uitgelekt

Zou het waar zijn?

Volgens mij gaat dit, ALS het waar is, enorme gevolgen hebben.

Ben trouwens zelf ook best benieuwd naar de code, zou er wel eens even doorheen willen snuffelen


Nieuwsberichten:
http://zdnet.com.com/2100-1104_2-5158496.html
http://www.infoworld.com/article/04/02/12/HNmicroleak_1.html

Andere linkjes:
http://heim.ifi.uio.no/~mortehu/files.txt
http://www.xs4all.nl/~reije081/xp00.png
http://www.xs4all.nl/~reije081/xp01.png

ff denken, welke PHP versie installeert apt get als stable? 4.1.2 (zijn nu bij 4.3.4). Welke Apache versie? 1.3.26 (zijn nu bij 1.3.29).

Ze zullen er ongetwijfeld hun redenen voor hebben, maar geef mij maar gewoon recente versies...



Ehhm, wat zijn PaX achtige kernel patches?



Als je MacOS X er cooler uit vond zien had ik je serieus kunnen nemen. Maar ik snap niet wat jij cooler vind aan X Windows icm Gnome of KDE..

Ik vind *nix qua windowmanager altijd nog inferieur aan Windows, oa qua performance. Hier verwacht ik de komende jaren ook nog geen verandering in...

PaX is een kernel patch voor linux, die bijv:

- Shared lib base address randomized (libraries worden dan steeds op een ander address geladen, om return-into-libc attacks te voorkomen)
- Non exec pages (bepaalde memory pages hoeven niet executable te zijn, bijv de stack, data of heap, hier worden in princiepe alleen data van de applicatie opgeslagen, en geen echte code dat uitvoerbaar moet zijn.)
- randomized stackbase.

Hierdoor worden standaard bufferoverflows een stuk moeilijker om te exploiten, remote zonder infoleak is het prolly helemaal niet meer mogelijk in sommige gevallen.

Het is niet 100% waterdicht denk ik, ik heb een theorie om PaX te verslaan, maar dat is alleen een theorie

Het zit standaard bij grsec, een aantal patches die nog wat andere dingen doen:
- users kunnen alleen hun eigen processen zien
- disablen van /dev/kmem en /dev/mem
- hiden van kernel symbols
- verder disabled het nog wat stuff in /proc,
zoals /proc/net/, maps, en andere stuff.

Allemaal stuff, waardoor local users niet echt veel meer kunnen op je bak, en bijv kernel rootkits zich niet meer makkelijk laten instaleren

http://pax.grsecurity.net

OpenBSD heeft een soort gelijk systeem (W ^ X)

dat zit toch al in grsecurity? of ben ik nou gek?

GRSecurity ken ik wel (van horen zeggen van klasgenoten). Maar goed, voor mijn eigen servertje vind ik persoonlijke zulke stappen net iets te overdreven (net niet security minded genoeg )

Juh, PaX zit bij grsecurity.

Opzich kan je niet paranoia genoeg zijn Bovendien stoppen die patches de meeste standaard exploits wel, dus mocht je een keer op vakantie zijn en een of andere whitehat released weer een volledige werkende openssh exploit...

Elke UNIX heeft daar last van want dat probleem beperkt zich niet alleen tot OpenBSD. Linux heeft ook zijn flaws in de kernel, ptrace, dobrk etc etc.



Ze zeggen niet 1 remote hole in het Operating System, maar in de default install!
Daar kan een Redslet systeempje wel een pluim aanzuigen!

En die challenge response bug was niet te exploiten zonder eerst de sshd_config aan te passen. Niet exploitable op een default install dus



Het is dat Itchie geen communist is want anders had ik gedacht dat...

En wat Pax betreft, jij hebt ook zo je ideeen om Pax evasive shit te schrijven dus we komen tot de conclusie dat alles gewoon vuln blijft!
En OpenBSD doet er imho meer aan security out of the box dan bijvoorbeeld SuSE. Alhoewel ik ergens gelezen had dat Fedora nu standaard met exec_shield geshipped wordt.

OpenBSD heeft secure levels, zou van mij ook best in Linux geimplementeerd mogen worden.

Neem bijvoorbeeld CDE icm een Sparc systeem...
Als je daar 1maal mee gewerkt hebt dan wil je nooit meer anders. Sun type 5 en 6 keyboards hebben "cut" "past" "front" buttons waarmee je super snel je windows hide en tevoor schijn tovert en stukken tekst cut 'n past.
Het gemak van meerdere schermen waarin je kunt werken owned ass!

Sun is nu bezig met looking glass:

http://wwws.sun.com/software/looking_glass/demo.html

Ga maar kwijlen

Als je 1maal UNIX gewend bent als desktop en je zit achter een Windows machine dan ben je belemmerd in snel en functioneel kunnen werken

Het ligt altijd nog aan de admin. Default is openbsd misschien veiliger dan een default linux install, maar like degene die dan die default linux install beheert is dan ook behoorlijk clueless bezig

Die claim van openbsd geeft nogal een vertekend beeld:

zo is bijv ook apache lek geweest, en ja hoor.. apache staat default niet aan. Alles disablen is natuurlijk geen security.

(het leuke was btw dat die bug alleen te exploiten was onder BSD systemen, ivm een speedhack in hun memcpy() implementatie)

Waar ik me ook best aan erger, is dat veel dingen op errata vermeldt worden als 'potential denial of service' terwijl er allang en breed dikke local root exploits in omloop zijn.

Ik ben het met je eens dat een default openbsd install veiliger is, alleen er zijn ook linux distros met leuke securityfeatures, met minder arrogante developers

*nix heeft mij als desktop echt nog niet kunnen overtuigen. Heb toch een aantal linux installaties als dual boot gehad en tegenwoordig altijd wel een partitie van FreeBSD voorzien, maar toch ga ik voor desktop dingen altijd nog naar XP. Enige voordeel van FreeBSD is (vind ik, misschien heb ik er nog niet genoeg moeite in gestoken) de krachtige shell...

Nee die bug is op *alle* systemen te exploiten waar het op OpenBSD dmv de crappy memcpy implementatie was... Gobbles vermelde duidelijk dat het hun gelukt was op Linux, BSD en Solaris.
Of het bullshit aan hun kant is weet ik niet, jij waarschijnlijk wel... maar als zij dat beweren in hun sploit zal het wel waar zijn toch?

En dat ze arrogant zijn, och valt wel mee!
Ze houden gewoon niet van bullshit
Ik heb ook zo nu en dan een flame gekregen als ik een .diff mailde met wat changes die niet goed waren. BSD is just a way of life!

gobbles blufte
daar ben ik echt zeker van.

De bug was dat er een signed integer aan memcpy werd door gepaast, en een boundscheck in de trant van 'if (size > 1024) exit(EXIT_FAILURE)', omdat size signed was, kon je het zo groot maken, (groter dan 0x80000000) waardoor de integer naar negatief klapte, en die boundscheck voorbij kwam.

Aangezien memcpy() een unsigned integer als length parameter wil, zal memcpy() bij bijv -1 4 gb gaan kopieeren.

Dat is een dikke stack overflow, alleen memcpy blijft doorgaan tot hij bij 0 is, en 4 gb kopieeren naar de stack gaat niet lukken.

gobbles had een truuk:
in de memcpy() van BSD zat een speedhack, in sommige gevallen gebruikte het memmove().

memmove kopieert de data met blokken van 4 bytes,
dus je houdt altijd 0 tot 3 'rest' bytes over.
Hij kopieert die 1 - 3 rest bytes eerst, voordat hij begint. Die kopieerde hij naar dst + size.
Aangezien size negatief was, kon je dus overal op de stack 1 tot 3 bytes writen, en de size parameter van memcpy() stond zelf op de stack,
en werd ingelezen na die kopieer actie.

je kon van die 0xffffffff, iets van 0x0000fffff maken, waardoor het een normale stackoverflow werd.

memcpy() van linux gebruikt zoiezo geen memmove, en stored de size parameter in een register.

gobbles blufte dus, alhoewel in eerste instantie gedacht werd dat het onder bsd ook niet kon

maar er hebben echt veel mensen naar gekeken,
die chunk encoding bug is nu alleen onder bsd en onder windows geexploited.

bleh .. wat een lap tekst

Badass eSDee...

Okee jij hebt meer insight dan ik

Hehe, nooit gedacht zoiets nog te lezen op PF

Gaat me nog net wat boven de pet, dit is wel hacken voor gevorderden

zal dit nog gevolgen hebben voor windows longhorn ???

Neuh, alle mogelijke exploits worden toch wel gevonden voordat Longhorn zijn RTM build gehaald heeft.

laat mij maar lekker in Windows clicken en af&toe WindowsUpdate.com bezoeken ... wat een nerd-talk hiero

En jij bent IT'er?

Ik heb ooit eens in een wazige bui Suse erop gezet en daarna Redhat
Automatisch werd die KDE geinstalleerd, ik vond het er mooi uitzien.
Alleen het werkt trager, dat is dan nog een groot nadeel.
Voor de rest heb ik nooit met Linux en desktop gewerkt.
Ik doe alles vanaf met de prompt.




Dan vindt Debian hem waarschijnlijk niet stabel genoeg.
Ik weet niet wat er voor belangrijke grote verschillen zitten tussen php4.1 en 4.3, maar het lijkt me nihil, helemaal als het om security gaat.
Apache is een ander verhaal.

Klopt, Debian is erg conservatief. Daar ben ik het zelf niet mee eens, PHP 4.3.4 heeft wel degelijk voordelen boven 4.1.2 Er zijn een redelijk aantal functies toegevoegd (bv. proc_open()) en daarnaast meen ik me te herinneren dat er bij 4.1.2 een DoS attack mogelijk was. Een paar versies achterlopen kan ik best begrijpen als stabiliteit je voornaamste zorg is, maar een PHP versie van bijna 2 jaar oud (27-Feb-2002) vind ik overdreven. De changelogs van de versies erna zijn nou niet echt te verwaarlozen meen ik...



Geef ik je helemaal gelijk in. En juist hierom neem ik Linux als Desktop nog niet zo serieus. Als server verdient het imho absoluut zijn plaatsje naast de Windows en Unix servers.

Ik ben zeker de enige hier die dit soort dingen grappig vind

damn waarom heb ik nou weet niet realplayer
Ik wil gewoon pics zien daarvan!
Kun je misschien wat plaatjes uit dat filpje schieten?

Is dit het?

Zon desktop wil je toch niet zeker

Ik heb gister het filmpje van die desktop gezien, en het leek me toch zeker wel een heel fijne desktop. grafische ziet die er goed uit, en 3d heeft zijn voordelen.

Zelf denk ik dat dit binnen een paar jaar wel de nieuwe generatie desktops gaat worden.

Lijkt me echt bijzonder waardeloos en systeembronnen verslindend, maar ja ieder het zijne zal ik maar zeggen

systeembronnen verslindend natuurlijk wel, maar nog wel mooi, met een krachtige computer

Veel plezier:
http://milo.corks.nl/msmail.txt

Was te verwachten dat MS hier snel en hard tegenop zou treden... Ik heb de eer om het vroeg op usenet te posten iig ook mooi voorbij laten gaan, brand mijn vingers hier liever niet aan