FS#49616 - [openssl] CVE-2016-2178

Attached to Project: Arch Linux
Opened by James Pic (is_null) - Wednesday, 08 June 2016, 09:44 GMT
Last edited by Levente Polyak (anthraxx) - Thursday, 22 September 2016, 18:10 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Pierre Schmitz (Pierre)
Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No



<<In this work we disclose
a vulnerability in OpenSSL, affecting all versions and
forks (e.g. LibreSSL and BoringSSL) since roughly October
2005, which renders the implementation of the DSA signature
scheme vulnerable to cache-based side-channel attacks.
Exploiting the software defect, we demonstrate the first published
cache-based key-recovery attack on these protocols:
260 SSH-2 handshakes to extract a 1024/160-bit DSA host
key from an OpenSSH server, and 580 TLS 1.2 handshakes
to extract a 2048/256-bit DSA key from an stunnel server.>>



This task depends upon

Closed by  Levente Polyak (anthraxx)
Thursday, 22 September 2016, 18:10 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in 1.0.2.i-1
Comment by Pascal Ernster (hardfalcon) - Thursday, 09 June 2016, 15:19 GMT
There's also CVE-2016-2177, with some potential remote buffer over heap overflows:

Comment by Pascal Ernster (hardfalcon) - Friday, 10 June 2016, 16:12 GMT
I've created updated PKGBUILDs for the openssl and lib32-openssl packages. These include both the fix for CVE-2016-2177 and the two fixes for CVE-2016-2178.
Comment by Pierre Schmitz (Pierre) - Tuesday, 14 June 2016, 11:29 GMT
This fix will be included in the next upstream release.
Comment by Levente Polyak (anthraxx) - Tuesday, 14 June 2016, 13:59 GMT
@Pierre: why not just backport them until the next release? I have a build and tested package ready that i could push to [testing] right now.
I've added those patches as local files instead of the proposed way (with clearer file-names). If there are no strong objections I would be happy to push them to [testing]. 0 work for you :)
Comment by Pascal Ernster (hardfalcon) - Tuesday, 14 June 2016, 14:22 GMT
FYI: I've been using the patched packages on several x86_64 machines (a desktop machine, a laptop and a server) since Friday, and I haven't noticed any crashes or other undesired behaviour.
Comment by Pierre Schmitz (Pierre) - Wednesday, 15 June 2016, 12:47 GMT
Do you know why upstream wont tag a new release? They are usually serious about security issues. It could be that this is either a non-issue or the fix might not be complete yet.
Comment by Levente Polyak (anthraxx) - Wednesday, 15 June 2016, 13:48 GMT
Good question:
well I wouldn't call this a non-issue :) CVE-2016-2178 is an exploitable side-channel attack, however in MITRE CVE score and openssl security policy its considered a low severity issue as its (most likely) hard to pull off and also requires adjacent network access. So the access complexity is quite high but the damage is still bad as it allows extracting secret data. this kind of issues don't automatically trigger an openssl release itself as it most likely can't be pulled off from any arbitrary remote client without adjacent network access.

CVE-2016-2177 is an integer overflow problem that has medium severity for both, MITRE (5.8/10) and also openssl. Normally such problems will be kept private and collected until the next release, its not clear why it was already public.

The openssl model itself only issues immediate releases when (according to their security model) there are critical or high severity issues. Why those two problems were not kept private, as they themselves recommend, is not really clear. Most of the time the moderate issues were either collected privately or found together with critical issues that triggered an immediate releases. This time nothing triggered such release yet but unfortunately those findings are publicly known beforehand.
Comment by Pascal Ernster (hardfalcon) - Wednesday, 15 June 2016, 15:55 GMT
I don't want to start a discussion about CVE scores, but please keep in mind that pulling off timing side channel attacks has become easier than it used to be. With more and more people using virtualized servers, it is not enough to only consider attackers with direct network access, but you also have to consider attackers owning another virtualized server on the same host machine, enabling them to leverage timing attacks onto the CPU pipeline or the CPU cache.