Is PuTTY software banned!!?
Is PuTTY software banned!!?
Share on-
Evernote Pocket Buffer
Is the famous free and open-source terminal emulator (serial
console and remote access) application PuTTY has been banned? Which is used
everywhere from accessing router, switch, AP, Linux to cloud virtual devices
etc.
Though it was written for Microsoft Windows, but later it is
ported for others OS. PuTTY (Public Encryption + Teletype) which implements the
client end of the session works by sending typed commands and receiving text
responses over a TCP/IP socket like a traditional terminal. The client and
server establish a session with same encryption key by a calculation.
On Windows PuTTY stores most of data in the location-'HKEY_CURRENT_USER\Software\SimonTatham\PuTTY' of
the registry. It requires a random number of seed files, to improve the
unpredictability of randomly chosen data needed as part of the SSH
cryptography. PuTTY leaves some Registry entries, and a random seed file, on
the PC which should be cleared. It can be done by the command- putty
–cleanup.
PuTTY uses secure socket (SSH) with public key encryption wrapping
the packet payloads. It has official ports (Unix-type platforms) and unofficial
ports (Symbian, Windows) and it is bundled with command-line clients- PSCP,
PSFTP & plink.
PuTTY have several components- PuTTY, PSCP (‘PuTTY Secure
Copy’ which is a SCP client), Pageant (SSH authentication agent), PuTTYgen
(which generates RSA, DSA, ECDSA, EdGSA key), pterm (standalone terminal
emulator).
PuTTY use alternate chipper (3DES, Arcfour, Blowfish, DES). It can
emulate control sequences from xterm, VT102 or ECMA-48 terminal emulation, and
allows local, remote, or dynamic port forwarding with SSH. It uses host key
checking to ensure encryption of data at the client end and the server end are same. To
connect using SSH-2 to a server that supports both versions, you need to change
the configuration from the default.
PuTTY automatically initiate repeat key
exchange once per hour, to improve session security. If the client or server
machine is slow, it may be experienced this as a delay of anything up to thirty
seconds. They are inconvenient, but for protection. If really cause problem,
periodic rekeying can be turned off using the ‘Kex’ configuration panel; but it
is risky.
In the SSH version 2.3.0 and below, the SSH-2 server constructs Message
Authentication Codes (MACs) in wrong way and expects the client to
construct them in the same wrong way. PuTTY constructs the MACs correctly by
default, and hence these old servers will fail to work with it. But from
version 0.52 or later, PuTTY detect the buggy servers from their version number
announcement, and automatically start to construct its MACs in the same
incorrect manner as they do, hence it will be able to work with them. So, the 'Incorrect MAC
received on packet' message is not shown.
In the session establishment process between client and server, if
they got different encryption key, the data encrypted by one and decrypted by
the other looks like random garbage. If the decryption has failed, PuTTY will
see a completely random length of SSH message in the region of 2 gigabytes
and will try to allocate enough memory to store this. Hence ‘out of memory’ error occurs.
It doesn't necessarily mean that it actually run out of memory. Also, for some
setup problem if login scripts generate output during the non-interactive sessions,
PSCP or PSFTP receive this while they are expecting to see the start of a FTP.
They attempt to interpret the output as FTP and hence an ‘out of memory’ error
occurs. For the same reason a fatal protocol error occurs because PSCP was
expecting to see data from the server that was part of the PSCP protocol
exchange, and instead it saw data that it couldn't make any sense of at all.
We need to know an application’s expected sequence because PuTTY
responds to pressed function key by sending a sequence of control characters to
the server. If a function key isn't doing as expected, it's likely that the
application’s expected character sequence to receive is not the same as the one
PuTTY is sending.
During an interactive session, PuTTY receives a stream of 8-bit
bytes from the server, and in order to display them on the screen it needs to
know the character set to interpret them in. Now from RHEL 8.0, it
appears to have made UTF-8 as the default character set.
There is no way for PuTTY to know this. So, while connecting to RHEL 8.0, some
characters don’t display properly. To resolve this, we may configure
sessions to RHEL8 systems to use UTF-8 translation.
PuTTY's terminal emulator has always had the policy that when the
‘alternate screen’ is in use, nothing is added to the
scrollback. This is because the usual sorts of programs which use the alternate
screen such as text editors, which tend to scroll back and forth in the same
document a lot; so they would fill up the scrollback with a large amount of
unhelpfully disordered text, and they contain their own method for the user to scroll
back to the bit they were interested in. We have generally found this policy to
do the Right Thing in almost all situations.
Some firewalls and any router doing Network Address
Translation (NAT), forgets about a connection through them if it remains
inactive for long time. This will cut off the connection when contact is
resumed. But if configured PuTTY sends keepalive messages, they reassure
the router or firewall that the network connection is still active and worth
remembering about.
From version 0.52 PuTTY has proper support for local echo. It
automatically determines whether to enable local echo and local line
editing based on protocol and server hints.
Well this is like a nightmare if PuTTY banned. But be tension-free and don’t worry
because this is not going to be happened. Putting others competitor behind
PuTTY will remain the leader.
PuTTY have received updates
fixing multiple vulnerabilities. Eight vulnerabilities have been fixed in
version 0.71 of PuTTY, and nine vulnerabilities fixed in version 1.8.1 of
LibSSH2.
In PuTTY 3 out of 8 vulnerabilities allow
DoS attacks. They are, if a CJK wide character is written to a 1-column
terminal; combining characters, double-width text, odd number of terminal
columns and GTK; and if many Unicode combining characters are written to the
terminal.
The fourth vulnerability is if a malicious
server allows PuTTY to log in without authentication, but then sends a
simulated PuTTY text, PuTTY would be prompted to send back the user's private
key phrase. It has been solved by employing new strategies to determine between
genuine and fake authentication prompts rather than altering the basic code.
The fifth vulnerability is if an attacker
get the putty.chm file into the directory from which PuTTY is
running, PuTTY assumes it is the genuine help file and feed it
to htmlhelp.exe. The .chm file can be used to run
separate code. This has been fixed by changing the way in which PuTTY tools
find their help file.
The sixth vulnerability is a buffer
overflow in Unix PuTTY for too many port forwardings. PuTTY monitors the
activity by putting file descriptors into a variable with no bounds-check ,
thus leaving it vulnerable to buffer overflow because this could be remotely
triggered by a malicious SSH server. This has been fixed by switching all PuTTY
tools to monitoring file descriptors using poll-2, which does not include the
API bug.
The seventh vulnerability was the ability
of PuTTY to occasionally generate repeat random numbers, caused by a one-byte
buffer overflow in the random pool code. If the position index could be decreased,
the previously output random numbers could be accidentally recycled. This has
been solved by replacing the RNG completely with one based on Schneier and
Ferguson's "Fortuna" design.
The eighth vulnerability result in an
integer overflow due to a missing key-size check in the RSA key exchange code.
If it is exploited by a man-in-the-middle attack, the result could be uncontrolled overwriting of memory. It has
been solved by enforcing the minimum key lengths specified in RFC 4432.
Each of the vulnerabilities has been
assigned a Common Vulnerabilities and
Exposures (CVE) number-
CVE-2019-3855: A specially crafted packet could result
in the overflow which could be used to allocate memory for a write out of
bounds error. This has been fixed by ensuring the packet length value is within
correct limits.
CVE-2019-3863: A server could send multiple keyboard
interactive responses with a total length greater than unsigned max characters.
The value could be used as an index to copy memory causing an out of bounds
memory write error. This has been fixed by ensuring the memory index and the
length of the response will fit into the buffer before copying the value and
incrementing the index value.
CVE-2019-3856: It is an integer overflow in the keyboard
interactive handling. The value could be used to allocate memory causing a
memory write out of bounds. It has been fixed by ensuring the keyboard prompt
requests value is less than 100 before proceeding with the login process.
CVE-2019-3861 involves out-of-bounds reads caused
by specially crafted packets with a padding length value greater than the
packet length- which could result in a buffer read out of bounds, or a
corrupted packet value. This has been fixed by ensuring the length of the
packet padding is less than the packet size minus 1.
CVE-2019-3857 is an integer overflow leading to a
zero-byte allocation and out-of-bounds write caused by a server sending an SSH_MSG_CHANNEL_REQUEST with
an exit signal message. This is fixed by ensuring the length of the message
fits UINT_MAX before allocating memory.
CVE-2019-3862 is an out-of-bounds memory
comparison caused by a specially crafted SSH_MSG_CHANNEL_REQUEST packet
with an exit status message and no payload. It has been fixed by ensuring the
length of the packet is greater or equal to the value being compared before
calling memcmp().
CVE-2019-3858 is a possible zero-byte allocation
leading to an out-of-bounds read caused by a specially crafted partial SFTP
packet with a zero value for the payload length. This has been fixed by
ensuring the length of the payload is not zero before proceeding.
CVE-2019-3860 involves out-of-bounds reads caused
by specially crafted partial SFTP packets with empty payloads in response to
various SFTP commands. This has been fixed by ensuring the length of the
payload is the required length before reading the packet buffer content.
CVE-2019-3859 involves possible out-of-bounds
reads caused by specially crafted payloads and the unchecked use of _libssh2_packet_require and _libssh2_packet_requirev.
This has been fixed by ensuring that the length of the payload is the required
length before reading the packet buffer content.
Well thanks for reading this article.
Please give your valuable comments. If find this helpful, please share this.
