Bug 23335

Assigning to the registered maintainer.

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

Updated to libtomcrypt-1.18.2-1.mga7.src.rpm in Cauldron.

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.

Advisory:
========================
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:
========================
libtomcrypt0-1.17-11.1.mga6.i586.rpm
libtomcrypt-devel-1.17-11.1.mga6.i586.rpm
lib64tomcrypt0-1.17-11.1.mga6.x86_64.rpm
lib64tomcrypt-devel-1.17-11.1.mga6.x86_64.rpm

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

Whoops—thanks for fixing the assignment.

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
uitgelogd
Connection to localhost closed.
Googled on the error, but no conclusive explanation found, this is not my usual territory.

CC: (none) => herman.viaene

Forgot:
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)
           man:sshd_config(5)
# 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

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).

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

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.

$ 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.

@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.
Password: 

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

CC: (none) => tarazed25

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

Yes, the log in comment #11 is as expected. I'll consider that tested.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0339.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED