#39 Header field excluded if it is a substring of another h.f.

Mark Martinec

While signing and generating a h= list of included
header fields, header fields whose header field head
is a substring of another header field head are
excluded from the h list and excluded from signature

E.g., a message containing the following header

X-Virus-Alert: xxx
X-Virus: yyy

results in the X-Virus being excluded, treating it
like a repeat of X-Virus-Alert (like repeated Received
header fields). The resulting signature is:

DomainKey-Signature: ...

The bug is in incorrect use of strncasecmp
in routine dk_hdrsigned(), file dk.c.


    • assigned_to: nobody --> sm-msk
  • Logged In: YES
    Originator: NO

    Proposed (as-yet-untested) patch attached.
    File Added: PATCH

  • Logged In: YES
    Originator: NO

    Actually, I'm not sure I follow your description.

    If h= lists x-virus-alert and not x-virus, isn't the latter supposed to be excluded anyway?

    I took a working message which included "date" in h=, and added a "Datefoo: BLAH" header above "Date" but made no other changes to the message, and it continued to verify just fine.

    I was imagining if h= includes x-virus it might pick up x-virus-alert via the strncasecmp() you mentioned, but that also seems not to be the case. The attached patch tightens up that test though.

  • Logged In: YES
    Originator: NO

    After further testing and review, I've removed the patch.

    The strncasecmp() call you cite appears to be correct; the first parameter is a NULL-terminated header name, the second parameter is the header being checked, and the third parameter is the number of bytes before the colon in the header being checked. There's thus no way for a substring match to hit as you've described.

    I tried again to reproduce the problem by taking a signed, verifying message whose signature contained "h=from:message-id;" and added a "Fromble" header before and after the existing "From" header, and the message still passed with correct canonicalization both times.

    If there's a problem to be fixed here, I can't reproduce it, and it's not in dk_hdrsigned().

    • status: open --> pending
  • Proposed patch #1

    • status: pending --> open
  • Logged In: YES
    Originator: NO

    I had somehow interpreted this as a verification bug so my test data was testing a totally different code path than the one that causes this problem.

    Patch restored. It does fix the problem.
    File Added: PATCH.dk

  • Logged In: YES
    Originator: NO

    v0.5.0 released, which contains this fix.

    • status: open --> closed-fixed