Nieuws
image

Scriptje van 4 regels laat meeste browsers crashen

dinsdag 30 november 2004, 13:37 door Redactie, 36 reacties

De Nederlander Berend-Jan Wever heeft een lek in verschillende browsers ontdekt en gepubliceerd. Met vier regels javascript-code is het mogelijk om Internet Explorer, Mozilla Browser, Mozilla Firefox, Opera en Apple Safari te laten vastlopen. Het script maakt gebruik van het zogeheten Infinite Array Sort denial of service-lek. Wever heeft het lek gemeld op zijn website en op de publieke mailinglijsten Bugtraq en Full Disclosure. Tot nu is er geen oplossing of update voor het probleem, zo laat Weblog goedZO?! ons weten. Hieronder het script in kwestie:

HTML
SCRIPT a = new Array(); while (1) { (a = new Array(a)).sort(); } /SCRIPT
SCRIPT a = new Array(); while (1) { (a = new Array(a)).sort(); } /SCRIPT
/HTML

Met dan aank Julien Moorrees voor het melden van dit nieuws

Reacties (36)
30-11-2004, 14:31 door Anoniem
Dit is geen noemenswaardig nieuws! Het is sowieso geen lek;
hooguit een bug en de browser moet ERGENS vanuit gaan bij
het uitvoeren van de code: het GIGO principe komt hier op:
garbage in, garbage out!

Oké: het zou netter zijn als browser dit zou afvangen, maar
op deze manier kan je alles laten crashen.

<moderator>naam verwijderd</moderator>
30-11-2004, 14:31 door Preddie
Dit script was al bekend bij mij .... dus ik weet niet of
die wel zo nieuw is :S
30-11-2004, 14:40 door Anoniem
mooie geheugen'worm'. Dat zal wel crashen ja. Krijg je als
je bullshit als echt-lijkende talen in je browsers gaat
zitten stoppen.
30-11-2004, 14:43 door Anoniem
Nou is het de vraag, is dit een probleem van de browser of
is dit gewoon slecht gecode door de webdeveloper?

Ik kan ook wel een programma ontwikkelen die een OS laat
vast lopen, maar of dat ook gelijk een bug is in dat OS, zou
ik niet weten..
30-11-2004, 14:44 door Anoniem
Tja... standaard resource starvation... net zoiets als
while (true) { fork() }
30-11-2004, 14:44 door Anoniem
Of deze:

<body onload="javascript:window();">
30-11-2004, 15:05 door Anoniem
Mag ij me even bij <moderator>naam verwijderd</moderator> aansluiten.

Berend Jan Wever is een publiciteitsgeile black hat. Hij publiceert voortijdig
buffer overflow PoC's met obfuscatie, waarop dat prompt door
virusschrijvers en trojanschrijvers wordt gebruikt. Ja, dan ben je goed
bezig.
30-11-2004, 15:12 door Anoniem
Door Anoniem
Nou is het de vraag, is dit een probleem van de browser of
is dit gewoon slecht gecode door de webdeveloper?

Ik kan ook wel een programma ontwikkelen die een OS laat
vast lopen, maar of dat ook gelijk een bug is in dat OS, zou
ik niet weten..

ja. als jij een heel OS kapot krijgt met 1 userspace
programma, dan ligt dat aan het os.

je zou in de browser misschien een geheugenmetertje kunnen
laten lopen die stopt met executen als het te groot wordt,
moet te doen zijn in een interpreter lijkt me zo
30-11-2004, 15:20 door rob
Mjah, ik vind die berend-jan maar een vervelend ventje als
je z'n posts ziet op de full disclosure mailinglist
30-11-2004, 15:44 door SirDice
Door Anoniem
Tja... standaard resource starvation... net zoiets als
while (true) { fork() }
Inderdaad. Gewoon een forkbom in een ander jasje.
30-11-2004, 15:46 door SirDice
Door Anoniem
je zou in de browser misschien een geheugenmetertje kunnen
laten lopen die stopt met executen als het te groot wordt,
moet te doen zijn in een interpreter lijkt me zo
Een beetje *nix systeem heeft dit al. Je kan limits (login class) instellen waar een gebruiker (of programma) niet overheen kan. Zo kan een dergelijk programma nooit je hele systeem onderuit trekken.
30-11-2004, 15:48 door Anoniem
je zou in de browser misschien een geheugenmetertje
kunnen
laten lopen die stopt met executen als het te groot wordt,
moet te doen zijn in een interpreter lijkt me zo
Inderdaad wel te implementeren -- alleen....... zijn er wel
weer situaties te verzinnen waar de ontwikkelaar een
soortgelijke actie *bewust* zou willen uitvoeren (niet deze
DoS situatie, maar een constructie met array sort's die er
ogenschijnlijk hetzelfde uitziet, maar door code op een
andere locatie wordt beinvloed en er dus geen DoS optreed).

Als dat echter gedaan wordt, breekt het bestaande
web-applicaties, en wordt de taal iets minder flexibel (stel
je bijvoorbeeld voor dat, vanwege de grote hoeveelheid
buffer overflow/underrun vulnerabilities, men binnen de
C-taal bijvoorbeeld je niet meer toegestaan bent om
bewerkingen op pointers uit te voeren... Het maakt het
veiliger, maar meteen minder bruikbaar.

De omschreven situatie is nu eenmaal van het type Garbage
In--Garbage Out zoals iemand al heel correct opgemerkt
heeft. Tijdens het ontwikkelen van Javascript-code kan er
nogal wat fout gaan en zijn dit soort situaties helemaal
niet uniek.

Er zijn voldoende van deze situaties te creeren, maar
gelukkig is er maar 1 browser (die we allemaal kennen en
vrezen) die daarmee in staat is het hele O.S. op zijn gat te
helpen....... en laat ik die nou *net niet* gebruiken.
30-11-2004, 16:22 door Anoniem
mmm jammer dat er in dit bericht wordt aangegeven om welke source het
gaat.
30-11-2004, 16:58 door Anoniem
Oud nieuws http://www.securityfocus.com/bid/11752/info

Een artikel overnemen is 1, kunnen tellen is 2, maar
verificatie van de bron, ho maar!

Scriptje van 1 regel laat meeste browsers crashen! Ik heb
nog nooit een browser zien crashen op de <HTML> tag!
30-11-2004, 17:37 door Anoniem
Door Anoniem
Tja... standaard resource starvation... net zoiets als
while (true) { fork() }


Je vergeet een malloc() erbij te zetten.

Gaat het sneller :-)

Weet iemand hoe je ulimits kan instellen in IEX ? :-)
30-11-2004, 17:40 door Donz
mmm jammer dat er in dit bericht wordt aangegeven om
welke source het gaat.
Nah, we gaan met z'n allen zitten speculeren over niets en
dan blijkt het 2 maanden later zo'n simpel iets te zijn. Dat
schiet op idd.

Het lijkt me overigens wel de bedoeling dat de browser dit
afvangt, veel scripting talen en software voorzien wel in
dergelijke beveiliging.
Denk dat de meeste mensen die wel eens software schrijven
zich al lang hebben afgevraagd of dit zou werken en velen
hier al van op de hoogte waren.
Vraag me voornamelijk af of ze hiermee iets gaan doen, of
dat het niet als bug opgepakt wordt.
30-11-2004, 17:46 door Anoniem
Door Anoniem
Scriptje van 1 regel laat meeste browsers crashen!

de HTML tag zijn inderdaad overbodig, waarom hij 2 maal die array creeert
mag joost weten... kennelijk zijn de mensen die hierover publiceren als
ook degene die het gevonden hebben niet in staat om kordaat te testen.

Als je alleen onderstaande lijn in een html bestandje propt zullen zowel
Firefox als ook IEX crashen...

<SCRIPT> a = new Array(); while (1) { (a = new Array(a)).sort(); } </SCRIPT>
30-11-2004, 18:58 door raboof
Achja, yet another DoS-probleem.

Overigens kunnen Konqueror en FireFox (en wie weet andere browsers, niet geprobeerd) sommige uit de hand gelopen scripts wel detecteren: probeer maar eens het script `while (1) { }'.

http://bzzt.net/~arnouten/loop.html
30-11-2004, 19:43 door Anoniem
Ik ben blij dat dit aan het licht is gekomen. Ik denk dat deze meneer
jarenlang hierop heeft nagedacht. Bravo. En wat heb je er aan: NIETS!
30-11-2004, 22:10 door Anoniem
Het opvreten van geheugen, tot en met het kunnen laten crashen
van een webbrowser, lijkt op zich geen ernstige vulnerability,
waarvan het bovendien niet voor de hand ligt dat deze massaal
toegepast gaat worden (net zo min als andere DoS attacks gericht
tegen particulieren).

Desalniettemin zijn situaties denkbaar waarin kwaadwillenden
dit uitbuiten: misschien laat de browser minder sporen achter
als men deze opzettelijk laat crashen nadat je, bijv. via een
gekraakte bannerserver, naar een foute page bent gestuurd.

Daarnaast is het m.i. zeer kortzichtig om dit soort fouten te
onderschatten, omdat het niet de eerste keer zou zijn als de
combinatie van enkele ogenschijnlijk "onschuldige" bugs tot
ernstige vulnerabilities blijkt te kunnen leiden. Zie bijv.
MS03-041, "There is a vulnerability in Authenticode that,
under certain low memory conditions, could allow an ActiveX
control to download and install without presenting the user
with an approval dialog."

Het is dus gewoon een bug die gefixed moet worden. Dit zijn
typisch van die fouten waar sommige software fabrikanten niets
aan doen, tenzij ze er openlijk (bijv. via full disclosure) op gewezen
worden dat de potentie van onvoorziene en ernstige complicaties
bestaat.
30-11-2004, 23:30 door [Account Verwijderd]
[Verwijderd]
01-12-2004, 02:56 door Anoniem
Berend Jan Wever is een publiciteitsgeile black hat.

publiciteitsgeil versus blackhat? HAHAHAHAHAH

En al die betogen over de bug. Who cares? Dat die mensen
geen nette VM kunnen schrijven die zoiets opvangt (zoals de
java vm netjes doet) is natuurlijk tekenent. Lekker belangrijk.
01-12-2004, 04:19 door Anoniem
Door Anoniem
Berend Jan Wever is een publiciteitsgeile black hat.
publiciteitsgeil versus blackhat? HAHAHAHAHAH

Je kan niet lezen (en schrijven gaat ook niet helemaal goet).
Maar dat geeft niet, je mag morgen weer naar school.
01-12-2004, 08:17 door Anoniem
Door Anoniem
Door Anoniem
Berend Jan Wever is een publiciteitsgeile black hat.
publiciteitsgeil versus blackhat? HAHAHAHAHAH

Je kan niet lezen (en schrijven gaat ook niet helemaal goet).
Maar dat geeft niet, je mag morgen weer naar school.
goeD

Veel plezier op school vandaag.
01-12-2004, 08:20 door Anoniem
Bovenstaande reacties zijn leuk en aardig en iedereen maakt wel een punt.

Maar heeft iemand zich weleens afgevraagd of het niet weleens wenseljk
kan zijn om nested loops te gebruiken in scripts die bepaalde hoeveelheid
resources alloceren ?

Het lijkt mij veel kwalijker dat een functie gerichte gebruik van een nested
loop onbedoelt tot crash kan leiden.
Zeker indien dit platform, browser, systeem afhankelijk kan zijn, immers
dan zou je voordat je een pagina kan laten zien eerst in detail moeten
vaststellen over welke resources de client beschikt zodat je dynamisch en
voor hem geschikte pagina's kan sturen..........
01-12-2004, 08:57 door Anoniem
fork bombs zijn al oud..
01-12-2004, 09:52 door Anoniem
Iedereen reageert weer lekker overdreven...

In vrijwel iedere programmeertaal zal een soortgelijke regel code
problemen geven. Normaal is dit ook geen probleem omdat deze situatie
niet zal voorkomen. Het concept dat een programmeertaal ook voor iets
anders gebruikt kan worden dan constructief een
programma /functionaliteit bouwen is een relatief nieuw concept
waar 'men' nog mee om moet leren gaan (niet alleen ms).
01-12-2004, 15:03 door Anoniem

Dat die mensen
geen nette VM kunnen schrijven die zoiets opvangt (zoals de
java vm netjes doet) is natuurlijk tekenent.

Ja gelukkig is Java met al z'n enterprise class code perfect
in orde.

Zoals al gezegd, dit soort acties zijn met elke taal
mogelijk, het feit dat Java dit toevallig tegenhoud is leuk
maar niet iets wat ik verwacht. Beveiliging tegen resource
starvation is iets wat op kernel nivo moet gebeuren en,
zoals ook al gemeld, op unix kan je iid fijn per account
instellen wat het max. aan resources is dat een bepaalde
user mag gebruiken, onder windows weet ik het niet maar dat
zal over een paar jaar ook wel geregeld worden gelet op de
huidige achterstand.
01-12-2004, 16:53 door Anoniem

publiciteitsgeil versus blackhat? HAHAHAHAHAH

Je kan niet lezen (en schrijven gaat ook niet helemaal goet).
Maar dat geeft niet, je mag morgen weer naar school.


Ik krijg het idee dat jij mij niet helemaal begrijpt. Een
blackhat is juist niet publiciteitsgeil maar het geeft niet
dat je dat niet helemaal begrijpt. Het security-wereldje is
ook nogal ingewikkeld, maar ik zal het even voor jullie
uitleggen:

"security.nl is een uithangbord voor bedrijven ala Pine om
hun eigen prutserige producten aan de man te brengen en
alleen maar meer angst te zaaien onder argeloze gebruikers."

WHITEHATS, STEP INTO MY OVEN!@#$@#%#$
01-12-2004, 20:16 door SpoT
heb het geprobeert en mijn browser (ex) loopt er wel nie door vast. Hoe
kan dat?
01-12-2004, 21:04 door Anoniem
Door Anoniem
"security.nl is een uithangbord voor bedrijven ala Pine om
hun eigen prutserige producten aan de man te brengen en
alleen maar meer angst te zaaien onder argeloze gebruikers."
WHITEHATS, STEP INTO MY OVEN!@#$@#%#$
Als je alleen de(zelfde) berichten wilt lezen zonder de
reacties, kijk op http://www.sif.nl :)
02-12-2004, 03:15 door Anoniem

Als je alleen de(zelfde) berichten wilt lezen zonder de
reacties, kijk op http://www.sif.nl :)

Lekker belangrijk. Dan heb je nog steeds die reclame troep
en loze artikelen. Twee voorbeeldjes van een tijdje terug.

De eerste dag wordt er gepost: "HACKERS MAKEN HET INTERNET
KAPOT"

En de volgende dag: "HACKERS NIET GEVAARLIJKER DAN WATERDAMP"

Waar hebben we het dan hier in godsnaam over?

Kortom: STEP INTO MY OVEN!!!
02-12-2004, 13:20 door Anoniem
Ik krijg het idee dat jij mij niet helemaal begrijpt. Een
blackhat is juist niet publiciteitsgeil maar het geeft niet
dat je dat niet helemaal begrijpt.
ROFL. - leuk om te zien dat hierover zo'n verschil in mening
kan bestaan. Het grappigste is dat degene die het hardst
schreeuwt het fout heeft.

Sorry, maar er zijn genoeg publiciteitsgeile blackhats (en
whitehats for that matter).

Waarom zetten ze al die namen en credits in hun exploits?
Publiciteit..

Waarom hacked iemand SCO en zet op een bannertje 'Hacked by
realloc( )' ? Publiciteit.

Waarom schrijft iemand stiekem 'n worm / virus dat
razendsnel verspreid? Publiciteit....

Blackhats zijn de foute jongens die het gebrek aan moraal
compenseren met dergelijke ego-trips. Whitehats assisteren
software-bedrijven nadat ze bugs hebben gevonden, op een
verantwoordelijke manier, en hun speelveldje ligt dus meer
op de achtergrond, en niet in de media zoals de meeste
blackhats.
02-12-2004, 16:48 door Anoniem

Waarom zetten ze al die namen en credits in hun exploits?
Publiciteit..

Waarom hacked iemand SCO en zet op een bannertje 'Hacked by
realloc( )' ? Publiciteit.

Waarom schrijft iemand stiekem 'n worm / virus dat
razendsnel verspreid? Publiciteit....

Een blackhat released geen exploits dus als ze na een tijdje
uitlekken staat inderdaad zijn naam er in. Het gaat dus NIET
om de publiciteit.

De SCO hack is wel degelijk een publiciteitsstunt maar ik
zag daar geen nick of naam van een hacker staan. Ze zijn
ZELF dus niets publiciteitsgeil wat dus een groot verschil
is met de gemiddelde whitehat.

Mayhem veroorzaken, daar gaat het sommige blackhats om. En
dat doen ze niet met naam en toenaam want dan hebben ze
problemen. Dus je kan het op mijn grote mond afschuiven maar
jij snapt het echt niet.

Nogmaals: STEP INTO MY OVEN!!!@#$
02-12-2004, 21:53 door Anoniem
Door SirDice
Door Anoniem
je zou in de browser misschien een geheugenmetertje kunnen
laten lopen die stopt met executen als het te groot wordt,
moet te doen zijn in een interpreter lijkt me zo
Een beetje *nix systeem heeft dit al. Je kan limits (login class) instellen waar
een gebruiker (of programma) niet overheen kan. Zo kan een dergelijk
programma nooit je hele systeem onderuit trekken.

Probeer hier maar eens 3 of 4 instances van te laten lopen:

#define SIZE 9000
long x[SIZE][SIZE];
long y[SIZE][SIZE];

static void stress()
{
register int i,j;
for(i=0; i < SIZE; i++)
for(j=0; j < SIZE; j++)
y[j] = x[j];

}

int main(int argc, char **argv)
{
register int i,j;
for(i=0; i < SIZE; i++)
for(j=0; j < SIZE; j++)
x[j]=j;

i = atoi(argc > 1 ? argv[1] : "100");
while(--i > 0)
stress();

return 0;
}


Laat maar even weten of je *nix systeem het leuk vond...

Stephan
03-12-2004, 09:26 door Anoniem
Dan zet je een rlimit op het maximaal te gebruiken geheugen en op een
maximaal aantal processen en je hebt nergens last van Stephan!
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search
Certified Secure