Re: Threat assessment, some dissent RE: [ebxml-msg] security problemwith ebXML MS

[James M Galvin <galvin@drummondgroup.com>]

This note is long and I apologize in advance for that.

Your argument overlooks two points.

1. The principal threat is not denial of service.  The principal threat
   is unintended actions.

   The specification is ambiguous regarding the significance of MIME
   headers for payloads.  Thus, one implementation may choose to
   essentially ignore such MIME headers depending solely on information
   in the SOAP envelope.  The MITM threat for such implementations would
   be reduced as a result.  However, another implementation may choose
   to dispatch as a result of some information in the MIME headers.
   Such an implementation would put any trading relationship at risk.

   An adversary could construct a body part that would pass the digest
   calculation but the actual content would cause an implementation to
   take actions other than what was intended.

   You might think this is contrived but then I'm sure most of the
   buffer overflow bugs found in a variety of popular applications were
   thought to be contrived before somebody did it.  This might be a
   denial of service attack for the ebXML messaging but since you
   dragged MIME into the processing who knows what it might do.  The
   point is the entire server machine is at risk, not just this message.

2. Routing is not under control of the application.  Also, what is to
   prevent a peer from re-routing a message or otherwise forwarding it?

   While it may be true that the MITM attack is reduced for peer-to-peer
   relationships, it is not at all obvious to me that either end has
   complete control of the path a message may take.

   Even if you do, it doesn't make sense from a security view to have
   two sets of processing rules, i.e., if the path is peer-to-peer
   process this way and if the path is multi-hop do it this way.  In
   general, when implementing it is a bad practice to introduce
   unnecessary changes in the control flow.

In security there are purists who insist on doing everything possible
and doing it right.  Even if one takes a more pragmatic view, the goal
needs to be that whatever you do you must do it right.  Adding digital
signatures that leave a clear and present vulnerability, however small,
is analogous to putting steel doors on a wooden house that still has
windows without bars.



Speaking more directly to your points:


    1. (Internal) Header modification is most 
    commonly a problem for one transport,
    SMTP, when using Relays (or Gateways or other intermediaries).

The fact that something occurs "ordinarily" *and* is wrong is exactly a
reason for detecting it.  Otherwise you become complacent and won't
notice when it really is a problem.

    "Helpful" CTE changes and companion header changes
    are presumably not going to happen
    under HTTP or HTTPS, even when intermediaries are involved,
    unless they gateway into email.

"Presumably" won't happen?  It's not about whether it will happen or
not.  In a risk analysis you assume it will.  The question is, "What is
the downside of it happening?"  Here it is not just ebXML messaging
errors, is the exposure of the entire server.

    And simply ignore any
    BEEP profile that has the problem :-) So a "MITM threat"
    based on changed headers is usually not malicious, and not
    universal across transports.

Which is exactly the reason you need to detect it.

    In a way, the SMTP situation speaks
    for not including headers in the scope of the signature
    if we are mainly concerned with the threat of inadvertently
    breaking signatures that are otherwise good. In other words,
    by including headers in the scope of the signature, we
    risk not getting the payload (potentially validly signed
    and intact) processed, because a signature check would fail
    due to the changed headers in the SMTP relay case. 

This is tantamount to suggesting that I should put a digital signature
on the payload and if it doesn't validate I should ignore it.

    We are opening ourselves up to uninintentional 
    denial of service by signing headers!

You are protecting yourself from unintended consequences.  Denial of
service is secondary, i.e., it is not the principal threat.

    If headers were important, and they were in danger
    of being maliciously changed, 
    then using a Suresh/RichSalz method could
    be optionally adopted (but I think simplicity would
    favor not going there).

The fact that it can be done means they are in danger.

    As Chris Ferris mentioned, peer to peer transports using 
    transport layer encryption would frustrate header manipulation. 
    Likewise, digital envelopes would discourage header manipulation, 
    even when intermediaries (gateways, relays, MSHes, 
    various FW proxies,etc) are involved. 

This presumes the third parties (peers) are not adversaries or have not
been compromised by a third party.

    This means there exist other ways of avoiding the MITM
    threat to headers when it is thought to be a live possibility.
    This means that mandating some redundant encoding of
    headers is not universally warranted; whether it is even
    a live possibility, depends on the specifics of transport
    as well as packaging.  No reason to require unconditionally.

Although conceptually it might (and I'm not suggesting I agree here)
make sense to conditionally require, I would look to the implementors
for an opinion.  Which do they think is more straightforward: always
doing it the same or adding additional control flows based on
circumstances.
    
    2. There could be hijacked relays or even other 
    hijacked intermediaries and they could 
    change headers maliciously. One suggested change
    was to alter the content-type header so that the payload
    processing would benefit the hijacker somehow, 
    by misdirecting it to another application handler.
    
    However, the _routing_ function within ebXML has largely dispensed
    with any strict dependence on the semantics of MIME content-*
    fields. MIME is mainly being used for its generalized bundling
    and unbundling capability. The diminished dependence on the
    MIME apparatus is partly because whatever the service or action
    element says, the ebXML payload will
    most likely just have the same old content-type of "text/xml" or
    "application/xml" ( or maybe "*/*+xml.") Why did we have service
    and action elements, if we were going to use the MIME apparatus for
    application-level routing? The MIME values were 
    regarded as insufficiently fine-grained.
    The MIME content-type provides a partly
    redundant, insufficiently informative label, that within
    ebXML messaging, can be largely ignored for app. routing
    purposes anyway. So, MITM threat largely irrelevant for internal
    content-type headers and the application level misrouting.
    No reason to require unconditionally.

If it is true that the MIME headers are irrelevant and are strictly for
transport, then as I said to you private email earlier the specification
should make this the case.  Simply declare that all payloads are of type
"application/octet-stream" with a Content-ID header and mandate that
only information in the SOAP Envelope is to be used to process the
payloads.  The fact that the specification is ambiguous on this point is
why there is an issue.  But then you have the problem of binding the
Content-ID to the payload.  (See below.)

    3. MITM change of headers could at least interfere 
    with processing, and so be an interference with 
    service attack. If the goal is interfering with service, 
    however, there are a lot of other attacks that would 
    be easier/faster/cheaper to undertake.
    Signing headers would not in itself defeat
    the interference with service, but just offer another
    way to detect it. Signing provides no remedy for this
    threat. No reason to require here.

As previously suggested, this is tantamount to saying put a digital
signature on it and if it doesn't validate just ignore it.

    4. Another possible reason to show
    that the "message" had not been messed with, 
    would be to discourage a certain
    kind of "replay" ( payload recycling ).
    By binding a SOAP envelope 
    to its payload(s) by signing,
    we would at least have some evidence about
    the entity that was replaying the payload.
    (It would not prevent it, of course. We could
    always still cut and paste an independently
    signed payload and repack, resign, resend.)

This binding is only true to the extent that Content-ID: values are
unique and that you check to make sure you haven't seen the one you just
received in a prior payload.  And this would require that the
Content-ID: value be derived from the payload.

Since none of this is true your argument does not apply.

    Interestingly, we already decided that some changes 
    are "don't care" with respect to
    message "integrity" (the changes intermediaries 
    do to the SOAP envelope, for example). 
    Given this existing agreement--which forced our use
    of XMLDsig in the first place--why not just
    decide to exclude the headers from within 
    the scope of the signature,
    and say that ebXML message "integrity"
    does not guarantee that the bodypart headers 
    have not changed (added, deleted,
    changed case, been given wrong values, etc)? 

Not caring about trace information or any other "informational"
information is vastly different than caring about information upon which
any processing may depend.

    As Suresh pointed out, the one bodypart header 
    that ebXML messagers do care about a little 
    (content-id) is one whose alteration will 
    most probably throw 
    an exception during processing anyway,
    if we are using XMLDsig. Since the
    error is already detected, no reason
    to require internal header signing here
    either.

The error is not already detected.  There is another point that would
have come out when we finally got to canonicalizing the MIME headers and
that is the cotent-id needs to be bound to the payload.  One way to do
this is to include the content-id value with the payload digest.
Another way is to ensure that the order of the payloads and the order of
the reference elements of those payloads and the order of the duplicated
MIME headers all matches.

All of that needs to be true for your argument (and Suresh's) to be
valid.

    None of the other headers 
    (content-description, -disposition,etc)
    supply info that needs to be trusted in the typical
    ebXML messaging case. If the payload
    did happen to be some elaborate MIME
    structure of many varied content types
    with embedded multiparts and whatnot,
    protecting all these headers could get
    quite complex. Easier to just envelope 'em
    if there is a viable threat of MITM.
    Mandating some header protection scheme
    again unwarranted.

If it's not relevant don't include it.

    5. Under a CPA, the packaging elements would specify
    what the content types and layout are supposed 
    to be for a specific conversation. The
    wrong content-type headers could be detected and 
    warned about. So, again, embedding and
    signing a header is not universally warranted
    or necesary.

This assumes that the detection is attempted and is warned about.
However, the specification is ambiguous on this point.

    All that said, if you still want to complicate
    things by worrying about a threat with very
    little real disutility, the Suresh/RichSalz procedure
    seems OK as an optional 2.0 addition. I think
    there is yet no compelling reason to require its
    use unconditionally within ebXML messaging, however.

If history has taught us anything about protocol security it surely has
taught us that if you don't include security as goal from the start you
will be forever backfilling to get it right because it will be competing
with backwards compatibility.

Jim