On Monday, June 30, 2003, at 12:48PM, Nathan Way wrote:
what seems to be happening is Ethereal is interpreting the /CN field
as a length value, tries to allocate gigabytes worth of memory then
faults because it can’t allocate that much RAM.
At least in recent versions of Ethereal, that shouldn't be happening -
the DCE RPC routines to extract counted strings and the like should
first check whether the entire string, with the purported length
specified, is available in the packet data, before doing any
allocation, so it should throw an exception and show a "Malformed
Packet" indication.
Also, the fault you should get when it can't allocate memory shouldn't
be a segmentation fault, as it uses "g_malloc()" and should thus call
"abort()" and get a SIGABRT signal, not a SIGSEGV.
Hex dump of packet:
Unfortunately, even after modifying that hex dump so that text2pcap can
turn it into a capture file, it's only one packet in the middle of a
MAPI sequence, so the DCE RPC dissector can't recognize it as a MAPI
packet (no binding is in the capture) and, even if we were able to
force that, it couldn't recognize it as a login reply (as the request
isn't in the capture).
If you could send us a raw binary capture file (not a printed dump)
with enough packets for Ethereal to try to see it as a MAPI login reply
(it'd need the bind and bind ack, as well as the matching request, at a
minimum), that'd help.
Other than disabling the MAPI decoder, is there a patch or anything to
fix this problem?
As we don't know what's causing it, no, we don't have a patch to fix
it. Getting the capture referred to above might make the difference
between being able to fix it in a timely fashion and not being able to
fix it in a timely fashion.
