--On 25 October 2010 09:55:47 -0700 Steve Atkins <st...@wordtothewise.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
