Re: [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto

[Tim <tim-security () sentinelchicken org>]

Hi Erik,

Thanks for backing me up on a number of things.  Only one response below.


> > In light of that, there's
> > nothing particularly wrong with using CBC, if it is implemented well.
> > At least, using it is not *more* wrong than using OFB, CFB, or CTR
>
> That is wrong. CBC mode allows attacks such as "Sweet32"
> (https://sweet32.info/), which is not possible with CTR mode.

The site you linked mentioned 64bit block ciphers are vulnerable, even
in CTR mode.  Obviously the birthday "paradox" applies. Regardless of
how right or wrong you are about Sweet32, this far from the most
important thing *implementors* should be worried about.  Obviously if
they start with AES, then the birthday paradox issues are vastly
reduced.  Any new system should be avoiding the likes of 3DES,
Blowfish, etc.  So it seems moot.


On the flip side, tell me what the impact is of these two scenarios
where a developer follows *some* of our advice:

(A) They use AES in CBC mode and apply an HMAC to the cipehrtext.
    They actually validate that HMAC before decrypting.  However, they
    fail to use a unique IV for every message.

(B) They use AES in CTR mode and apply an HMAC to the cipehrtext.
    They actually validate that HMAC before decrypting.  However, they
    fail to use a unique IV for every message.


Which is worse?  Obviously (B) fails pretty catastrophically.  (A) is
not great, but at least the plaintext isn't nearly as easy to expose
(usually only minor block-level information leaks).  In the real world
I see these kinds of mistakes all of the time.  So be careful of
steering people toward a mode that doesn't degrade as gracefully when
developers make mistakes.  They invariably will do so, unless they've
spent as much time with crypto as you and I.

tim


PS- And to re-iterate, we shouldn't ask them to use any particular
    cipher mode, but instead to use something off the shelf.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/