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
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Mar 2010 09:34:17 -0800
From: Kaddeh <kaddeh@...il.com>
To: information security <informationhacker08@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Mozilla Firefox 3.6 plenitude String
	Crash(0day) Exploit

I wouldn't call this a bug in the least bit.
I would call it a lack of hardware issue than anything, similar to "minimal
requirements" on software, etc.
This issue only happens on 32-bit with the configuration that you yourself
are running, there is no issue with Firefox itself, mainly because it has
been confirmed multiple times to work on multiple machines (myself
included).
I chalk this one up to single-user issue and move on.

Cheers

Kad

On Tue, Mar 9, 2010 at 9:03 AM, information security <
informationhacker08@...il.com> wrote:

>  The testcase crashes in Mozilla because
> The reason for this is that  the  are stack exhaustion crashes and are not
> exploitable. Stack exhaustion occurs when there is no more room on the
> program stack to push any more data. This is not a stack-based buffer
> overflow. but it is definitely a bug
>
> Asheesh
>
>
> <http://blogs.technet.com/srd/archive/2009/01/28/stack-overflow-stack-exhaustion-not-the-same-as-stack-buffer-overflow.aspx>
>
> On Mon, Mar 8, 2010 at 7:16 AM, Rohit Patnaik <quanticle@...il.com> wrote:
>
>> You checked this code on a 64-bit computer?  I just tested it on Ubuntu
>> 9.10 amd-64 edition (running from a LiveCD, no less).  The result was the
>> same as the one described above - Firefox chugged for a few seconds and then
>> displayed a very wide web page.
>>
>> -- Rohit Patnaik
>>
>> On Thu, Mar 4, 2010 at 4:15 AM, information security <
>> informationhacker08@...il.com> wrote:
>>
>>> i had check this code  in 64 bit computer  it works
>>> but why this code only work for Mozilla  browser not in Internet Explorer
>>> and
>>> also thanks Jeff  for all your comment :)
>>> In India a famous Poet kabir says "keep your critic next to you he is
>>> your  best friend!"  :)
>>>
>>> Asheesh kumar Mani Tripathi
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Mar 3, 2010 at 4:19 PM, Jeff Williams <jeffwillis30@...il.com>wrote:
>>>
>>>> Sure;
>>>>
>>>> Mozilla by default recover any "lost" tabs by itself, then no worry for
>>>> your "users" considerations.
>>>>
>>>> Now sparky, who will be stupid enough to launch a botnet that sets a web
>>>> page containing a document.write "A" * 2000000000000000000 on them
>>>> compromised hosts ?
>>>>
>>>> You tell me.
>>>>
>>>>
>>>>
>>>> 2010/3/3 information security <informationhacker08@...il.com>
>>>>
>>>>> Thanks Valdis .Jeff for all your comment
>>>>> yes my small-penis machine running out of RAM and swap space ...:
>>>>> ...... :)and i believe that Mozilla get crash ...........:(
>>>>> can you tell me how to fix that people don't become victim from this
>>>>> attack  people with having 34 bit Computer
>>>>> or people having small -penis machine change into big-penis machine :)
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 3, 2010 at 12:37 AM, <Valdis.Kletnieks@...edu> wrote:
>>>>>
>>>>>> On Tue, 02 Mar 2010 20:02:37 PST, information security said:
>>>>>>
>>>>>> > open in Mozilla Firefox and wait for 15 sec ...... :) and say Good
>>>>>> Bye
>>>>>>
>>>>>> Sorry, your exploit doesn't do squat on a 64-bit Firefox 3.7a3 with
>>>>>> plenty of
>>>>>> RAM. It chugs for about 7-8 seconds and displays a *very* wide page.
>>>>>>  It must
>>>>>> be your small-penis machine running out of RAM and swap space. :)
>>>>>>
>>>>>> Hint - this issue was well understood back in 1964. Literally. IBM's
>>>>>> OS/360 had
>>>>>> a GETMAIN macro that allocated storage that could encounter this same
>>>>>> basic
>>>>>> "out of memory" issue.  So not only is this a non-bug that was known
>>>>>> when you
>>>>>> were still being toilet-trained, this may be the first recorded case
>>>>>> of
>>>>>> somebody reporting a non-bug that was known when their *parents* were
>>>>>> still
>>>>>> being toilet-trained.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/
>

Content of type "text/html" skipped

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ