Hobbyisten patchen Windows 98 en Me

Origineel bericht van iemand 18/01/2006
Als dit klopt vind ik het raar dat er NU pas sites zijn die van dit lek misbruik maken

Origineel bericht van Dino 18/01/2006
Als dit klopt zullen er nog wel zo oude problemen opduiken!

Origineel bericht van Olaf 18/01/2006
Buffer overflows zijn een van de moeilijkste dingen om te ontdekken, zelfs als je met je neus op staat te kijken in de source code zie je het soms niet. En het is pas de laatste paar jaar dat programmeurs weten dat buffer overflows problemen kunnen creeren, de redenering tot nu toe als programmeur was, "je moet dat maar niet doen" Of een ander typisch gezegde is: Als je er vuiligheid in steekt, dan krijg je vuiligheid uit. Anders gezegd: dat is mijn probleem niet.

De enigste manier om een bufferoverflow deftig op te lossen is door de compilers intelligenter maken en waarschuwingen geven dat er een potentiele bufferoverflow kan bestaan. Microsoft heeft bvb voor string bewerkingen een reeks nieuwe functies in de C code voorzien. Ik ken maar weinig Belgische programeurs die zelfs weten wat een buffer overflow is.

Een ander zwak punt zit hem in de calling conventie van de dll's.
Er word bvb niet getest als een functie die 5 parameters krijgt er plost een 6e teveel heeft. In vele gevallen kan die exra parameter een terugkeeradres bevatten om naar toe te springen als de functie gedaan is. Vooral als de C calling conventie gebruikt word, de pascal calling conventie of standard calling conventie is daar minder gevoelig in, omdat de functie zelf zijn eigen stack opkuist in palats van diegene die hem oproept. Maar je verliest dan variabel aantal parameter fucties.

Er zijn alijd trade-offs, pascal calling conventie is safer maar trager can de c-versie.

Nu

Origineel bericht van Olaf 18/01/2006
Nu ik stel voor dat iedereen die moord en brand schreeuw voor zoiets, dat hij een keer C, C++ of Delphi aanschaft en zelf eens probeert een dom programmake in elkaar te steken. En dat programma aan 100 ander mensen geeft. Dan pas zal je ontdekken dat het niet zo eenvoudig is om een echt veilig programma in elkaar te steken.

Wel stel nu voor dat je een bmp file inleest en op het scherm toont als programma. Wel neem dan gelijk welke executable file, rename die extensie exe naar bmp en laat dat programma die zogenaamde bmp die eigenlijk een exe is open doen, wedden dat die crasht? Wedden dat als ik een trojan in die corrupte file zou steken dat die code nog uitgevoerd word ook? Je zal zien dat je 90% van je tijd in 10% van de code zal steken om toch maar veilig te maken.

Origineel bericht van christophe 18/01/2006
Ik steun volledig het bericht van Olaf,
behalve voor deze opmerkingen:
- het probleem van de buffer overflows is reeds lang gekend. Reeds in 1988 gebruikte de Morris worm een buffer overflow, in 1995 werd het fenomeen terug ontdekt en begon de bewustording van het gevaar ervan. Het is inderdaad waar dat ze zeer moeilijk te vinden zijn. Format-string-vulnerabilities daarentegen zijn pas recent ontdekt en zijn gemakklijk te detecteren, maar zeer gevaarlijk.
- Er bestaan ook systemen in C je code beschermen tegen buffer overflows, met natuurlijk een klein performatieverlies.

Origineel bericht van compfreak986 18/01/2006
Het is niet alleen in progrmmas dat bufferoverflows kunnen optreden.
Het kan ook in de hardware.
Een goed voorbeeld hiervan zijn de dure cisco-routers.
Deze worden vaak gebruikt bij ISP's maar zijn zelfs met telnet te kraken door een simpele buffer-overflow.

En zoals hiervoor al is gezegd, Je kan geen software of scripts maken zonder lekken.

Origineel bericht van compfreak986 18/01/2006
En laat me raden, jij bent een Linux gebruiker?
Je moet eens nadenken Windows domineert nog altijd de markt van de Operating Systems, dus zijn er meer mensen die het gebruiken en waarschijnlijk zijn er ook veel meer al dan niet kwaadwillende personen die lekken zoeken in Windows.

-->Er worden dus ook meer lekken gevonden.

Kijk naar IE en FF.
Hoe meer mensen FF gaan gebruiken, hoe meer lekken men vind.

Origineel bericht van Dino 18/01/2006
.."k ken maar weinig Belgische programeurs die zelfs weten wat een buffer overflow is."
Excuseer mijn taalgebruik: WTF!!!????

Origineel bericht van kiji 19/01/2006
hoeveel gebruikers vinden en rapporteren lekken?
een paar honderd man die toevallig ook net in de computerindustrie zitten. Er zijn natuurlijk meer mensen bezig met het onder de loep nemen van windows-code en ja dat zal ook wel tot meer ontdekkingen leiden, maar toch blijft het probleem dat MS een serieus probleem heeft in hun security en quality control. Net omdat MS zo'n monopolie heeft zouden wel wat harder mogen werken.
Gebruik gerust de vergelijking FF/IE; bij IE zitten een paar honderd goedbetaalde programmeurs al sinds '95 dag-en-nacht op de IE code te staren en nog kunnen ze niks beter brengen. Terwijl ze bij mozilla met een honderdtal vrijwilligers in hun vrije tijd toch zowat de beste browser (op gebied van XHTML/CSS standaarden en, daar valt weer over te twisten, veiligheid en gebruiksvriendelijkheid).
Ze weten bij MS al jaren van het wmf-lek, maar blijkbaar was het niet nodig er iets aan te doen. Misschien geen idee hoe het op te lossen? Terwijl 1 "keuterboerke" in een dag een patch op tafel kan leggen. Hoe je het draait of keert, MS is incompetent. Ondanks de duizenden programmeurs glippen er nog zoveel lekkern en bugs in de releases (tot daar aan toe, met de miljoenen lijnen code, kan dat wel gebeuren) maar het zijn er nog altijd relatief veel en weten van een lek en het niet patchen? Doet me denken aan een logge communistische bureaucratie die ondanks alle ideologie niks geeft om de mens in het systeem.

Origineel bericht van Naam 19/01/2006

Foutieve redenering.

Apache 80%, IIS 20%.

Lekken worden veroorzaakt door kwaliteitsgebreken, niet door aantal gebruikers.

Origineel bericht van Guy 19/01/2006
Beste allemaal,

De laatste posts zijn hier de reinste onzin !!!

1) Buffer overflows zijn wel goed gekend, zelfs door Belgen!
2) Buffer overflows zijn HEEL GEMAKKELIJK te ontdekken!
3) Buffer overflows hebben niets te maken met complilers!
4) Uw programma code beschermen tegen buffer overflows kan wel! (maar dus niet door één een andere of betere compiler te gebruiken, maar door slimmer te programmeren.
5) Buffer overflows kunnen in elk apparaat voorkomen waar een µc in zit.
6) Een buffer overflow hoeft niet noodzakelijk te leiden tot een security exploit.
7) Sommige bedrijven claimen dat ze een buffer overflow vrije programmeertaal hebben wat totale onzin is!
8) Buffer overflows zijn wel de grootste kopzorgen voor zowel IBM, Intel, MicroSoft, Apple, HP, Cisco, enz...
8) De nieuwste µc's van Intel met ExecFlag voor het intern geheugen is een stap in de goede richting.

Het probleem met buffer overflows voor een gewonen programmeur is dat je een ASM programmeur moet zijn. En daar vele onder jullie enkel hogere programmeertalen kennen zoals C of Delphi of VB enz... is de kunst van ASM programmeren verloren aan het gaan. En het zijn juist de ASM programmeurs die de regels van compilers kunnen overrulen en die inzicht hebben in de echte(!) code achter de code (lees hogere programmeer taal)

Een duidelijk voorbeeld van de onkunde van programmeurs is te lezen is de laatste posts met bijhorende stellingen. Ook al zijn ze goed bedoeld.

Met vriendelijke groeten,
Guy
ASM prgrammeur.

Origineel bericht van Olaf 19/01/2006
compfreak986, het is wel toevallig de software in die hardware die de buffer overflow veroorzaakt.

Ondertussen zijn de programmeertalen volwassener geworden, en beginnen ze extra functies te implementeren die alhoewel iets trager zijn dan de ouder versie, een stuk veiliger zijn.

Een voorbeeld is de nieuwe StringCchCat() als vervanger voor strcat() en zo...

In mijn ogen kan een OS enkel veiliger worden door al zijn programma's en services te draaien in een soort van sandbox. Tot nu toe waren de machines te traag om dat te doen, maar ondertussen bestaat er meer en meer virtualizatie software die dat kan beginnen te doen. .NET en Mono en de toekomstige WinFX is al een stap in de goede richting. Maar er is nog heel veel werk aan om dat allemaal in goede banen te leiden en bruikbaar te maken.

Origineel bericht van Olaf 19/01/2006
Dino mag ik veronderstellen dat jij een van de programeurs bent die niet weet wat een buffer overflow is? En waarom dat een gevaar is? Aan je reactie te zien toch.

En moest je het wel weten, leg het dan eens uit.

Origineel bericht van Olaf 19/01/2006
Awel Kiji, ga bij Microsoft werken en alles zal perfect in orde komen.
Maar ik heb niet het gevoel dat je veel programmeert Kiji, anders zou je wel anders redeneren.

En nee, het IE team zit niet elke dag achter IE, ze doen ook nog ander zakens.
Bvb de Vista team werd ingeschakeld om XP SP 2 mee te helpen verbeteren, dat is al een van de redenen waarom Vista vertraagd is.

En geloof me, een keuterboerke is niet in staat om in 1 dag een patch te maken, je moet al wat van reverse engineering kennen en assembler code kunnen lezen. En ik ken er niet veel die dat kunnen.

Origineel bericht van schwungman 19/01/2006
Allemaal akkoord, er heeft in mijn ogen ook niemand moord en brand geschreeuwd. Een beleefde thread, houden zo

Nu, van 1990 tot nu, da's bena 16 JAAR eh mannen. Die kerel zegt toch duidelijk dat toen het gevaar gekend was en dat verbaast me.

Te moeilijk? Toegegeven, goede programmeurs zijn zeldzaam en C/C++ is soms heel moeilijk om goed te krijgen, maar als je een OS schrijft moet je toch nog wat andere uitdagingen overwinnen zou ik denken... Het verbaast me gewoon dat Microsoft dit zelf zo ver heeft laten komen, als je dan weet dat zelfs Vista hier nog vatbaar aan was. Eens de druk er was, is de patch toch gekomen dus onmogelijk zal het zeker niet geweest zijn.

Origineel bericht van Onbekend 19/01/2006
lool meneer is weer eens de specialist omdat hij weet wat een buffer-overflow is? Olaf mijn beste, van welke planeet kom jij? LOL

Origineel bericht van Olaf 19/01/2006
Gemakkelijk te herkennen? Vergeet het maar, soms wel, maar soms zitten ze heel diep en is het niet meteen duidelijk, zelfs niet als je de source code ziet. De therm buffer overflow is algemeen bekend, maar heel weinig mensen weten wat het echt is, en nog minder mensen houden er ook nog rekening mee.

Een bufferoverflow misbruiken is niet altijd gemakkelijk, het is veel trial and error vrees ik.

Tjiens een assembler programmeur. Ik dacht dat ik nog de enigste was.

Origineel bericht van Olaf 19/01/2006
Guy de enigste mensen die ik ken die nog assembler programmeren zijn die mensen die embedded systemen programmeren. Op de PC komen die niet zoveel meer voor. De assembler zit geintegreerd in de C compiler nu, niet meer als stand-alone.

Origineel bericht van schwungman 19/01/2006
Wat betreft die patch van het keuterboerke: akkoord die man is heel bekwaam, zeker geen boerke.

Anderzijds was zijn patch geen "echte" patch in die zin dat hij de functie die kwetsbaar was gewoon uitschakelde, en dat is een goede workaround maar geen "echte" functionele patch. Waarmee ik dus niet wil zeggen dat het niet heel nuttig is geweest, MS had dit m.i. beter ook gedaan ipv. te zeggen "kijk uit terwijl je surft want er kunnen prentjes op de pagina staan".

Origineel bericht van Firmin Bachte de Kuppe 21/01/2006
Awel awel, da zen ier allemoa ooraakels zeker? Wa en gelierde toal da ze hier spreke, dikkenekken geziever. Wa is gevoar on nen buffel? Wa is ne valse patj? En ik lees ier oek weer veul geziever over maaicrosoft. Pressies of die nie weite mee wa ze bezig zen. Pressies of Mozarella beiter is. Haaft es op mee diene ziever hie, en haaft es op mee keuterboerekes deur 't slijk te hale. Nertjes. Go spele of assemblere mee elle eige roemmel. Of zukt een stammenee woe ge onder ulle kan zievere.