[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFeDd5bLk0N4g3LP0FUgX+XH2QMaV+=d3ybagBE4K6pAHQAxHA@mail.gmail.com>
Date: Fri, 2 Nov 2018 16:42:33 +0200
From: Billy Brumley <bbrumley@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2018-5407: new side-channel vulnerability on
SMT/Hyper-Threading architectures
> 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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
