Upstream has issued an advisory today (January 26): https://www.openssl.org/news/secadv/20170126.txt The issues are fixed in 1.0.2k. Updated packages checked into Mageia 5 and Cauldron SVN. Freeze push requested.
(In reply to David Walser from comment #0) > Upstream has issued an advisory today (January 26): > https://www.openssl.org/news/secadv/20170126.txt > > The issues are fixed in 1.0.2k. > > Updated packages checked into Mageia 5 and Cauldron SVN. Freeze push > requested. Thanks, Akien just pushed the cauldron package. There is no registered maintainer, so assigning to all packagers collectively for someone to push it to 5/updates_testing, to write an advisory and to assign to QA team.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
Updated packages uploaded for Mageia 5 and Cauldron. Testing procedure: https://wiki.mageia.org/en/QA_procedure:Openssl Advisory: ======================== Updated openssl packages fix security vulnerabilities: There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure that handles input lengths divisible by, but longer than 256 bits. mong EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation (CVE-2016-7055). If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash. The crash can be triggered when using RC4-MD5, if it has not been disabled (CVE-2017-3731). There is a carry propagating bug in the x86_64 Montgomery squaring procedure. An attacker would need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients (CVE-2017-3732). References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7055 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3731 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3732 https://www.openssl.org/news/secadv/20170126.txt ======================== Updated packages in core/updates_testing: ======================== openssl-1.0.2k-1.mga5 libopenssl-engines1.0.0-1.0.2k-1.mga5 libopenssl1.0.0-1.0.2k-1.mga5 libopenssl-devel-1.0.2k-1.mga5 libopenssl-static-devel-1.0.2k-1.mga5 from openssl-1.0.2k-1.mga5.src.rpm
Whiteboard: (none) => has_procedureAssignee: pkg-bugs => qa-bugs
Debian has issued an advisory for this on January 27: https://www.debian.org/security/2017/dsa-3773
URL: (none) => https://lwn.net/Vulnerabilities/713043/
CC: (none) => davidwhodginsWhiteboard: has_procedure => has_procedure advisory
Checked the performance on a 64bit server before updating, following the procedure linked from comment 2. On-server tests all went well. Speed test from server to another machine on the LAN also worked fine. The server-to-remote speedtest also worked for a server on a 32-bit virtualbox. Updated on both x86_64 real hardware and i586 virtualbox and ran the same tests. Local 64-bit: $ openssl version -a OpenSSL 1.0.2k 26 Jan 2017 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB ....... OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic $ openssl ciphers -v .... lots .... including RC4-MD5 and ECDH* $ openssl ciphers -v -tls1 repeated the whole list, including TLSv1.2. $ openssl ciphers -v 'HIGH' Showed the whole list again, with 128 and 256 bit ciphers. $ openssl ciphers -v 'AES+HIGH' Same story, so these listing functions fail. Better to use '-v | grep' whatever. Unfortunately, these were not tested before updates, but there is still the 32-bit vbox. $ openssl speed This runs for a long time, allotting 3 or 10 second periods to every cipher. It hits a single core of a multicore cpu at any one time, switching every now and again. Local LAN connection: $ openssl s_time -connect belexeuli:443 No CIPHER specified Collecting connection statistics for 30 seconds ************************************************************************* 3913 connections in 1.34s; 2920.15 connections/user sec, bytes read 0 3913 connections in 31 real seconds, 0 bytes read per connection Now timing with session id reuse. starting rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr 6352 connections in 0.76s; 8357.89 connections/user sec, bytes read 0 6352 connections in 31 real seconds, 0 bytes read per connection $ openssl speed rsa ........................................... sign verify sign/s verify/s rsa 512 bits 0.000037s 0.000003s 27237.0 373983.3 rsa 1024 bits 0.000104s 0.000007s 9655.5 150421.4 rsa 2048 bits 0.000480s 0.000021s 2085.4 46927.4 rsa 4096 bits 0.005071s 0.000078s 197.2 12824.5 $ openssl speed rsa -multi 6 As the QA tests states, the initial information looks quite different. The core temperature shot up from 35°C to 61°C as well. Summary: sign verify sign/s verify/s rsa 512 bits 0.000009s 0.000001s 110717.6 1483333.3 rsa 1024 bits 0.000027s 0.000002s 37193.1 578282.8 rsa 2048 bits 0.000118s 0.000005s 8476.0 187171.9 rsa 4096 bits 0.001275s 0.000019s 784.0 52076.1 The man page is not very helpful regarding -v. It does not seem to be mentioned but it appears to be a command modifier meaning something like 'verbose output' or 'tabular listing'. Since the package functions OK can we just ignore the vagaries of the enquiry commands and pass this as OK for 64 bits?
CC: (none) => tarazed25
Testing on i586 in virtualbox $ openssl ciphers -v -tls1 Also returns the full list with version 1.0.2j, ignoring the -tls1 parameter. Updated the five packages. Listed the available ciphers. Ran the local speed test which returned times per operation in the milliseconds to submilliseconds range: e.g. op op/s 160 bit ecdh (secp160r1) 0.0002s 4237.5 192 bit ecdh (nistp192) 0.0003s 3134.0 224 bit ecdh (nistp224) 0.0004s 2367.5 256 bit ecdh (nistp256) 0.0005s 1840.4 384 bit ecdh (nistp384) 0.0013s 775.6 Since there is only one core on a virtual machine the multiple core speed test is not needed but it works anyway. Two processes are forked and share one core on the host machine. sign verify sign/s verify/s rsa 512 bits 0.000105s 0.000008s 9501.2 117647.1 rsa 1024 bits 0.000585s 0.000028s 1709.4 36363.6 rsa 2048 bits 0.003930s 0.000106s 254.5 9434.0 rsa 4096 bits 0.027897s 0.000397s 35.8 2518.9 The network test runs fine: $ openssl s_time -connect <ip address>:443 Tail end of output > rrrrrrrrrrrrrrr 5855 connections in 0.00s; inf connections/user sec, bytes read 0 5855 connections in 31 real seconds, 0 bytes read per connection Tried the simulated server approach using two terminals: console A > # openssl s_server -cert /etc/pki/tls/certs/httpd.pem -key /etc/pki/tls/private/httpd.pem -www Using default temp DH parameters ACCEPT console B > # openssl s_time -connect <ip address of vbox>:4433 -www / -new -ssl3 No CIPHER specified Collecting connection statistics for 30 seconds ERROR 3073255100:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40 The console B error was reflected in the console A output. Ports 443 and 4433 had been opened in Shorewall. As a last resort I disabled the firewall but that had no effect. $ systemctl status httpd.service showed that the apache webserver was running.
Following up the vbox failure with simulated server, tried setting up the server on real 64-bit hardware (belexeuli) @belexeuli: # openssl s_server -cert /etc/pki/tls/certs/httpd.pem -key /etc/pki/tls/private/httpd.pem -www Using default temp DH parameters ACCEPT In the 32bit vm (menkib) $ openssl s_time -connect belexeuli:4433 -www / -new -ssl3 results in > No CIPHER specified Collecting connection statistics for 30 seconds ERROR 3073660604:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:SSL alert number 40 and on the server end @belexeuli: 139770128979600:error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number:s3_srvr.c:960: ACCEPT It is still possible for menkib to collect statistics from belexeuli via port 443. Either I have a fundamental misunderstanding of the server <==> client connection or there really is something wrong with the software. The client "handshake failure" matches the server "wrong version number" message. The openssl packages have been updated at the server end. Or could this problem have something to do with the PEM certificate business?
SSLv3 is disabled for security reasons. Don't try to use it.
Thanks David. Maybe that should be added to the wiki. So this can be OK'd for both architectures.
Whiteboard: has_procedure advisory => has_procedure advisory MGA5-64-OK MGA5-32-OK
CC: (none) => sysadmin-bugsKeywords: (none) => validated_update
Having some doubts about validation. Does openssl have any alternative to sslv3? The POODLE vulnerability is mentioned on the web with hints that tlsv1.1 or tlsv1.2 could replace sslv3. Maybe the simulated server should be tried without encryption? Shall try that if it is possible.
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2017-0042.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Yep. That worked. Set up the server on a 32-bit virtualbox (menkib): # openssl s_server -cert /etc/pki/tls/certs/httpd.pem -key /etc/pki/tls/private/httpd.pem -no_ssl3 -www then on the 64-bit host: $ openssl s_time -connect menkib:4433 -www / -new No CIPHER specified Collecting connection statistics for 30 seconds .......................... 4264 connections in 2.22s; 1920.72 connections/user sec, bytes read 33497984 .......... Each connection triggers ACCEPT at the server end. So the validation is OK.