Note: This is exactly how CMS mitigates this attack. The SignedAttrs DER
structure is appended after the content, so DER parsing will fail if any
octets are added or removed.
On Tuesday, June 11, 2013, Richard Barnes wrote:
> Ah. I see. Guess that's what the '.' character is for in the base64
> version. :)
>
> In this version, you could just require that the JWS protected header have
> no trailing white space. Then, if you the attacker trims any characters,
> it won't be valid.
>
> Senders MUST NOT create a header with trailing white space. Recipient
> MUST (1) check that the header is valid JSON, and (2) check that there is
> no trailing white space in the header string.
>
> I think this is a flavor of your (2).
>
>
>
> On Tuesday, June 11, 2013, Jim Schaad wrote:
>
> Yes – you are still not understanding the problem.****
>
> ** **
>
> There is an interesting issue that comes up in computing hash values of
> multiple things which are concatenated together. This issue is that it is
> possible to move items from one thing to an adjacent thing and still get
> the same hash value.****
>
> ** **
>
> Thus if field1=”aaa” and field2=”bbb” you get “aaabbb” as the value being
> hashed.****
>
> If field1=”aa” and field2=”abbb” you still get the same “aaabbb” as the
> value being hashed but different ideas of what the two fields are.****
>
> ** **
>
> There are three classic ways to deal with this problem:****
>
> ** **
>
> **1. **Use length prefix on each field – this is the ASN.1 encode
> it version****
>
> **2. **Use fields that are well defined in terms of delimiters****
>
> **3. **Put in separation characters which are not allowed in either
> field.****
>
> ** **
>
> I once tried to argue that this is what we should do and ended up with the
> following: Method one was not considered acceptable, method two was not
> possible given the current state of JSON parsers, method three is what we
> currently do.****
>
> ** **
>
> JSON parsers allow for indefinite amounts of whitespace following a JSON
> object so that will always be a problem. Additionally there are JSON
> parsers which believe they can stop parsing and not produce an error once
> it has fully built a top level object. Thus they consider the string
> ‘{“a”:“b”}FRED” to be something that can be successfully parsed.****
>
> ** **
>
> This allows for an attacker to move items from the content to the
> protected string unless there is an externally imposed rule about what
> happens for trailing characters after the protected content.****
>
> ** **
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
