Re: CVE-2018-5407: new side-channel vulnerability on SMT/Hyper-Threading architectures

[Billy Brumley <bbrumley () gmail com>]

> However, I feel the blame might be misplaced here.  I think the
> existence of this side-channel in SMT should be obvious to the extent
> that it's not considered a vulnerability, but a fully expected by-design
> property.  Maybe the problem is it wasn't documented as such.  Maybe we
> should have put more effort into making it more obvious to everyone in
> 2005, like it's finally done now.

It's a fair comment.

I've been doing SCA a while now; L1 dcache timings (SMT), L1 icache
timings (SMT), remote timings, bug attacks, Flush+Reload, etc. Outside
of bug attacks (which are deterministic), this is the most
reproducible vector I've ever seen. I feel like that's one reason
holding back disabling SMT, because they are not trivial to reproduce.

If you have the setup I described:

https://github.com/bbbrumley/portsmash

Pull the code, follow the instructions. You'll see the signals we used
in the attack. No address dependencies, adapting to cache geometry,
etc -- it just works out of the box.

> Are you also releasing manuscript.pdf you had attached to your distros
> list posting?  You must be.

It's coming -- I promise. I submitted it as an IACR eprint yesterday
("Port Contention for Fun and Profit") -- currently under moderation,
but will eventually pop out here:

https://eprint.iacr.org/

(Side note: I have raised this issue several times with IACR. I can't
get a permalink from them until I submit and it clears the mod queue.
But I can't submit stuff that's still under embargo. It's a catch 22.
Ofc there are technical solutions from IACR side but they won't
address it. Share your opinion: @IACR_News current co-editor is
@Leptan.)

> I only skimmed it, but as I understand the OpenSSL code in question
> is branching upon a secret.  This is generally considered high-risk
> even without SMT.  While it'd be harder and less practical to exploit
> without SMT, the state of instruction cache changes in a way visible to
> other processes that might be scheduled to run on the same core.
> Perhaps it'd take orders of magnitude more observations since the OS
> scheduler won't kick in very frequently, but eventually the secret
> should be obtainable.

The code in question certainly had lots of SCA issues :) I was the
first to show it vulnerable with an L1 dcache SMT attack (ASIACRYPT
2009). OpenSSL didn't respond during disclosure. Side note:
openssl-security is so much better since HeartBleed. They're really on
top of things, and being GitHub-based now the code is constantly
improving. If you're reading, go contribute to the project!

If there's something good about a vulnerability being unpatched for
almost a decade: that code path sparked quite a lot of academic work
in microarchitecture attacks.

> I guess this commit is (part of?) the fix:
>
> https://github.com/openssl/openssl/commit/5d92b853f6b875ba8d1a1b51b305f14df5adb8aa

For the 1.1.0 branch, at

https://github.com/openssl/openssl/commits/OpenSSL_1_1_0-stable/crypto/ec/ec_mult.c

everything starting from aab7c770353b1dc4ba045938c8fb446dd1c4531e

> In there, we see a ladder of function calls separated by "||", which in
> C guarantees short-circuit evaluation.  This is data-dependent
> branching, and it remains such after that commit.  Being unfamiliar with
> ECC and with this code, I don't know whether the branching is (still) by
> secret or not (anymore).  I'd appreciate your comments on this.

Those branches are actually public; that is unofficial OpenSSL style
guide to avoid lots of if / else if / goto statements to detect return
errors from function calls.

> > Upgrade to OpenSSL 1.1.1 (or >= 1.1.0i if you are looking for patches)
>
> OpenSSL recently issued two security advisories suggesting a further
> upgrade to 1.1.1a or 1.1.0j, but then mentioning that "a new side
> channel attack was created" and listing commits with even further fixes
> (not releases):
...
> Timing vulnerability in ECDSA signature generation (CVE-2018-0735)
...
> Timing vulnerability in DSA signature generation (CVE-2018-0734)
...
> I don't know to what extent this is related or not.

These are unrelated, but you're certainly not the first to ask ;)

BBB