[Top] [All Lists]

Re: NUL handling and security considerations [was: Re: My open issues with RFC3028bis]

2005-07-02 07:38:15

Michael Haardt <michael(_at_)freenet-ag(_dot_)de> writes:
On Thu, Jun 30, 2005 at 10:37:29PM -0700, Philip Guenther wrote:
[RFC 2047] Section 5, almost at the end:

  Only printable and white space character data should be encoded using
  this scheme.  However, since these encoding schemes allow the
  encoding of arbitrary octet values, mail readers that implement this
  decoding should also ensure that display of the decoded data on the
  recipient's terminal will not cause unwanted side-effects.

NUL is not white space.  If a word contains either, its author did not
care about this recommendation is and it may be a good idea to drop it
or display its decimal representation or whatever else.  Most likely
the above addresses ESC sequences.

It's valid syntax, and Unicode has a NUL codepoint, so it's not like we
can claim that something like:

From: Philip =?US-ASCII?Q?=00_Guenther?= <guenther(_at_)sendmail(_dot_)com>

can't be converted to Unicode, so the new text in 2.7.2 doesn't cover it.

I may be stretching it too far here, but AFAIK, there are implementations
that truncate strings, thus corrupting test results.  Trying to label them
non-conforming probably won't succeed, but we should not silently ignore
this problem.

I guess there are two choices:
A) Require correct handling of NUL
B) Strongly prefer correct handling of NUL and warn about the dangers of
   not doing so in the security considerations

I have no major problem with A but I think B is a better choice. FWIW, the
implementation I work on has no problem handling NULs, but I worry that
this will make many other implementations non-conforming.

On that thought, there's a security consideration missing.  As a
first draft:

   As with any filter on a message stream, if the sieve implementation
   and the mail agents 'behind' sieve in the message stream differ in
   their interpretation of the messages, it may be possible for an
   attacker to subvert the filter.  Of particular note are differences
   in the interpretation of malformed messages (e.g., missing or extra
   syntax characters) or those that exhibit corner cases (e.g., NUL
   octects encoded via [HEADER-CHARSET]).

Of course, this problem is not specific to email; I recall reading
in the last 90s about using differences in IP fragment handling to evade
networking monitoring devices.  The first case of this problem in email
that I recall involved virus filters that were stricter about their MIME
handling than MS Outlook was, such that the filter would fail to scan
MIME parts which had a syntax error in their MIME headers while Outlook
would accept them sufficient to be infected.

The question is: is there anything we can say on this other than "this
is a problem"?  Recommending that sieve implementations be more liberal
(than MUAs) doesn't work because the attack works both ways.  Rewriting
messages to make them strictly compliant has a horrible history, while
rejecting everything that's even slightly suspect is politically
impossible.  Do we just document it, grunt, and move on?

Seems like the best we can do, doesn't it?