Osmux protocol [1] has historically been used as a replacement of RTP in
the SCCPLite or AoIP interfaces over satellite links, since usually the
satellite link is placed between the BSS (BSC) and the CN (MSC.
However, some network operators found need for Osmux in the Abis
interface, that is, between BTS and BSC. Hence, an Osmocom extension IE
"Osmux CID" was added to the IPAC CRCX/MDCX ip.access Abis
implementation, which is understood by osmo-bts and osmo-bsc. This new
extension IE is similar to the already existing extension IE in the
BSSMAP protocol spoken in AoIP (see BE_OSMOCOM_OSMUX_CID in wireshark
code).
More information on how this IE is used can be found in OsmoBTs and
OsmoBSC user manuals [2][3] (search for "Osmux" keyword).
This patch adds the new IE to the RSL dissector and avoids informing the
RTP subsystem to follow this conversation if the IE is found, since
marking it as an RTP conversation overrides the default or user
configured osmux dissector (UDO port 1984).
[1] https://ftp.osmocom.org/docs/latest/osmux-reference.pdf
[2] https://ftp.osmocom.org/docs/latest/osmobts-usermanual.pdf
[3] https://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf
SMB can have two types of string encodings: Little Endian UTF-16, and
Extended ASCII OEM code page (DOS code pages, like CP 437, 850, 866, etc.)
The strings can either have an exact length, or be null terminated
inside a larger buffer that may contain other fields.
Currently the dissector returns strings in the original encoding for
the Extended ASCII strings, and returns ISO-8859-1 strings, not UTF-8,
for Unicode strings. Neither are correctly handled internally when non
ASCII values are used.
We should always produce UTF-8 strings for internal use.
For the OEM strings, we can't tell what code page it is, so use ENC_ASCII
to be safe. (A preference could be added here and in packet-smb-browser.c for
the default code page.)
For the UTF-16 strings, also produce UTF-8. Continue to handle an odd
case where some Windows 2000 servers terminated UTF-16 strings with only
a single NUL and then provided an odd byte count of the string length
plus the one NUL byte.
Fix#18369
MS-CIFS indicates that the deprecated commands SMB_COM_SEARCH (0x81),
SMB_COM_FIND (0x82), and SMB_COM_FIND_UNIQUE (0x83) never use
Unicode, and "names are returned in the extended ASCII (OEM)
character set only." That makes sense, as the size in the return
is listed as a fixed 13 bytes. Honor that.
RFCs 9110 5.5 is explicit about allowed characters in field values:
"Specification for newly defined fields SHOULD limit their values
to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD
treat other allowed octets in field content (i.e., obs-text [%x80-FF])
as opaque data... Field values containing CR, LF, or NUL characters
are invalid and dangerous."
Up to RFC 7230, an obsolete "line-folding" mechanism that included
CRLF was allowed.
So NUL is not allowed, and all the known fields we support only allow
ASCII, so for display purposes it is permissible to retrieve the
value as ASCII. tvb_get_string_enc with ENC_ASCII does actually
retrieve a buffer of the full length with internal NULs if they
are in the buffer, but other functions end up truncating the value
at the first null if it exists. We should eventually have expert infos
that flag internal NULs or other invalid values with varying degrees of
severity, and display unknown header types with invalid values as
something like FT_BYTES with BASE_SHOW_ASCII_PRINTABLE.
Continue, for now, to pass along the raw value in the header_value_map
in case some dissector was using that value.
Fix#18368.
If UTF-8 validation fails, set the fvalue to a sanitized value so that calls
later to retrieve it don't null deference and crash. We could,
especially for a release, disable the assertion and just sanitize
bad strings.
Related to #18363
Use ENC_APN_STR for APN and FQDN. This avoids possibly producing
invalid UTF-8 by overwriting one byte with . with the implementation
that was done in the dissector.
Fix#18364.
Sanitize HTTP header values before adding them to the tree.
We treat them as always US-ASCII. (Note, however, that RFC
7230 discusses that while "Newly defined header fields SHOULD
limit their field values to US-ASCII octets. A recipient SHOULD
treat other octets in field content as opaque data.")
Fix#18362. Fix#18363.
The setup and data flags are single characters, displayed as
ASCII if printable ASCII or otherwise escaped, with a special
value when 0. FT_CHAR is the appropriate type for that. Use
range strings to handle the special case formatting. This
allowing using proto_tree_add_item.
Fix#18359. Fix#18360. Fix#18361.
XML 1.0 allows valid UTF-8 characters, except for the ASCII control
characters other than tab, carriage return, and line feed.
(It does not allow form feed and vertical tab, so the allowed group is
not the same as the standard ctype.h isspace category. It also
allows but discourages DEL (\x7F).)
The characters cannot be included as character references of the
form &#xx; either; there is technically no way to include them.
Escape them as done prior to 89e96c1e77
but continue to leave bytes with the high bit set alone so that
UTF-8 printable characters are not escaped.
Fix#10445
When a dissector directly adds a string value through
proto_tree_add_string[_format_value], validate that it is
UTF-8 so that only valid UTF-8 strings are used internally,
and written to output (whether text, JSON, or XML.)
(We were treating it as a UTF-8 string anyway, but not
validating it.)
If the string passed in is not UTF-8, that's a dissector bug
Dissectors that use API functions like tvb_get_string_enc
will always produce valid UTF-8, but some do their own
processing.
Fix#18317
packet-bgp.c:6886:9: warning: Value stored to 'reader_offset' is never read [deadcode.DeadStores]
packet-bgp.c:6903:13: warning: Value stored to 'reader_offset' is never read [deadcode.DeadStores]
packet-bgp.c:6907:13: warning: Value stored to 'reader_offset' is never read [deadcode.DeadStores]
packet-bgp.c:6917:9: warning: Value stored to 'reader_offset' is never read [deadcode.DeadStores]
packet-bgp.c:6925:9: warning: Value stored to 'reader_offset' is never read [deadcode.DeadStores]
packet-mbim.c:5651:5: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-mbim.c:5703:5: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
Dynamically create the indices for the SRT table so that
all the message types sent from the tap get put in the SRT
table, instead of hardcoding in a list of four that is a
smaller subset of what is matched in gtp_match_response.
If this dissector is going to be registered to a port that isn't
IANA assigned to it, it should at least reject packets that don't
look like the protocol. If it's going to handle TCP desegmentation,
it also should deal with not necessarily starting at the beginning
of a stream too.
For GTP session tracking (off by default), there's a mapping
from <TEID, ADDRESS> to frame numbers. The current implementation
is a tree (converting the address to a string for keys) of linked
lists of the TEIDs. That gets very slow when there's a large number
of TEIDs. Convert it to a map that uses the teid and address,
with the TEID used for the hash.
There's still a reverse lookup (foreach_remove) when TEIDs are reused
or sessions fail, but this still yields over a 10x speedup on a
few moderate sized test files (~50000 GTP-C packets).
The session table maps frames (which are 32 bit uints that
start at 1) to sessions (which are also 32 bit uints that
start at 1), so use GUINT_TO_POINTER and the direct hash
functions instead of creating extra file scope pointers.
Pascal Quantin
Pau Espin