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

padding oracle attack and lucky thirteen #7

Open
hannesm opened this Issue Mar 3, 2014 · 7 comments

Comments

2 participants
@hannesm
Member

hannesm commented Mar 3, 2014

problem: server leaks information if distinguishing between padding failure and mac failure

solution: don't ever send a padding failure alert

references

@hannesm

This comment has been minimized.

Member

hannesm commented Mar 12, 2014

to be slightly more precise, don't bail in crypto.ml:123 when padding is incorrect, but use a random premastersecret for further communication [which obviously will fail once enc/dec is used]. otherwise bleichenbacher's attack can be done.

@hannesm

This comment has been minimized.

Member

hannesm commented Mar 12, 2014

here's a first defense measure against bleichenbacher d83a5f0

@hannesm

This comment has been minimized.

Member

hannesm commented Mar 23, 2014

CBC decoding must be constant time... which is rather intricate, https://www.imperialviolet.org/2013/02/04/luckythirteen.html describes the countermeasures introduced by OpenSSL (and I believe we've to do it in a similar way)! the memory access pattern for invalid and valid padded data needs to be exactly the same...

@hannesm

This comment has been minimized.

Member

hannesm commented Apr 3, 2014

some further thoughts on this: we need to get rid of data-dependent branches and allocation -- or runs of the garbage collector. maybe we need to take the GC lock (do a gc minor before) and turn interrupts off to get rid of all the timing issues imposed by high-level runtime.

@hannesm

This comment has been minimized.

Member

hannesm commented Jul 7, 2014

see also discussion in #49

@eras

This comment has been minimized.

eras commented Dec 13, 2017

This kind of attack has been found to be relevant once again in other implementations: https://robotattack.org/

@hannesm

This comment has been minimized.

Member

hannesm commented Dec 13, 2017

@eras uhm, how is "robot" related to "lucky13"? IMHO "this kind of attack" isn't true.

AFAIU "robot" attack, this behaviour was fixed on 12th March 2014 (d83a5f0) which was before the initial release (0.1.0) of OCaml-TLS. The current code is still in the same shape https://github.com/mirleft/ocaml-tls/blob/0.8.0/lib/handshake_server.ml#L94 . Please take a look into #20 and #23 where we discussed and fixed this Bleichenbacher attack (again thanks to @gram for his code review back then).

This was also mentioned in our blog post announcing this library - https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitigation#Attacks-on-TLS and look for "Bleichenbacher". Please let me know if you've more questions about this (or a working attack). I'd prefer to discuss each attack in a separate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment