Wireshark · Wireshark-dev: Re: [Wireshark-dev] Finding the bug in the unistim dissector

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

Digging deeper into these extra display handling functions showed that 
the format string escape it tries to accomplish was incorrect(*). With 
that fixed it ran 10000 fuzz test runs overnight, without problems.

I've other activities to attend to, but I hope to get back finishing up 
after the weekend.

Thanx,
Jaap

(*) format string escape was done by means of inserting a slash in front 
of a percent. That lead to a test case with "s/%nguage" format string. 
That "%n" causes trouble. Changing the escape character to "%" solved this.

Jaap Keuter wrote:
> Hi,
>
> Yeah, that was my first idea as well. Finding the object that gets 
> altered isn't so easy though.
> Looking back at the code there are just your basic proto_tree_add_* 
> calls, but there are two extra display handling functions which look 
> oke, but may be the cause after all....
>
> Thanx,
> Jaap
>
> Luis EG Ontanon wrote:
> > Might be a buffer overflow overwriting it.
> >
> > - break after protocol registration.
> > - find the object that gets altered,
> > - set a watchpoint on that memory location
> > - continue until the watchpoint tells you who and where it gets overwritten.
> >
> > Luis
> >
> > On 8/15/07, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> > > Hi list,
> > >
> > > I've picked up the unistim dissector a while ago and try getting it into
> > > shape for checkin. Thing is that I'm currently running fuzztests which
> > > for the most run fine, but now I've isolated a packet that causes a
> > > segmentation fault. The problem is that I'm stuck looking for the cause.