nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Quoted printable problem


From: Ken Hornstein
Subject: Re: [Nmh-workers] Quoted printable problem
Date: Mon, 17 Dec 2012 21:31:27 -0500

>There is an even better reason: security.  Since a multipart wrapped
>in QP (or base64) is undefined, there is no correct way to deal with
>it, and therefore nobody will deal with it "correctly" – if that was
>even possible.  This means broken parsers generating stack overflows,
>ripe for exploitation by viruses.  I would *really* like to see the raw
>source for a couple of these messages, as I'm starting to wonder if
>these aren't actual virus payloads.

So, I've been meditating on this for a bit, and let me speak to some of
this.

- The interpretation of Postel's Law is ... not universal.  See:

  http://en.wikipedia.org/wiki/Robustness_principle
  http://tools.ietf.org/html/rfc3117
  http://queue.acm.org/detail.cfm?id=1999945

  So, the _right_ thing to do here is not clear, at least to me.  The MIME
  RFCs don't spell out what to do when you receive a message that is
  malformed; are you supposed to error out?  Fall back to something else?
  Try to do a best effort-guess?  It's okay to drop stuff on the floor
  when we're talking about network packets since it's expected there will
  be loss, but I'm not sure the same expectation applies to email.

- I am 100%, absolutely sure that at least in my case the message in
  question was not a virus payload.  In my case the multipart claimed
  that the Content-Transfer-Encoding was q-p, but since there were plenty
  of equal signs that were not encoded it was clear that it wasn't.  I
  edited by hand the encoding to 7bit and I was able to extract out the
  content (my tickets) fine.

- If our fallback position is that multipart types that have a bogus
  encoding such as quoted-printable or base64 are interpreted as 7bit
  (or 8bit) I fail to see how that will generate any NEW security issues
  in terms of parsing MIME headers.  I have a strong suspicion that this
  is how other mailers deal with such messages.

- I actually got our admins to restore my home directory from backups and
  I was able to locate the offending message in question.  However, it
  is AFTER I edited the Content-Transfer-Encoding from quoted-printable
  to 7bit.  There are actually two C-T-E headers in that message;
  a toplevel multipart/mixed type and one of the parts had a
  multipart/related type.  I don't recall if only one or both of those
  were quoted-printable (I believe it was both, but I honestly can't be
  sure).  The multipart/related type also included a charset parameter
  which makes me think it's especially bogus.  I made no other changes
  to this message.  If you want a copy of it, I'm glad to send it to you
  off-list.

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]