Some older dissectors that predate Unicode and parse text protocols
are prone to generate invalid UTF-8 strings. This is a bug and can have
safety implications.
For example passing invalid UTF-8 to proto_tree_add_string() is a
common bug. There are safeguards in format_text() but this should
not be relied on as a general solution to the problem.
For one, as the name implies, it is only used with representation of a
field value, which is not the same as the value itself of an FT_STRING field.
Issue #18317 shows another reason why.
For now this compile flag only enables extra checks for string ftypes,
which covers a subset of proto.h APIs including
proto_tree_append_string(). Later is should be extended to other
interfaces.
This is also not expected to be disabled for release builds because
there are still many dissectors that do not correctly handle strings.
More work is needed to 1) identify them and 2) fix them.
Ping #18317
The remote-capture-command option does not work when selecting
remote capture command selection 'other' from the extcap capture
options dialog. Fix strcmp statement to actually check for 'other'.
Fixes: #18381
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.
Search is tried as user enter regex string. Regex will be
invalid as they type it (starts with "\" or fat fingered "*")
If Wireshark is run from command line, error line is generated
for every attempted match in the search list.
** (wireshark:8344) 00:29:15.353028 [GUI WARNING] --
QString::contains: invalid QRegularExpression object
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
João Valverde
Pau Espin