Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Vulnerability Development: Re: Advice On FireFox Bug

Re: Advice On FireFox Bug

From: Michal Zalewski <lcamtuf_at_dione.ids.pl>
Date: Mon, 1 Aug 2005 19:59:42 +0200 (CEST)

On Sat, 30 Jul 2005, John Cobb wrote:

> After a bit of playing I found a bug with the latest version of FireFox
> which seems to work on Win2K & WinXP /.../ but since im not a
> coder/reverse enigneerer it's a bit difficult to understand what's
> causing the problem.

John,

If you manually created a malicious input file, you should be well aware
what causes the crash; I take it you took an approach more similar to my
'mangleme' experiment (see BUGTRAQ archives) - if so, you'd have a file
with plenty of broken HTML tags, and would be tasked with finding which
one, exactly, causes the problem.

You're probably looking the wrong way - many problems occur after initial
parsing and splitting of tags, and so, a step-by-step HTML parser
debugging is probably not going to help a whole lot.

Chances are the problem is caused by a single tag. The easiest way to find
it is to split the file in two parts - and see which one, if any, crashes
the browser. If you get a crash, continue this procedure - in just a
couple of steps, you should go down to a file that can be easily examined
manually.

If, at some point, you end up with two halves, neither of them causing a
crash, try uneven ratios, or remove a portion from the middle of the file,
leaving a block at the beginning and near the end intact. Also pay
attention to the balance of '>' and '"'.

Also, don't be afraid to read the debugger output on crash, even if you do
not know the product and are not too comfortable with assembly - crash
location, along with stack backtrace and register contents, should give
you some hints as to where the crash occured, and what data ended up where
it does not belong.

> (This bug is 0day. If you work for a nice rich security company and want
> to purchase this of me, email me: johnc_at_nobytes.com :) )

Oh, that's not nice.

/mz
http://lcamtuf.coredump.cx/silence/
Received on Aug 02 2005

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos