A CVE has been assigned for a timing attack issue fixed upstream in cryptopp: http://openwall.com/lists/oss-security/2016/04/11/2 The fix is in these two commits (first fixes security issue, second fixes performance regression in first fix): https://github.com/weidai11/cryptopp/commit/1700f440afe02952f6a6ce4087368c66a5034e3b https://github.com/weidai11/cryptopp/commit/50e5c14c18671726d23479b5e0cadc4224100259 Patch2 in the package has been superceded by the upstream commit: https://github.com/weidai11/cryptopp/commit/a0b078543abdfb5a508ff75dcd5865c4d6401085 from: https://github.com/weidai11/cryptopp/issues/82 but it doesn't apply cleanly to 5.6.3. Probably best to wait for 5.6.4 which incorporates all of these and should be out soon according to: https://github.com/weidai11/cryptopp/issues/146
Whiteboard: (none) => MGA5TOO
Assigning to all packagers collectively, since there is no maintainer for this package.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
Updated to 5.6.3 and synced patches with Fedora to fix this. Advisory: ======================== Updated libcryptopp packages fix security vulnerability: In libcryptopp, for both Rijndael::Enc::ProcessAndXorBlock and Rijndael::Dec::ProcessAndXorBlock there is some code to avoid timing attacks, however it is removed by the compiler due to optimizations, making the binary vulnerable to timing attacks (CVE-2016-3995). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3995 https://lists.fedoraproject.org/pipermail/package-announce/2016-April/182297.html ======================== Updated packages in core/updates_testing: ======================== libcryptopp6-5.6.3-1.mga5 libcryptopp-devel-5.6.3-1.mga5 libcryptopp-progs-5.6.3-1.mga5 from libcryptopp-5.6.3-1.mga5.src.rpm
URL: (none) => http://lwn.net/Vulnerabilities/683992/Version: Cauldron => 5Assignee: pkg-bugs => qa-bugsWhiteboard: MGA5TOO => (none)Severity: normal => critical
MGA55-32 on AcerD620 Xfce No installation issues. At CLI: # urpmq --whatrequires libcryptopp6 amule amule-commandline kodi kodi libcryptopp-devel libcryptopp-progs libcryptopp-progs libcryptopp-progs libcryptopp6 synergy I used synergy before, so tried this one, log of server in attachment. Tried a MGA5-64 as client with libcryptopp6-5.6.2 . Server runs OK but as soon as client tries to connect, synergy server stops.
CC: (none) => herman.viaene
Created attachment 7690 [details] start of synergy server
It doesn't seem to have loaded the library Herman, it does load libcrypto.so.1.0.0 but that belongs to openssl $ urpmf libcrypto.so.1.0.0 lib64openssl1.0.0:/usr/lib64/libcrypto.so.1.0.0 I suspect the issue with synergy is unrelated. You could try with cryptest from libcrptopp-utils $ urpmf libcryptopp-progs | grep bin libcryptopp-progs:/usr/bin/cryptest You will have to experiment to find how it's used. If it's too involved then it's enough to show no error loading the library when it's run under strace.
erm libcryptopp-progs, not libcrptopp-utils :\
Adding feedback marker. The -progs, which is essentially cryptest, looks for it's testdata and testvectors in /usr/share/cryptopp but they are packaged in /usr/share/libcryptopp. Also man page is missing. It makes it unusable. On the plus side though, once corrected, cryptest should be simple to use for testing. From the man page, "cryptest v" seems to run validation tests. $ man cryptest No manual entry for cryptest Should be one, see.. http://manpages.ubuntu.com/manpages/xenial/en/man1/cryptest.1.html $ cryptest CryptoPP::Exception caught: FileStore: error opening file for reading: /usr/share/cryptopp/TestData/usage.dat $ urpmf libcryptopp-progs | grep usage.dat libcryptopp-progs:/usr/share/libcryptopp/TestData/usage.dat $ cryptest --help Unrecognized command. Run "cryptest h" to obtain usage information. $ cryptest h CryptoPP::Exception caught: FileStore: error opening file for reading: /usr/share/cryptopp/TestData/usage.dat $ cryptest /usr/share/libcryptopp/TestData/usage.dat Unrecognized command. Run "cryptest h" to obtain usage information. $ cryptest h /usr/share/libcryptopp/TestData/usage.dat CryptoPP::Exception caught: FileStore: error opening file for reading: /usr/share/cryptopp/TestData/usage.dat $ cryptest tv /usr/share/libcryptopp/TestData/usage.dat CryptoPP::Exception caught: Can not open file /usr/share/cryptopp/TestVectors//usr/share/libcryptopp/TestData/usage.dat.txt for reading $ cryptest tv /usr/share/libcryptopp/TestData/usage.dat Using seed: 1461226385 CryptoPP::Exception caught: Can not open file /usr/share/cryptopp/TestVectors//usr/share/libcryptopp/TestData/usage.dat.txt for reading
Whiteboard: (none) => feedback
The synergy problem is AFAICS related to the libcryptopp versions. When I switch off encryption in both client and server, synergy works perfectly OK. So libcryptopp versions 5.6.3 and 5.6.2 do not seem to cooperate very well??? I tried my hand at amule, but I cann't get around it. Looking further into kodi (has also dependency on lincryptopp).
Paths to test files fixed. Man page for cryptest from Debian added. Updated packages in core/updates_testing: ======================== libcryptopp6-5.6.3-1.1.mga5 libcryptopp-devel-5.6.3-1.1.mga5 libcryptopp-progs-5.6.3-1.1.mga5 from libcryptopp-5.6.3-1.1.mga5.src.rpm
Whiteboard: feedback => (none)
Confirmed man page and tested with $ cryptest v | less One error remains at the end.. CryptoPP::Exception caught: Can not open file TestVectors/dsa.txt for reading It's odd as the rest complete OK, the file exists and permissions are consistent. Manually ran it with.. $ cryptest tv /usr/share/cryptopp/TestVectors/dsa.txt Using seed: 1461410708 Testing Signature algorithm DSA/SHA-1. ................................................................................................................ Testing Signature algorithm DSA/SHA-224. .... Testing Signature algorithm DSA/SHA-256. ........ Tests complete. Total tests = 124. Failed tests = 0. So I think this is sufficient for this update.
Whiteboard: (none) => has_procedure mga5-64-ok
Validating. Advisory uploaded.
Keywords: (none) => validated_updateWhiteboard: has_procedure mga5-64-ok => has_procedure advisory mga5-64-okCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0147.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
this update broke now amule :( see: https://bugs.mageia.org/show_bug.cgi?id=18272
CC: (none) => geiger.david68210