Suricata

Ma Ja wrote:

If I am correct, there might be a decoding problem with decoding quoted-printable encoded email text attachments in Suricata.

Of course, with "attachments" I meant MIME multipart bodyparts.

Suricata 8 and 7 seem incorrect.

So does Gmime in another way, while comparing to Wireshark IMF exported object

@Philippe Antoine wrote:

So does Gmime in another way, while comparing to Wireshark IMF exported object

Is it possible to tell what GMime does wrong? If we use that as a reference, we might also have a problem.

< +static gboolean related_url_string_cb(field_info *finfo, gboolean doit, 
< const gchar**  ret_url)
---
> +static gboolean related_url_string_cb(field_info *finfo, gboolean doit, const gchar**  ret_url)

I think Gmime does insert wrongly a newline (compared to Wireshark and suricata)

(Sorry for jumping into this thread, a colleague pointed me to it as I use GMime in several projects, inter alia the MUA Balsa – thus I'm interested in any possible bugs in that library…)

The dump from the PCAP actually looks a little odd at this point:

000030d0  73 74 61 74 69 63 20 67  62 6f 6f 6c 65 61 6e 20  |static gboolean |
000030e0  72 65 6c 61 74 65 64 5f  75 72 6c 5f 73 74 72 69  |related_url_stri|
000030f0  6e 67 5f 63 62 28 66 69  65 6c 64 5f 69 6e 66 6f  |ng_cb(field_info|
00003100  20 2a 66 69 6e 66 6f 2c  20 67 62 6f 6f 6c 65 61  | *finfo, gboolea|
00003110  6e 20 64 6f 69 74 2c 20  3d 0a 0a 63 6f 6e 73 74  |n doit, =..const|
00003120  20 67 63 68 61 72 2a 2a  20 20 72 65 74 5f 75 72  | gchar**  ret_ur|
00003130  6c 29 3d 30 41 3d 0a 2b  7b 3d 30 41 3d 0a 2b 3d  |l)=0A=.+{=0A=.+=|

A line break in a text body, represented as a CRLF sequence in the text canonical form, must be represented by a (RFC 822) line break, which is also a CRLF sequence, in the Quoted-Printable encoding.
[…]
Note that many implementations may elect to encode the local representation of various content types directly rather than converting to canonical form first, encoding, and then converting back to local representation. In particular, this may apply to plain text material on systems that use newline conventions other than a CRLF terminator sequence. Such an implementation optimization is permissible, but only when the combined canonicalization-encoding step is equivalent to performing the three steps separately.

IMHO the GMime decoder does decode the input at offset 0x3118 correctly according to this optimisation: the two octets 0x3d 0x0a represent the soft line break which is removed according to Clause 5 of the the aforementioned standard, whilst the hard line break at offset 0x311a is preserved. It may be confusing that the attachment is an application/octet-stream, but the standard does not explicitly rule out using the “simplified” line breaks for this content type. This looks really like a somewhat special corner case…

Or did I miss something here?

The patch file looks indeed correct without the newline...