3 ms·
Isn't "game-over flaw" a bit overstated? It's a serious blunder, but if the data you're authenticating is highly structured then in many cases it won't be expl
by dfranke 17y ago
Isn't "game-over flaw" a bit overstated? It's a serious blunder, but if the data you're authenticating is highly structured then in many cases it won't be exploitable because the final padding from the original message becomes part of the body of the extended message, as unparseable gibberish.
- thaidn 17y agoThe final padding is never parsed if we put set them as (part of) the value of an unknown key, i.e., setting a=pi_key....<pading>
- dfranke 17y agoI'm talking about exploitation of this vulnerability in general, not the specific case of Flickr. Not everything is a sequence of key-value pairs formatted in UTF-8.
- juli 17y agoAttacker controls the length of the message so he can make the padding be only 9 bytes long
- tptacek 17y agoMost of the crypto you're going to run across as a pentester will be in apps written in Java and C#, and in almost every one of those cases, garbage characters won't break a parse. ".split()" works just fine even if you have 16 characters of random high ASCII. It's one of those things C programmers definitely have to unlearn.
- dfranke 17y agoEeeeeeewwwww. If you're using .split() to "parse" untrusted input, and not even validating it against a regex first, that's an epic fail in its own right.
- tptacek 17y agoWhat a weird thing to say. You trust a regex engine more than you trust "split()"?
- dfranke 17y agoI trust a generated parser more than a hand-written one. Any parsing algorithm that involves the use of split() is almost certain to be weakly thought-out and have ill-defined behavior for unexpected input. A well-written parser will never read past the first unexpected character, or at least token.
- NateLawson 17y agoThis is equivalent to the old claim, "Since an attacker can only write a 0-byte somewhere in memory, this is a crash-only bug."