Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] pcapng, must opt_comment string be 0-terminated?

From: Martin Kaiser <lists@xxxxxxxxx>
Date: Tue, 3 Jan 2012 22:30:29 +0100
Thus wrote Michael Tuexen (Michael.Tuexen@xxxxxxxxxxxxxxxxx):

> On Jan 2, 2012, at 3:53 AM, Guy Harris wrote:

> > The Wireshark code to read pcap-NG files uses g_strndup() to make
> > copies of the various "UTF-8 string[s]", so the strings in the file
> > don't have to be null-terminated, and I would read the *lack* of any
> > mention of null-termination in the spec as an indication that

> I think g_strndup() is for being secure. Even if the spec requires the
> string to be 0 terminated, you never know if the file you read
> conforms to the spec. Since the option has a length field, using
> g_strndup() is the way to go.

I'm asking because there might be an issue with the current
implementation.

In pcapng_read_packet_block(), we have char option_content[100]; and
call
pcapng_read_option(..., &oh, option_content, sizeof(option_content), ...)
for each option that we find.

This function reads the option length, stores it in oh.option_length and
reads oh.option_length bytes from the file into option_content.

Then we do
   wblock->data.packet.opt_comment = g_strndup(option_content, sizeof(option_content));

where sizeof(option_content) is 100. If the option string is not
0-terminated, we end up copying the string + random bytes from the
option_content buffer until there's a 0 or we reached 100.

It's not that critial we but know the correct length and could do

opt_comment = g_strndup(option_content, oh.option_length)

instead.

If you agree, I can open a bugzilla item with a patch and sample capture
that has an unterminated comment.

Best regards,

   Martin