Wireshark mailing list archives
Re: Hierarchy of fields & offsets again, more potential offenders
From: Pascal Quantin <pascal.quantin () gmail com>
Date: Wed, 2 Aug 2017 21:24:10 +0200
Hi Hassan, 2017-08-02 1:05 GMT+02:00 Sultan, Hassan via Wireshark-dev < wireshark-dev () wireshark org>:
Hi all, So I've started adding checks to my wrapper and am finding some interesting cases (they all look like issues that need to be fixed to me, but again, I might be missing something), would someone please take a look and tell me which you think are ok / bugs so I can start sending patches to fix them ? The below is the output from processing the file https://wiki.wireshark.org/SampleCaptures?action=AttachFile& do=get&target=smb3-aes-128-ccm.pcap Hopefully I'll soon enough grasp the intricacies and won't need the repeated validation from you guys. My plan longer term is to have this as an automated test to process capture files so that we can catch these issues at build time unless anyone has an objection. Thx, Hassan Reminder, format of the output is : <ftype> <offset> <name>(<length>): [children] FT_PROTOCOL 0 frame(172) : [...] FT_PROTOCOL 34 tcp(32) : FT_UINT16 34 tcp.srcport(2) : 38166 FT_UINT16 36 tcp.dstport(2) : 445 [...] FT_BYTES 66 tcp.payload(106) : VIOLATION 2 : Child tcp.payload has an end offset past the end of its parent VIOLATION 3 : Child tcp.payload has a length longer than its parent
This is done on purpose: we separate the tvb for the TCP header, and the tvb for the payload. tcp.payload field gives you the length of the payload and highlights it in the bytes view. Most probably not something we want to change.
FT_PROTOCOL 0 frame(318) : [...] FT_PROTOCOL 66 nbss(252) : FT_UINT8 66 nbss.type(1) : 0x00000000 FT_UINT24 67 nbss.length(3) : 248 FT_PROTOCOL 70 smb2(248) : FT_NONE 70 [SMB2 Header](64) : [...] FT_NONE 134 [Session Setup Response (0x01)](184) : [...] FT_BYTES 142 smb2.security_blob(176) : FT_PROTOCOL 142 ntlmssp(176) : FT_STRING 142 ntlmssp.identifier(8) : NTLMSSP FT_UINT32 150 ntlmssp.messagetype(4) : 0x00000002 FT_STRING 198 ntlmssp.challenge.target_name(8) : SUSE FT_UINT16 154 ntlmssp.string.length(2) : 8 VIOLATION 1 : Child ntlmssp.string.length has an offset lower than its parent FT_UINT16 156 ntlmssp.string.maxlen(2) : 8 VIOLATION 1 : Child ntlmssp.string.maxlen has an offset lower than its parent FT_UINT32 158 ntlmssp.string.offset(4) : 56 VIOLATION 1 : Child ntlmssp.string.offset has an offset lower than its parent FT_UINT32 162 ntlmssp.negotiateflags(4) : 0xe2890235 FT_BYTES 166 ntlmssp.ntlmserverchallenge(8) : 01:15:18:13:d2:89:8c:cd FT_BYTES 174 ntlmssp.reserved(8) : 00:00:00:00:00:00:00:00 FT_NONE 206 ntlmssp.challenge.target_info(112) : FT_UINT16 182 ntlmssp.challenge.target_info.length(2) : 112 VIOLATION 1 : Child ntlmssp.challenge.target_info.length has an offset lower than its parent FT_UINT16 184 ntlmssp.challenge.target_info.maxlen(2) : 112 VIOLATION 1 : Child ntlmssp.challenge.target_info.maxlen has an offset lower than its parent FT_UINT32 186 ntlmssp.challenge.target_info.offset(4) : 64 VIOLATION 1 : Child ntlmssp.challenge.target_info.offset has an offset lower than its parent [...] FT_PROTOCOL 0 frame(430) : [...] FT_PROTOCOL 66 nbss(364) : FT_UINT8 66 nbss.type(1) : 0x00000000 FT_UINT24 67 nbss.length(3) : 360 FT_PROTOCOL 70 smb2(360) : FT_NONE 70 [SMB2 Header](64) : [...] FT_NONE 134 [Session Setup Request (0x01)](296) : [...] FT_BYTES 158 smb2.security_blob(272) : FT_PROTOCOL 158 ntlmssp(272) : FT_STRING 158 ntlmssp.identifier(8) : NTLMSSP FT_UINT32 166 ntlmssp.messagetype(4) : 0x00000003 FT_BYTES 170 ntlmssp.auth.lmresponse(8) : 00:00:00:00:40:00:00:00 FT_BYTES 222 ntlmssp.auth.ntresponse(156) : FT_UINT16 178 ntlmssp.blob.length(2) : 156 VIOLATION 1 : Child ntlmssp.blob.length has an offset lower than its parent FT_UINT16 180 ntlmssp.blob.maxlen(2) : 156 VIOLATION 1 : Child ntlmssp.blob.maxlen has an offset lower than its parent FT_UINT32 182 ntlmssp.blob.offset(4) : 64 VIOLATION 1 : Child ntlmssp.blob.offset has an offset lower than its parent
It looks like some fields describing the blob position (and present before the blob itself) were put in a subtree of the blob. Whether this is to improve readability is left to someone knowing NTLM Server Challenge protocol (so not me). FT_BYTES 222
ntlmssp.ntlmv2_response(156) : FT_BYTES 222 ntlmssp.ntlmv2_response.ntproofstr(16) : 39:db:db:eb:1b:dd:29:b0:7a:5d: 20:c8:f8:2f:2c:b7 [...] FT_STRING 378 ntlmssp.auth.domain(8) : SUSE FT_UINT16 186 ntlmssp.string.length(2) : 8 VIOLATION 1 : Child ntlmssp.string.length has an offset lower than its parent FT_UINT16 188 ntlmssp.string.maxlen(2) : 8 VIOLATION 1 : Child ntlmssp.string.maxlen has an offset lower than its parent FT_UINT32 190 ntlmssp.string.offset(4) : 220 VIOLATION 1 : Child ntlmssp.string.offset has an offset lower than its parent
It looks like some fields describing the string position (and present before the string) were put in a subtree of the string. Whether this is to improve readability is left to someone knowing NTLM Server Challenge protocol (so not me). FT_STRING 386 ntlmssp.auth.username(26) :
administrator FT_UINT16 194 ntlmssp.string.length(2) : 26 VIOLATION 1 : Child ntlmssp.string.length has an offset lower than its parent FT_UINT16 196 ntlmssp.string.maxlen(2) : 26 VIOLATION 1 : Child ntlmssp.string.maxlen has an offset lower than its parent FT_UINT32 198 ntlmssp.string.offset(4) : 228 VIOLATION 1 : Child ntlmssp.string.offset has an offset lower than its parent
Same things as above
FT_STRING 202 ntlmssp.auth.hostname(8) : NULL FT_BYTES 414 ntlmssp.auth.sesskey(16) : b2:e8:76:55:9c:9c:58:b0:34:4b:d5:a9:9f:8e:98:55 FT_UINT16 210 ntlmssp.blob.length(2) : 16 VIOLATION 1 : Child ntlmssp.blob.length has an offset lower than its parent FT_UINT16 212 ntlmssp.blob.maxlen(2) : 16 VIOLATION 1 : Child ntlmssp.blob.maxlen has an offset lower than its parent FT_UINT32 214 ntlmssp.blob.offset(4) : 256 VIOLATION 1 : Child ntlmssp.blob.offset has an offset lower than its parent
Same thing as above
FT_UINT32 218 ntlmssp.negotiateflags(4) : 0xe0880235 FT_PROTOCOL 0 frame(180) : [...] FT_PROTOCOL 70 smb2(110) : FT_NONE 70 [SMB2 Header](64) : [...] FT_NONE 134 [Tree Connect Request (0x03)](44) : FT_UINT16 134 smb2.buffer_code(2) : 0x00000009 FT_BYTES 136 smb2.reserved(2) : 00:00 FT_STRING 142 smb2.tree(36) : \\WS2016\encrypted FT_UINT32 138 smb2.olb.offset(2) : 0x00000048 VIOLATION 1 : Child smb2.olb.offset has an offset lower than its parent FT_UINT32 140 smb2.olb.length(2) : 36 VIOLATION 1 : Child smb2.olb.length has an offset lower than its parent
Same thing as NTLM Server Challenge, but for SMB2. Probably the same code author.
FT_PROTOCOL 0 frame(268) : [...] FT_PROTOCOL 70 smb2(198) : FT_NONE 70 [SMB2 Transform Header](0) : FT_NONE 70 smb2.server_component_smb2_transform(4) : FD534D42 VIOLATION 2 : Child smb2.server_component_smb2_transform has an end offset past the end of its parent VIOLATION 3 : Child smb2.server_component_smb2_transform has a length longer than its parent FT_BYTES 74 smb2.header.transform.signature(16) : 76:17:6b:19:56:ed:2c:9c:5a:cf:00:a3:0c:04:85:bc VIOLATION 2 : Child smb2.header.transform.signature has an end offset past the end of its parent VIOLATION 3 : Child smb2.header.transform.signature has a length longer than its parent VIOLATION 4 : Child smb2.header.transform.signature has a start offset past the end of its parent FT_BYTES 90 smb2.header.transform.nonce(16) : 3a:aa:96:8f:18:ae:61:e6:e7:6f:1f:00:00:00:00:00 VIOLATION 2 : Child smb2.header.transform.nonce has an end offset past the end of its parent VIOLATION 3 : Child smb2.header.transform.nonce has a length longer than its parent VIOLATION 4 : Child smb2.header.transform.nonce has a start offset past the end of its parent FT_UINT32 106 smb2.header.transform.msg_size(4) : 146 VIOLATION 2 : Child smb2.header.transform.msg_size has an end offset past the end of its parent VIOLATION 3 : Child smb2.header.transform.msg_size has a length longer than its parent VIOLATION 4 : Child smb2.header.transform.msg_size has a start offset past the end of its parent FT_BYTES 110 smb2.header.transform.reserved(2) : 00:00 VIOLATION 2 : Child smb2.header.transform.reserved has an end offset past the end of its parent VIOLATION 3 : Child smb2.header.transform.reserved has a length longer than its parent VIOLATION 4 : Child smb2.header.transform.reserved has a start offset past the end of its parent FT_UINT16 112 smb2.header.transform.encryption_alg(2) : 0x00000001 VIOLATION 2 : Child smb2.header.transform.encryption_alg has an end offset past the end of its parent VIOLATION 3 : Child smb2.header.transform.encryption_alg has a length longer than its parent VIOLATION 4 : Child smb2.header.transform.encryption_alg has a start offset past the end of its parent FT_UINT64 114 smb2.sesid(8) : 0x000048009400003d VIOLATION 2 : Child smb2.sesid has an end offset past the end of its parent VIOLATION 3 : Child smb2.sesid has a length longer than its parent VIOLATION 4 : Child smb2.sesid has a start offset past the end of its parent
The SMB2 Transform Header text item is inserted in the tree using proto_tree_add_subtree() function using the -1 length parameter (which usually means till the end of the tvb, at least for some field types). This function is internally calling proto_tree_add_text_valist_internal() that does: if (length == -1) { /* If we're fetching until the end of the TVB, only validate * that the offset is within range. */ length = 0; } This seems wrong. It might be replaced by something like: if (length == -1) { /* If we're fetching until the end of the TVB, only validate * that the offset is within range. */ length = tvb_captured_length(tvb) ? tvb_ensure_captured_length_remaining(tvb, start) : 0; } Pascal.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Hierarchy of fields & offsets again, more potential offenders Sultan, Hassan via Wireshark-dev (Aug 01)
- Re: Hierarchy of fields & offsets again, more potential offenders Pascal Quantin (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Pascal Quantin (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Sultan, Hassan via Wireshark-dev (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Pascal Quantin (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Stig Bjørlykke (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Sultan, Hassan via Wireshark-dev (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Sultan, Hassan via Wireshark-dev (Aug 07)
- Re: Hierarchy of fields & offsets again, more potential offenders Alexis La Goutte (Aug 08)
- Re: Hierarchy of fields & offsets again, more potential offenders Sultan, Hassan via Wireshark-dev (Aug 08)
- Re: Hierarchy of fields & offsets again, more potential offenders Pascal Quantin (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Pascal Quantin (Aug 02)
- Re: Hierarchy of fields & offsets again, more potential offenders Pascal Quantin (Aug 09)
- Re: Hierarchy of fields & offsets again, more potential offenders Alexis La Goutte (Aug 09)