Bug 23335 - libtomcrypt new security issues CVE-2018-0739 and CVE-2018-12437
Summary: libtomcrypt new security issues CVE-2018-0739 and CVE-2018-12437
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: has_procedure MGA6-32-OK MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2018-07-20 18:57 CEST by David Walser
Modified: 2018-08-15 17:46 CEST (History)
6 users (show)

See Also:
Source RPM: libtomcrypt-1.18.1-1.mga7.src.rpm
Status comment:


Description David Walser 2018-07-20 18:57:20 CEST
Fedora has issued an advisory on July 19:

The issues are fixed upstream in 1.18.2.

Mageia 5 and Mageia 6 are also affected.
David Walser 2018-07-20 18:57:39 CEST

Whiteboard: (none) => MGA6TOO

Comment 1 Marja Van Waes 2018-07-20 19:42:09 CEST
Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => dan

Comment 2 Dan Fandrich 2018-07-21 20:28:42 CEST
Updated to libtomcrypt-1.18.2-1.mga7.src.rpm in Cauldron.
David Walser 2018-07-21 20:37:02 CEST

Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)

Comment 3 Dan Fandrich 2018-07-21 23:26:43 CEST
libtomcrypt0-1.17-11.1.mga6 is now available for testing in updates/core_testing.

The test procedure for bug #17948 using Dropbear configured to use ECDSA host keys can be followed as a sanity check for this update.  Using this additional command will ensure that the server is using ECDSA host keys and therefore should be exercising the code patched for CVE-2018-12437:

ssh -v localhost true |& grep 'ECDSA host key' || echo 'Not properly tested'

It should print a line mentioning "ECDSA host key" and it should NOT say "
Not properly tested".

I don't have a procedure to test the second issue relating to ASN.1 parsing.

libtomcrypt has been updated to secure it against two security vulnerabilities.

An attacker capable of triggering signatures and mounting a side channel attack against a victim can extract an ECDSA key in a practical amount of time. This problem has been assigned the identifier CVE-2018-12437.

A problem in the ASN.1 parser could cause a stack overflow and a resulting denial of service when parsing deeply recursive ASN.1 types. This problem has been assigned the identifier CVE-2018-0739.

Updated packages:

Whiteboard: (none) => has_procedure
QA Contact: security => qa-bugs

Dan Fandrich 2018-07-21 23:28:37 CEST

CC: (none) => dan

David Walser 2018-07-22 01:46:38 CEST

Assignee: dan => qa-bugs
QA Contact: qa-bugs => security

Comment 4 Dan Fandrich 2018-07-22 02:14:58 CEST
Whoops—thanks for fixing the assignment.
Comment 5 Herman Viaene 2018-07-27 14:17:10 CEST
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues.
Getting a snag when trying to follow procedure:
$ ssh -F /dev/null -X localhost zenity --info --text=working
tester6@localhost's password: 
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Unable to init server: Could not connect: Connection refused

(zenity:16857): Gtk-WARNING **: cannot open display: 
there is nothing wrong apparently with ssh because:
$ ssh  localhost
tester6@localhost's password: 
[tester6@mach6 ~]$ exit
Connection to localhost closed.
Googled on the error, but no conclusive explanation found, this is not my usual territory.

CC: (none) => herman.viaene

Comment 6 Herman Viaene 2018-07-27 14:19:22 CEST
Before running the test I installed dropbear and
# systemctl -l status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:sshd(8)
# systemctl start dropbear
# systemctl -l status dropbear
● dropbear.service - Dropbear SSH Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/dropbear.service; enabled; vendor preset: enabled)
   Active: active (running) since vr 2018-07-27 13:48:37 CEST; 17s ago
  Process: 8376 ExecStart=/usr/sbin/dropbear $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 8380 (dropbear)
   CGroup: /system.slice/dropbear.service
           └─8380 /usr/sbin/dropbear

jul 27 13:48:37 mach6.hviaene.thuis systemd[1]: Starting Dropbear SSH Server Daemon...
jul 27 13:48:37 mach6.hviaene.thuis systemd[1]: dropbear.service: PID file /var/run/dropbear.pid not 
jul 27 13:48:37 mach6.hviaene.thuis systemd[1]: Started Dropbear SSH Server Daemon.
jul 27 13:48:37 mach6.hviaene.thuis dropbear[8380]: Running in background
Comment 7 Dan Fandrich 2018-07-27 14:47:49 CEST
I suspect it's an issue with X11 authentication, unrelated to this bug fix. The original test for bug #17948 was about X11 so it made more sense there. The important part of the test in this case is that host authentication with a ECDSA succeeds, so perhaps a better set of test command would be:

  ssh -F /dev/null -o StrictHostKeyChecking=no localhost echo probably working
  ssh -F /dev/null -o StrictHostKeyChecking=yes localhost echo really working

which should say "really working" after the second command. This is a good regression test for this bug only on hosts where the "ECDSA host key" command in comment #3 reports that the server is using ECDSA host keys (which I haven't actually verified myself yet because I haven't configured a host that way).
Comment 8 Herman Viaene 2018-07-27 15:15:08 CEST
TX Dan
$ ssh -F /dev/null -o StrictHostKeyChecking=no localhost echo probably working
tester6@localhost's password: 
probably working
$   ssh -F /dev/null -o StrictHostKeyChecking=yes localhost echo really working
tester6@localhost's password: 
really working
So, it really works.

Whiteboard: has_procedure => has_procedure MGA6-32-OK

Comment 9 Dan Fandrich 2018-07-27 16:22:01 CEST
What's the output of:

ssh -v localhost true |& grep 'host key'

on this host (ignoring any strings of hex or base64 digits)? If it doesn't say "ECDSA host key" then, unfortunately, it's not actually testing the changed code.
Comment 10 Herman Viaene 2018-07-28 17:37:38 CEST
$ ssh -v localhost true |& grep 'host key'
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
debug1: Server host key: ecdsa-sha2-nistp521 SHA256:klon/F1XVupOEP2RWnjXNDBBHlmozSWTdR06anymUbE
debug1: Host 'localhost' is known and matches the ECDSA host key.
Comment 11 Len Lawrence 2018-08-14 20:47:12 CEST
@Dan, re comments 8, 9 and 10.
Tried x86_64.
Before the update the commands given generated similar out put to Herman's including the "really works".

$ ssh -v localhost true |& grep 'host key'
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:/kp8SCjV0jmjwwgfWKqR9HURBqTEDzTvAOrvSErwAdk
debug1: Host 'localhost' is known and matches the ECDSA host key.

Is the "matches the ECDSA host key" what you expect to see?
If so I shall try the 64-bit update.

CC: (none) => tarazed25

Comment 12 Len Lawrence 2018-08-14 20:53:35 CEST
Went ahead and tried it anyway and noted the same results with the three commands.

OK for 64-bits

Whiteboard: has_procedure MGA6-32-OK => has_procedure MGA6-32-OK MGA6-64-OK

Comment 13 Dan Fandrich 2018-08-14 23:31:41 CEST
Yes, the log in comment #11 is as expected. I'll consider that tested.
Len Lawrence 2018-08-15 01:34:16 CEST

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2018-08-15 17:06:35 CEST

CC: (none) => tmb
Keywords: (none) => advisory

Comment 14 Mageia Robot 2018-08-15 17:46:45 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.