This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of epel-7. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message.
Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. ===== # bugfix, security, enhancement, newpackage (required) type=security # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1591163,1591166 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False ====== Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new
In his original Technical Advisory Keegan Ryan states that "Side-channel attacks are explicitly excluded from Cryptlib's threat model." However, I contacted the creator of CryptLib, Peter Gutmann, for a statement about the impact of Keegan's findings. With his permission I'll post Peter's reply to me here as a comment. And close the bug. Here is Peter's reply : The cryptlib manual's comment on this is: -- Snip -- Cloud computing is fundamentally incompatible with secure crypto operations. If you’re running your crypto on someone else’s computer then you have no way of telling what they’re doing with your crypto or your keys. By extension if you’re running your crypto on a platform that’s shared with hostile processes that can access information like CPU statistics and cache information then you can’t guarantee the safety of your crypto keys. Although cryptlib employs countermeasures to try and reduce the threat, it’s not possible to guarantee the safety of your crypto or keys when they’re exposed on someone else’s hardware or to someone else’s software (the same applies to anyone else’s crypto in such an environment, at best you can try and obscure or hide your crypto operations and keys and hope that no-one figures out how to get at them). In other words if you’re running your crypto in a cloud or shared computing environment then your security guarantees are void. Similarly, if you allow someone to probe the system that you’re running cryptlib on with measuring equipment that can analyse internal electrical or similar signals then your security guarantees are void. As with the cloud/shared computing problem, this issue isn’t specific to cryptlib but affects all crypto implementations, no matter what their salespeople may tell you. The solution to these issues is simple, don’t run your sensitive crypto operations on systems controlled by others or that allow hostile code to run alongside, and attack, your crypto code, and don’t allow them to probe your systems with measuring equipment to capture its internal operations. -- Snip -- Or, as I told someone earlier today, this isn't a WONTFIX, this is a CANTFIX. If the attacker can run their code on the same CPU as you with access to hardware-level diagnostic capabilities, you're hosed. There's nothing you can do to defend against that, so the solution is "don't do that, then", not try and patch up every new vuln as it's published while thinking you're immune. This is a problem that cannot be fixed or patched, and we're realistic about it and tell the users that. (OK, that's not quite true, if you can write code that never ever exhibits any data-dependent behaviour, no branches, all operations take the same time, etc, then you're OK). If you're really worried about it, cryptlib's ECDSA is disabled by default and I don't know if anyone ever uses DSA, so at least it's mitigated that way, but the only actual solution is "don't do that, then", because if you do there'll always be further side channels there to get you no matter how many of them you try and patch up. Peter.