--On 25 October 2010 09:55:47 -0700 Steve Atkins
<steve(_at_)wordtothewise(_dot_)com>
wrote:
8.14 Malformed Inputs
DKIM allows additional headers to be added to a signed message without
breaking the signature. This tolerance can be abused during a replay
attack by adding additional copies of headers that are displayed to the
end user, such as From or Subject, to an already signed message in a way
that doesn't break the signature.
The resulting message violates section 3.6 of [MAIL] so the way it will
be handled and displayed by an MUA is unpredictable - but in some cases
they will display the newly added headers rather than those that are part
of the originally signed message. This might allow an attacker to replay
a previously sent, signed message with a different Subject, From or To
field.
My guess is that for the set of MUAs that aren't paying attention to DKIM
signatures, random placement of the second header will ensure that the
wrong header is displayed 50% of the time. Familiarity with a few popular
MUAs (assuming that they deterministically display either the first or the
last) would achieve better than 50% display rates. Heck, if you insert one
header before the signed header, and one after, then you might well get a
100% display rate across all MUAs that aren't aware of this problem.
It's conceivable that "unpredictable" is
Because of this, inbound mail system implementors should consider
defending against this sort of replay attack by either
1) Rejecting or treating as suspicious any message that has multiple
copies of headers that are disallowed by section 3.6 of [MAIL],
particularly those that are displayed to the end user (From, To, Cc,
Subject).
And, "Date", please? It also meets those criteria. Some messages might have
quite different meanings when the date is changed. Perhaps a message with
instructions to call a premium rate phone number, "by Friday". Such a
message might be repurposed after the number has changed hands.
Or, a political statement might have very different implications at a later
date. For example, I saw a tweet recently saying that a UK coalition
government minister (a Liberal Democrat) had called another government
minister (a Conservative) "incompetent". It turned out that this was true,
but the linked article was written months before the recent general
election, before the coalition was formed. So, the implications were very
different than if the statement were made today.
2) Treating any message that has multiple copies of headers that are
disallowed by section 3.6 of [MAIL] as not DKIM signed.
Senders who feel that their messages might be particularly vulnerable to
this sort of attack who don't want to rely on receiver filtering of
invalid messages can ensure that adding additional headers will break
their DKIM signature by including two copies of the headers they're
concerned about in the signature (e.g. "h= ...
from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further
discussion.
h= ... from:from:to:to:subject:subject:date:date ...
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html