This bug was fixed in the package openssh - 1:7.3p1-1 --------------- openssh (1:7.3p1-1) unstable; urgency=medium
* New upstream release (http://www.openssh.com/txt/release-7.3): - SECURITY: sshd(8): Mitigate a potential denial-of-service attack against the system's crypt(3) function via sshd(8). An attacker could send very long passwords that would cause excessive CPU use in crypt(3). sshd(8) now refuses to accept password authentication requests of length greater than 1024 characters. - SECURITY: ssh(1), sshd(8): Fix observable timing weakness in the CBC padding oracle countermeasures. Note that CBC ciphers are disabled by default and only included for legacy compatibility. - SECURITY: ssh(1), sshd(8): Improve operation ordering of MAC verification for Encrypt-then-MAC (EtM) mode transport MAC algorithms to verify the MAC before decrypting any ciphertext. This removes the possibility of timing differences leaking facts about the plaintext, though no such leakage has been observed. - ssh(1): Add a ProxyJump option and corresponding -J command-line flag to allow simplified indirection through a one or more SSH bastions or "jump hosts". - ssh(1): Add an IdentityAgent option to allow specifying specific agent sockets instead of accepting one from the environment. - ssh(1): Allow ExitOnForwardFailure and ClearAllForwardings to be optionally overridden when using ssh -W. - ssh(1), sshd(8): Implement support for the IUTF8 terminal mode as per draft-sgtatham-secsh-iutf8-00 (closes: #337041, LP: #394570). - ssh(1), sshd(8): Add support for additional fixed Diffie-Hellman 2K, 4K and 8K groups from draft-ietf-curdle-ssh-kex-sha2-03. - ssh-keygen(1), ssh(1), sshd(8): Support SHA256 and SHA512 RSA signatures in certificates. - ssh(1): Add an Include directive for ssh_config(5) files (closes: #536031). - ssh(1): Permit UTF-8 characters in pre-authentication banners sent from the server. - ssh(1), sshd(8): Reduce the syslog level of some relatively common protocol events from LOG_CRIT. - sshd(8): Refuse AuthenticationMethods="" in configurations and accept AuthenticationMethods=any for the default behaviour of not requiring multiple authentication. - sshd(8): Remove obsolete and misleading "POSSIBLE BREAK-IN ATTEMPT!" message when forward and reverse DNS don't match. - ssh(1): Deduplicate LocalForward and RemoteForward entries to fix failures when both ExitOnForwardFailure and hostname canonicalisation are enabled. - sshd(8): Remove fallback from moduli to obsolete "primes" file that was deprecated in 2001 (LP: #1528251). - sshd_config(5): Correct description of UseDNS: it affects ssh hostname processing for authorized_keys, not known_hosts. - sshd(8): Send ClientAliveInterval pings when a time-based RekeyLimit is set; previously keepalive packets were not being sent. - sshd(8): Whitelist more architectures to enable the seccomp-bpf sandbox. - scp(1): Respect the local user's LC_CTYPE locale (closes: #396295). - Take character display widths into account for the progressmeter (closes: #407088). -- Colin Watson <[email protected]> Sun, 07 Aug 2016 22:45:26 +0100 ** Changed in: openssh (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/394570 Title: Backspace via SSH only deletes last byte of characters (no IUTF8 handling, requires standardisation work) Status in openssh package in Ubuntu: Fix Released Status in openssh package in Debian: Fix Released Bug description: Binary package hint: openssh-client This is not a terminal-related problem: regardless of the terminal used and the way the backspace key is supposed to behave (ASCII DEL, escape sequence, Control+H), what happens is that via SSH the backspace key only deletes the last byte of a character, not the whole character itself. You can notice this when you use UTF-8 characters that are encoded on more than 1 byte. Some diacritics from the Latin alphabet are encoded on 2 bytes, whereas some Japanese characters are encoded on 3. As an example, assume the following scenario: the letter "ș" is encoded as "c8 99" and endline is encoded as "0a": user@host:~$ cat > ș.txt ș ^d user@host:~$ hexdump -C ș.txt 00000000 c8 99 0a |...| 00000003 Now, assume you write "testș[hit backspace]test[endline]". On the physical host (i.e. without being SSH-ed into it), the hexdump of that file will be: user@host:~$ cat > test.txt testș[backspace]test ^d user@host:~$ hexdump -C test.txt 00000000 74 65 73 74 74 65 73 74 0a |testtest.| 00000009 whereas the *same* thing via SSH would lead you to having the following hexdump: user@host:~$ ssh user@localhost user@localhost's password: user@host:~$ cat > test.txt testș[backspace]test ^d user@host:~$ hexdump -C test.txt 00000000 74 65 73 74 c8 74 65 73 74 0a |test.test.| 0000000a So notice how backspace only deleted via SSH the last byte of "ș" i.e. only the "99" out of "c8 99"; compare the expected hexdump: 74 65 73 74 74 65 73 74 0a with the actual hexdump: 74 65 73 74 c8 74 65 73 74 0a locale is set to en_US.UTF-8; changing it to ro_RO.UTF-8 (both on the host and via SSH) yields the same results. Finally, last details: Ubuntu 9.04 Kernel 2.6.28-13-generic openssh-client: Installed: 1:5.1p1-5ubuntu1 openssh-server: Installed: 1:5.1p1-5ubuntu1 L.E.: I also tried the same thing using dropbear instead of OpenSSH. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/394570/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
