Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistencies in answers to RSA errors (possiby Bleichenbacher/ROBOT attack) #285

Closed
hannob opened this issue Sep 13, 2018 · 9 comments
Closed
Assignees

Comments

@hannob
Copy link

@hannob hannob commented Sep 13, 2018

Last year we published research that several TLS implementations were still vulnerable to the classic "Bleichenbacher" attack from 1998 and named it the ROBOT attack [1].

While analyzing several implementations we also figured out inconsistencies with haskell-tls, but as we couldn't really make sense of them we haven't analyzed them in more detail.

We observe that in some situations as a response to faulty RSA encryption packages a haskell tls server will answer with an internal server error instead of a bad_record_mac error. The behavior is inconsistent, so we're not sure this can be turned into a practical attack. Yet it's still definitely a bug and potentially a vulnerability.

This only happens with ciphers with AES256 and CBC mode. (Which is also why our detection script and many other detection tools that are based on it will not see it, as they often will just test with AES128.)

It was originally pointed out to us by Hubert Kario (he's the developer of tls-fuzzer, which will show errors if you run its bleichenbacher check [2] against a haskell tls server). Another tool that's capable of detecting the error is TLS-Attacker, which is by one of ROBOT's co-authors [3].

A test run would be something like this:
java -jar Attacks.jar -loglevel DEBUG bleichenbacher -connect [host] -cipher TLS_RSA_WITH_AES_256_CBC_SHA

[1] https://robotattack.org/
[2] https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-bleichenbacher-workaround.py
[3] https://github.com/RUB-NDS/TLS-Attacker

@hannob hannob changed the title haskell-tls inconsistencies in answers to RSA errors (possiby Bleichenbacher/ROBOT attack) Inconsistencies in answers to RSA errors (possiby Bleichenbacher/ROBOT attack) Sep 13, 2018
@kazu-yamamoto kazu-yamamoto self-assigned this Sep 14, 2018
@ocheron
Copy link
Contributor

@ocheron ocheron commented Oct 14, 2018

Thank you for the report @hannob.
@kazu-yamamoto Did you look at this?

@kazu-yamamoto
Copy link
Collaborator

@kazu-yamamoto kazu-yamamoto commented Oct 15, 2018

I want to learn this issue. But I don't know when I can take time.

@vdukhovni
Copy link
Collaborator

@vdukhovni vdukhovni commented Nov 2, 2018

The issue can be subtle, because not only must one not provide a signal to the attacker that the padding check failed, but these days one is also expected to do so in "constant time", that is there should also not be a timing side-channel that allows an adversary to determine whether the padding check succeeded or failed. This can be difficult.

@ocheron
Copy link
Contributor

@ocheron ocheron commented Nov 2, 2018

When I looked at this I did not see any issue directly related to RSA encryption.
Same behaviour is also shown in #289, consequence of the X448 issue.

Also, compared to the description, I reproduced the "internal_error" alert easily with AES128 too.

$ python scripts/test-bleichenbacher-workaround.py 'zero byte in random padding - TLS_RSA_WITH_AES_128_CBC_SHA'
zero byte in random padding - TLS_RSA_WITH_AES_128_CBC_SHA ...
[...]
AssertionError: Expected alert description "bad_record_mac" does not match received "internal_error"
@tomato42
Copy link

@tomato42 tomato42 commented Jan 25, 2019

did you consider automating those tests to prevent future regressions?

@ocheron
Copy link
Contributor

@ocheron ocheron commented Jan 26, 2019

Alas currently the test infrastructure never verifies alert codes raised.

@tomato42
Copy link

@tomato42 tomato42 commented Jan 26, 2019

And what is the reason for not using tlsfuzzer test to do that?

@kazu-yamamoto
Copy link
Collaborator

@kazu-yamamoto kazu-yamamoto commented Jan 26, 2019

I'm using trytls personally but not tlsfuzzer yet. See #299.
Yes, we should integrate them into test.

@tomato42
Copy link

@tomato42 tomato42 commented Jan 26, 2019

it seems to me like trytls is more focusing on configuration (is SSL3 enabled, is MD5 enabled, ...) and bugs in X.509 handling (are small keys rejected, ...) - while the former can be done with tlsfuzzer, the latter is explicitly out of scope for tlsfuzzer, so it looks to me like they are complementary not a replacement for each-other

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.