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

Tja local bugs onder windows boeien geen fuck. Er zijn zoiezo al genoeg shatter exploits voor windows.

maarja.. de jpg/png parser code zit er geloof ik ook bij, als daar bugs in gevonden worden zouden die remote getriggerd kunnen worden. (bijv. door IE, of outlook) kan je er nog wel wat lol mee beleven

kom net uit me werk kzag het net pas

een paar gasten die ik ken hebben ook al een stuk code. Maar ik vraag me ag hoe groot de gevolgen zijn want ik denk dat ze bij microsoft ook constant code zitten te analyseren. Ze brengen hiervoor ook patches uit en het stuk dat nu gelekt is zal wel de hoogste prioriteit krijgen. afwachten dus

ben 'm aan het binnen halen.. kben bnieuwd

[esdee@flopppp research]$ du -H windows_2000_source_code.zip
214MB windows_2000_source_code.zip


het staat zo'n beetje overal op internet nu.

lollige comments btw:

./private/shell/shell32/util.cpp:// around the fucking peice of shit compiler we pass the last param as an void *instead of a LPITEMIDLIST
./private/shell/shell32/util.h:// the fucking alpha cpp compiler seems to fuck up the goddam type "LPITEMIDLIST", so to work

etc..

Ik heb m op 203 MB

Maar goed, dat programmeurs af en toe leuk commentaar toe kunnen voegen is al wel duidelijk uit de linux sources

Vaak halen ze dat er trouwens wel uit (helaas!).

Ah linux is een bij1geraapt zooitje, kies voor OpenBSD! Strakke ansi c code, geen bullshit, (bijna) clean knf source, geen gpl shit etc etc!
Mahja, ik ga naar bed... laterz

FreeBSD is tot nu toe mijn *nix favoriet Zal voorlopig nog wel even zo blijven

Heb net even anderhalf uur source zitten doorsnuffelen, zijn toch wel een aantal dingen waar ik van op kijk en waarvan ik denk dat MS er ook niet blij mee zal zijn dat dit nu op straat ligt

ja ach, naar voor bill ....

still linux rules

linux != rules

Er is geen enkele Linux distro die out of the box sneller dan OpenBSD installed! Gentoo zuigt omdat alles gecompiled moet worden, Debian zuigt omdat het of outdated is en apt gewoonweg flawed is.
Redslet is commerciel (al is Fedora wel redelijk kicking-ass) en SuSE... tja... yast... do i need to say more?
Solaris of OpenBSD op de server, MacOSX op de desktop = enlightment

Maar dat is mijn mening

zolang ik maar een zwartscherm heb met grijze letters en een root@ prompt vind ik t best

Console zuigt ook, Gnome aan de m8!

grafische meuk zuigt

nou ik heb em allang binnen ben mar mijn eigen besturing ant programeren

Ik heb ook lang openbsd gedraaid, maar ik ben er eigelijk niet meer zo'n fan van nu.

En like, iedere keer is er weer iets waardoor openbsd noooit meer te ownen is, vage patches die je zogenaamd moeten beschermen, en dan komt er weer een of andere kernel vuln. en dan blijkt dat al je puike systrace policies helemaal geen zin hebben

Er zijn geruchten van veel kernel bugs, en ook van kmalloc() bugs, dus dan helpt de propolice patch waarmee de kernel gecompiled is ook niet meer. (beschermt alleen tegen stack overflows, niet tegen heap)

Komt nog eens bij dat theo een enorme lul is
Die claim van '1 remote hole' klopt voor geen kant: sshd heeft zoiezo die deattack bug gehad en die challenge-response bug. Ook zat er een fmt string bug in talkd, die standaard ook aanstond.
Beetje valse informatie.

Ook grappig:
"As theo announced on misc@, non-executable stack support is available in the most
recent snapshots for most platforms. In other words, say goodbye to the vast majority
of buffer overflow attacks against OpenBSD machines "

Ik ondekte dat je gewoon in mprotect() kon returnen in libc, en gewoon de stack weer terug executable kon zetten. Super lomp

Ihmo is een linux bak met een PaX patch veiliger dan een openbsd bak

juh ceno, itchie heeft me gehersenspoeld

Zozo, zo komt t gesprek op OpenBSD vs. Linux terecht

Maar goed, ik hoor hier geen commentaar over FreeBSD... Wat is de mening daarover? De uptimes op netcraft geven me iig wel redelijk wat vertrouwen dat het zeker stabiel is. Tuurlijk zijn er wel wat exploits voor, maar voor welk OS niet?

Iig, heb Solaris hier ook nog in de kast liggen, wie weet een keer proberen.

PS: ports collecties heeft mn hart!

Het is jammer dat er voor freebsd geen PaX-achtige kernel patches zijn.

Of heb ik wat gemist?

ach, ieder jaar een nieuwe windows
Dus boeie.

En BSD is het veiligste OS wat er is
Iedereen gebruikt zowat windows omdat daar verweg de meeste commerciele software op draait.
Best wel jammer.
Terwijl een Desktopje in Linux er standaard al veel cooler uitziet.



Ik ben dik tevreden met Debian hoor
'apt'-get is gewoon een geweldige tool!
Eindelijk eens niet veel gekut als je iets wil installeren.

veiligste os ligt imho nogal aan de admin

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