Malformed S1AP NAS-PDU

edit

Hi Pascal - thank you,

the MS Classmark 3 as having a length too short

Not sure if I got the idea right but looks like manually changing its current length 03 to 0A makes the whole message decode correctly, so I'm wondering if that 40 05 70 40 26 00 00 is Supported Codecs IE indeed or rather it's just part of MS Classmark 3.. https://drive.google.com/file/d/1jYGR...

Please let me know if you want me to file a bug/enhacement on it anyway.

Thanks & Regards,

Dmitriy

Manually modifying the IE length allows you to hide the problem, but still the MS Classmark 3 content is suspicious (spare bit set to 1, A5/7 algorithm supported while it does not exist), so I doubt it is valid.

Anyway I added an extra check in this commit: https://code.wireshark.org/review/#/c...

It will trigger another malformed error but with a more meaningful message.

Thank you: I'm checking NAS-EPS PDU encoding with our Engineering team in parallel.

Hi Pascal, sorry could you please explain why exactly Wireshark used to consider my MS Classmark 3 "as having a length too short compared to the payload parsing"? After Item 1 ID code 0x26 (id-NAS-PDU) and 0x00 (criticality=reject) goes 0x37, which looks like a valid length of the remainder as it covers it exactly incl Supported Codecs IE. Meanwhile MS Classmark 3 IE itself has allowed length 0x03 (which can be 1-32 octets as per 3gpp 48.008), same as MS Classmark 2 IE. So I'm struggling to understand why Wireshark used to consider Supported Codecs IE as the continuation of MS Classmark 3 before the changes you've made. Meanwhile how can I obtain the build with the changes? Thanks in advance, Dmitriy

You need to check the MS Classmark 3 encoding in 3GPP 24.008 spec and do the decoding manually. You will see that the parsing of the bits goes beyond the 3 bytes indicated in the IE, which is an encoding error. You an find builds with my change here: https://www.wireshark.org/download/au... But again it simply gives a better error message, it does not solve anything as the message is not properly encoded.

Here are my manual MS Classmark 3 decoding results: 20 = its IE type, 03 = its length, E8 80 1F = its value. I cannot see anything wrong here... what exactly makes Wireshark decide that what follows is the continuation of MS Classmark 3 IE and not the next IE? Shouldn't it obey MS Classmark 3 length alone and parse exactly 3 successive octets no matter what?

Did you try to decode the e8 80 1f bytes according 24.008 spec, as I already asked you? You will see that there is not enough bits and that the third byte ends in the middle of a field.

Wireshark was parsing above the 3 bytes due to a variable underflow, as the length was too short for the bits encoding. This is what I fixed in my patch, and you can use a 2.9.1 development build to have it. And even if you consider only 3 bytes for his IE, the codecs list IE is also malformed as I already explained. I have no idea what generated this attach message, but it has several errors and Wireshark is here to spot them, not ignore them (a real MME would probably ignore the Classmark 3 and codecs list as it would simply forward them to the MSC for combined attach). The Wireshark development tree is currently based on release 15. The 2.6.x releases must be around release 14, but I did not double check.

Understood. It's perfectly fine to flag any errors as long as any other IEs that can be decoded are still decoded, e.g. TAI, EUTRAN-CGI, RRC-Establishment-Cause in my trace, which all seem to be encoded correctly. I'll double check the 24.008 version supported by our internal test tool that generates those messages.

Note that the Classmark 3 encoding has not changed since years (it gives the GSM capabilities), and that those bits (that are at the beginning of the IE) where already present in release 3 (year 2000). So you should probably fix your internal test tool to at least provide a meaningful content.

Thank you - they've just fixed both IEs. Could you please confirm they look good now? https://drive.google.com/file/d/139hA...