Mageia Bugzilla – Bug 20525
putty new security issue CVE-2017-6542
Last modified: 2017-03-27 23:28:13 CEST
openSUSE has issued an advisory today (March 19):
The issue is fixed upstream in 0.68.
Mageia 5 is also affected.
Assigning to the registered maintainer.
Hi! Updated in mgav6/cauldron thanks to Akien, and I submitted an update of putty-0.68-0mga5 to mageia 5 core/updates_testing. David, should I prepare an advisory?
Updated putty package fixes security vulnerability:
In PuTTY before 0.68, if SSH agent forwarding is enabled, local attackers that
are also able to connect to the UNIX domain socket could have overwritten heap
Updated packages in core/updates_testing:
Having a look at this on x86_64 hardware to start with.
I am stuck at the pre-update stage just now trying to test the PoC. It is not giving the expected result. Need to examine this further.
There is a proof of concept for CVE-2017-6542 at http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
The vulnerability sounds similar to one we came across in another bug in unrelated software.
In fact there are several vulnerabilities listed, some quite old, perhaps already fixed.
$ (echo -ne '\xFF\xFF\xFF\xFD\x0B'; cat /dev/zero) | socat stdio unix-connect:$SSH_AUTH_SOCK
On local machine:
2017/03/26 19:55:12 socat[25600.139765343241984] E write(5, 0x1702590, 8192): Broken pipe
On remote machine:
2017/03/26 19:56:11 socat[31119.140336665061120] E connect(5, AF=1 "<anon>", 2): SSH_AUTH_SOCK: Undefined variable.
From that I would deduce that the command should be run on the local machine, which has;
$ echo $SSH_AUTH_SOCK
It is expected that "PuTTY will crash". That is not apparent here because the remote session continues and can be terminated cleanly. The site quoted also says that
"This bug is only exploitable at all if you have enabled SSH agent forwarding".
My .ssh/config file has;
Don't know what to make of this - shall try that again after the update.
Updated from version 67.1 to 68.1.
Invoked putty and changed the client font to Andale Mono 12
In "Session" set the client name to belexeuli and opened it.
Presented with an xterm and a security notice. Logged in as
lcl and checked the home directory with ls.
Back on the server side:
$ (echo -ne '\xFF\xFF\xFF\xFD\x0B'; cat /dev/zero) | socat stdio
2017/03/26 21:05:59 socat[2799.140479512913664] E write(5, 0xd25590, 8192): Broken pipe
No difference there, so the functionality tests will have to do. Note that the man page
states that agent forwarding works for SSH-1 only just now and we use SSH-2 AFAIK.
Most parameters can be preset from the commandline:
$ putty -fn "Andale Mono 12" -l lcl -ssh
When the connection is opened the client asks for the user password immediately.
$ putty -fn "Andale Mono 12" -telnet
[ putty gui ]
At the connection attempt the xterm appears but there is also a popup message
"Connection refused", which I assume(!) originates on the client. A commandline telnet login
from the client succeeds. The client does not have a telnet daemon running but the
local machine has telnetd listed under services with the option "start when requested".
Toggling that makes no difference to anything and contact fails with
$ telnet <client>
telnet: connect to address <client>: Connection refused
But telnet in the other direction works fine; i.e. on the client
$ telnet <server>
produces a login prompt for the putty server machine on the client.
The problem here is telnet and my lack of knowledge of the protocol.
The same goes for rlogin.
$ putty -fn "Andale Mono 12" -rlogin -l lcl
[ putty gui ]
Unable to open connection to belexeuli:
Back on this tomorrow.
Rpmdrake or one of its priority dependencies needs to be updated first. Rpmdrake will then restart.
The following 2 packages are going to be installed:
4.7MB of additional disk space will be used.
4.5MB of packages will be retrieved.
Is it ok to continue?
$ uname -a
Linux localhost.localdomain 18.104.22.168-desktop-1.mga5 #1 SMP Sat Mar 18 18:54:15 UTC 2017 i686 i686 i686 GNU/Linux
I was able to putty into one of my servers after generating an ssh key.
It is working as designed.
@Brian re comment 7
Have you tried telnet or rlogin? ssh works fine here as well.
Those servers don't allow me to perform that. Let me see if I can do that with one of my local machines.
I'll see what configuration needs to happen on the host.
Installed rsh and rsh-server but could not get rsh to run. telnet now fails in both directions so there is no way it is going to work in putty.
Following Brian's lead and giving this the OK for x86_64 on the basis that it works for ssh.
Thanks to Len for heroic struggles & Brian for his comment 7.
Validating; advisory already in place.
An update for this issue has been pushed to the Mageia Updates repository.