Bug 20525 - putty new security issue CVE-2017-6542
Summary: putty new security issue CVE-2017-6542
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: advisory mga5-32-ok MGA5-64-OK
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2017-03-19 16:15 CET by David Walser
Modified: 2017-03-27 23:28 CEST (History)
6 users (show)

See Also:
Source RPM: putty-0.67-1.mga6.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2017-03-19 16:15:32 CET
openSUSE has issued an advisory today (March 19):
https://lists.opensuse.org/opensuse-updates/2017-03/msg00055.html

The issue is fixed upstream in 0.68.

Mageia 5 is also affected.
Comment 1 Marja van Waes 2017-03-19 17:19:01 CET
Assigning to the registered maintainer.
Comment 2 Shlomi Fish 2017-03-19 20:45:39 CET
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?
Comment 3 David Walser 2017-03-19 20:55:12 CET
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
data (CVE-2017-6542).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6542
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-agent-fwd-overflow.html
http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
========================

Updated packages in core/updates_testing:
========================
putty-0.68-1.mga5

from putty-0.68-1.mga5.src.rpm
Comment 4 Len Lawrence 2017-03-26 21:15:23 CEST
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.
Comment 5 Len Lawrence 2017-03-26 21:48:29 CEST
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.
Poc:
$ (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
/run/user/1000/keyring/ssh

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;
Host *
ForwardX11 yes
ForwardAgent yes

Don't know what to make of this - shall try that again after the update.
Comment 6 Len Lawrence 2017-03-26 23:27:37 CEST
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
unix-connect:$SSH_AUTH_SOCK

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>
Trying <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:
Permission denied

Back on this tomorrow.
Comment 7 Brian Rockwell 2017-03-27 00:25:52 CEST

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:

- glibc-2.20-24.mga5.i586
- putty-0.68-1.mga5.i586

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 4.4.5.5-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.
Comment 8 Len Lawrence 2017-03-27 08:12:41 CEST
@Brian re comment 7
Have you tried telnet or rlogin?  ssh works fine here as well.
Comment 9 Brian Rockwell 2017-03-27 13:55:07 CEST
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.
Comment 10 Len Lawrence 2017-03-27 17:40:49 CEST
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.
Comment 11 Lewis Smith 2017-03-27 21:36:30 CEST
Thanks to Len for heroic struggles & Brian for his comment 7.
Validating; advisory already in place.
Comment 12 Mageia Robot 2017-03-27 23:28:13 CEST
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0093.html

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