Bug in Sigcomp decoding, STATE-ACCESS instruction

This issue was migrated from bug 1920 in our old bug tracker.

Original bug information:

Reporter: Ruben Garcia
Status: RESOLVED NOTABUG
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: x86
Version: 0.99.5

Ruben Garcia said:

Build Information: Version 0.99.5 (SVN Rev 20677)

Copyright 1998-2007 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.10.7, with GLib 2.12.7, with WinPcap (version unknown), with libz 1.2.3, with libpcre 6.4, with Net-SNMP 5.4, with ADNS, with Lua 5.1, with GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio PortAudio V19-devel, with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 3.1 (packet.dll version 3, 1, 0, 27), based on libpcap version 0.9[.x], without AirPcap.

Built using Microsoft Visual C++ 6.0 build 8804

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

According to RFC 3320 section 9.4.5, if a value of zero is received as state_length argument on STATE-ACCESS instruction, the actual length is to be obtained from the state specification.

Instead, when Wireshark tries to decode a message containing a Bytecode using state-access with a 0 state_length (to access the whole static SIP dictionary), zero bytes are copied from the state and so, message decoding fails.

added uigtk version0.x labels

Anders Broman said:

Could you provide a trace illustrating this so a bug fix can be verified.

Ruben Garcia said:

(In reply to comment #1)  
> Could you provide a trace illustrating this so a bug fix can be verified.  
>  

Hi,

Thanks for looking at the issue.

Unfortunately, the capture files that I have contain private subscribers data as well as our propietary implementation of the bytecode. I've reached the conclusion that the state_length "0" didn't work, because with the instruction:

STATE-ACCESS (rfc3485_id, 6, 0, 0, rfc3485_state, 0)

to access the SIP static dictionary, header words were not correctly decoded ("0" padding appeared at the decoded message instead), although understood by the TE's implementation of the UDVM. However, when I changed the instruction (and this was the only change) to

STATE-ACCESS (rfc3485_id, 6, 0, 4836, rfc3485_state, 0)

(4836 is the length of the state), Wireshark decodes the message without problems.

If you have a fix and want to send it to me, I can do the verification with the capture files and tell you if I find any problem with it.

Thanks again for looking at the issue.

Anders Broman said:

Hi,
I'm affraid that if you can't send the trace you'll need to do some
debugging yourself.
This code in sigcomp_state_hdlr.c *should* handle length = 0
	/*
	 * The value of
	 * state_length MUST be taken from the returned item of state in the
	 * case that the state_length operand is set to 0.
	 *
	 * The same is true of state_address, state_instruction.
	 */
	if ( *state_length == 0 ){
		*state_length = state_buff[0] << 8;
		*state_length = *state_length | state_buff[1];
	}
	if ( *state_address == 0 ){
		*state_address = state_buff[2] << 8;
		*state_address = *state_address | state_buff[3];
	}
	if ( *state_instruction == 0 ){
		*state_instruction = state_buff[4] << 8;
		*state_instruction = *state_instruction | state_buff[5];
	}

Jaap Keuter said:

Ruben, have you looked into the part Anders suggested? Did you rerun your test with the latest release 0.99.7?

Anders Broman said:

Closing due to lack of response, and no other BUG reports received on the same problem.

closed