> 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 (dot) com [email concealed] :) )
> 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 (dot) com [email concealed] :) )
Oh, that's not nice.
/mz
http://lcamtuf.coredump.cx/silence/
[ reply ]