Re: [Nmh-workers] Weird behavior with non-ascii code in headers

[Ken Hornstein]

>Right now, as we have seen, the answer is yes for nmh (where
>"replacement" is truncation).

Yes, but that was a bug in the format engine!  I don't think anyone
thinks truncation is the correct answer.

>In general, I don't think the
>question is easy to answer.  What if an attacker, or
>mistake, moves the divider between the display name and
>angle address?  And it's even more complicated because an
>"address" can be an nmh alias.

I am trying to see how this could possibly happen, and I really can't.
Can you give me an example how it could?  We're talking about mapping
all characters outside of a given range into one particular character.
It doesn't have to be ?, it could be anything (well, I think it shouldn't
be one of the specials, so we'd want to stick with something that's
considered atext in RFC-5322 parlance).

>Using '?' as the replacement character is especially
>problematic because it's used as all or part of the
>delimiters in RFC 2047 encodings.  It seems to me that an
>attacker could then do just about anything to an address,
>such as encoding something that turns into a ',' so the
>first part of the display name becomes a standalone address
>or alias.  (2047 specifically mentions encoding a "phrase",
>which is what a display name is.)

I am trying to envision this attack you describe, and I am having a
hard time.  First, exactly how could someone encode something to turn
characters into a comma?  I'm just missing how that happens.  If the
concern is that an RFC-2047 encoding be constructed that might contain
a special ... well, maybe (you could alleviate that concern by not using
? or = as a replacement character).  But I'm trying to figure out why you
would even bother, instead of just constructing an RFC-2047 phrase
directly.

Secondly ... I am actually skeptical that this could even be considered
an attack vector.  Assuming no buffer overflows, what, exactly, would
an attacker be trying to accomplish?  Send the reply email to the wrong place?
Why not simply use a Reply-to header?

>This just isn't a hole that we should retain.  Punt to user
>on input error, that's the only safe action here.

Yeah, that just sounds like it sucks to me; from what I've seen, nobody
else does that.  Also, it is not consistent with the guidance in the
mailformed message draft.

--Ken