You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2010/09/30 20:29:33 UTC

[jira] Commented: (MYFACES-2934) Side-channel timing attack in StateUtils class may still allow padding oracle attack

    [ https://issues.apache.org/jira/browse/MYFACES-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12916595#action_12916595 ] 

Leonardo Uribe commented on MYFACES-2934:
-----------------------------------------

I have checked it and well, the probability to be succesful using that type of attack is very, very, very, very, very low, because the comparison done in this case takes very few time compared with other tasks done by myfaces itself on a single request.

Anyway, I would like to know how to fix it, maybe replace the line "break" with "continue" should do the job. If that so, I can commit the code on all myfaces branches.


> Side-channel timing attack in StateUtils class may still allow padding oracle attack
> ------------------------------------------------------------------------------------
>
>                 Key: MYFACES-2934
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2934
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 1.2.9
>         Environment: All using MyFaces 1.2.9
>            Reporter: Kevin W. Wall
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> [FYI: I'm the person who fixed the padding oracle attack in ESAPI 2.0-rc# crypto which is why I spotted this.]
> I did a quick code inspection of encrypt() / decrypt() methods in org.apache.myfaces.shared_impl.util.StateUtils as it relates to the fix for MYFACES-2749.  Most everything is done correct (MAC is over IV+ciphertext and checked before decryption), but I noticed a subtle flaw that, at least in theory (or enough data gathering and statistical analysis), that opens a side-channel timing attack that might be still be used as a oracle in a padded oracle attack such as described by Duong and Rizzo.
> The problem is in the 'for' loop at lines 471-478 in StateUtils.java. You need to compare ALWAYS compare ALL the bytes in the MAC to ensure a timing side-channel attack cannot be used to as an oracle in the padding oracle attack.
> Contact me at kevin.w.wall@gmail.com if you need more info or want to see how it was fixed in OWASP ESAPI.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.