Arch Linux

There's also CVE-2016-2177, with some potential remote buffer over heap overflows:

https://github.com/openssl/openssl/commit/a004e72b95835136d3f1ea90517f706c24c03da7

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.

This fix will be included in the next upstream release.

@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 :)

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.

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.

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.

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.