Package: putty / 0.67-3

Metadata

Package Version Patches format
putty 0.67-3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
pipe buf.patch | (download)

unix/uxshare.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 fix build failure on gnu/hurd

putty FTBFS on GNU/Hurd due to a missing definition of PIPE_BUF in
<limits.h>. This is solved by using the _POSIX_PIPE_BUF defined value
of 512 instead. (In fact the assertion will never happen, SALT_SIZE is
defined to 64 and PIPE_BUF is always larger than that, e.g. for Linux
4096, and so is _POSIX_PIPE_BUF.)

Bug-Debian: https://bugs.debian.org/805505
puttygen batch passphrase.patch | (download)

cmdgen.c | 149 99 + 50 - 0 !
doc/man-pg.but | 20 15 + 5 - 0 !
2 files changed, 114 insertions(+), 55 deletions(-)

 add command-line passphrase-file options to command-line puttygen.

Patch due to Colin Watson.

Putting the passphrase in a file avoids exposing it to 'ps' which can
print out every process's command line, while at the same time not
being as platform-specific as the approach of providing an fd number
(since cmdgen.c is in principle a potential cross-platform PuTTYgen,
not just a Unix one, which is why it's not in the 'unix' directory).

Of course it introduces its own risks if someone can read the file
from your disk after you delete it; probably the best approach to
avoiding this, if possible, is to point the option at a file on an
in-memory tmpfs type file system. Or better still, use bash-style
/dev/fd options such as

  puttygen --new-passphrase <(echo -n "my passphrase") [options]

Failing that, try a secure file-wipe utility, as the man page change
mentions.

(And a use case not to be overlooked, of course, is the one where you
actually want to generate an unprotected key - in which case, just
pass /dev/null as the filename.)

vuln agent fwd overflow.patch | (download)

ssh.c | 41 41 + 0 - 0 !
1 file changed, 41 insertions(+)

 sanity-check message length fields in chan_agent input.

Fixes 'vuln-agent-fwd-overflow': a hostile agent-forwarding client
sending a length such as 0xFFFFFFFD can cause c->u.a.totallen to end
up less than c->u.a.lensofar, leading to an attacker-controlled heap
overwrite when those two values are subtracted and used as a bound for
the amount of data to memcpy into the buffer.

Of course the mitigating factor is that if there is any such thing as
a 'hostile agent-forwarding client' in your world then you're likely
to _already_ be in fairly serious trouble - they can make free use of
all the keys stored in your agent, and would surely prefer to do that
than tip their hand by crashing your SSH client.

This is just the sort of thing I should have spotted in one of my past
general tightening-up passes such as commit 896bb7c74, but apparently
didn't :-(

Bug-Debian: https://bugs.debian.org/857642