If you take a look to the attachment
http://bugs.wireshark.org/bugzilla/attachment.cgi?id=605
of bug http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1342
You'll have a perfect example of an "evil" packet (not malicious but
certainly evil) that causes 4(3?) bugs to be triggered.
This malformed packet causes a recursion loop in AccessResult via
dissect_ber_choice() because the choice's data is a sequence of 00s.
Other than the bug in the code that generated the packet (which is not
our business). We got one or two bugs here:
- dissect_ber_choice() must stop looping without advancing.
- and MMS's AccessResult/success1 might be IMPLICIT (I tried to make
it implicit and it stopped the loop marking these packets as
malformed).
That causes a stack overflow which hides more bugs:
One of the bugs I just fixed it, where a windows exception thrown up
in the stack will skip all the ENDTRY groups causing a crash later in
except_pop() when called by the ENDTRY of dissect_packet()
Once fixed the file is read ok with tshark (even with -V but there you
can see the effect of the loop). On WS (on Windows), on the other
hand, the packet list is made OK but if you click on the "evil" packet
(21) WS just shuts down (no dump to the debugger, no signs of why!). I
believe this to be a out of memory error when generating the tree
after dissection but honestly I do not know how to deal with this.
I'll investigate the last issue (the shut down) but someone that knows
how dissect_ber_choice() works should take a look at it.
Luis
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
