https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7638
--- Comment #5 from Guy Harris <guy@xxxxxxxxxxxx> 2012-08-15 14:10:22 PDT ---
(In reply to comment #4)
> The GIOP protocol supports both big and little endian values depending on the
> version (in the header of the message), which can affect the "message size".
> Should there be a "sanity check" based on the version of the message and just
> set some expert info? Should the "sanity check" cause the heuristic to fail?
> Should the dissector attempt to use the oppose endianness to see if the number
> is "more valid"?
I'd say that it should check for a (somewhat-arbitrary) "too big" size and, if
it fails, just set some expert info. The heuristic for GIOP is probably pretty
strong, as it's based on an explicit magic number, so I'd be inclined to treat
a packet with "GIOP" in the right location and a bogus length as a
probably-mangled GIOP packet rather than as "not a GIOP packet", whether it's
the length field or the byte-order field that's mangled; the check for the
opposite endianness should, if done, be just used to suggest which of the
fields is more likely to have been mangled.
> And what should the "magic number" be for that "size sanity check"?
Not sure. A megabyte?
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.