7 ms·
OpenSSH 7.0 released
- ams6110 11y agoOpenSSH 6.8 and 6.9 incorrectly set TTYs to be world-writable. Local attackers may be able to write arbitrary messages to logged-in users That seems like a pretty significant "oops" to have gone unnoticed for two releases?
- mnw21cam 11y agoIt's not that big a deal. Try "man mesg", which works by fiddling with the world-write bit on your TTY. All that an attacker can do write text to a victim's terminal (and mess up said terminal using interesting escape codes).
- deleted 11y ago[deleted]
- wslh 11y ago> All that an attacker can do write text to a victim's terminal (and mess up said terminal using interesting escape codes). I remember exploiting this issue more than a decade ago: http://seclists.org/bugtraq/1999/Sep/432 http://seclists.org/bugtraq/1999/Sep/432
- schoen 11y agoI wonder if there are attacks where you can alter the state of an idle user's terminal (based on what process you see that terminal has running) to trick the user into taking an inappropriate action when the user returns to the terminal. (There's certainly generic social engineering, but I'm wondering more about counterfeiting a situation that could really exist so that even a knowledgeable and skeptical user could be fooled.)
- derefr 11y agoBasically, tab-napping[1] for TTYs. [1] http://www.azarask.in/blog/post/a-new-type-of-phishing-attack/ http://www.azarask.in/blog/post/a-new-type-of-phishing-attac...
- cxseven 11y agolike wslh said, more can be done. I seem to recall that characters can be bounced into the tty's input.
- unhammer 11y agolike https://github.com/dellis23/disrupt https://github.com/dellis23/disrupt ?
- cxseven 11y agoThis is what I was remembering: http://www.securityfocus.com/bid/6940/discuss http://www.securityfocus.com/bid/6940/discuss There was (and might still be) an escape sequence that allowed setting the xterm title, and another sequence that caused that title to be sent to the terminal AS INPUT! I'd imagine this latter control sequence was eliminated.
- mike-cardwell 11y agoThis doesn't seem like a particularly interesting release. A few fixes. A few defaults changed. Am I missing something?
- rockdoe 11y ago* Support for the 1024-bit diffie-hellman-group1-sha1 key exchange is disabled by default at run-time. It may be re-enabled using the instructions at http://www.openssh.com/legacy.html http://www.openssh.com/legacy.html * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by default at run-time. These may be re-enabled using the instructions at http://www.openssh.com/legacy.html http://www.openssh.com/legacy.html
- s_dev 11y agoI understand that no piece of software is ever finished but I think OpenSSH serves its purpose very well and isn't the kind of software that is worth adding experimental features that would change its scope/purpose and therefore releases tend towards bug fixes and security patches and in this sense makes it kind of "finished" as much as I hate saying it like that. An important aspect of unix philosophy is one tool does one job very well.
- mike-cardwell 11y agoI agree. I'm just trying to figure out what prompted this to be posted here? I assumed there would be something particularly interesting about this release, but I can't see it...
- s_dev 11y agoI suppose such a large number of people here would be absolutely dependant on OpenSSH so any kind change or update is news to them. As well the 7.0 version number makes for a lovely even number and catching headline.
- joshbaptiste 11y ago
- nandhp 11y ago> Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled by default at run-time I guess I upgraded to an RSA key "just in time", though obviously far later than I apparently should have.
- cmrx64 11y agoMight as well upgrade to a ed25519 key while you're at it :) Smaller and faster!
- deleted 11y ago[deleted]
- nailer 11y agoLooks like http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx http://blogs.msdn.com/b/powershell/archive/2015/06/03/lookin... didn't make it into this release.
- jamiesonbecker 11y agoExcellent release. OpenSSH + Userify = authtopia Summary + New default: PermitRootLogin prohibit-password, which also prohibits all interactive login forms. + DSS keys are finally disabled by default + Use at least 2048 bits for your RSA keys + Deprecating or disabling MD5, SHA1, Blowfish CBC, ARC4, and a few other older ciphers/hmac's. + Bug and vuln fixes
- bonzini 11y ago> Use at least 2048 bits for your RSA keys It says they only plan on "refusing all RSA keys smaller than 1024 bits" (e.g. 768 bits. > Deprecating or disabling SHA1 SSH1, not SHA1!
- jamiesonbecker 11y agoat least 2048 bits yeah, I added that .. 2048 is really minimum best practice these days ;) SSH1, not SHA1! Good point, edited - btw next paragraph also says disabling 1024 bit diffie-hellman-group1-sha1 key exchange.
- xorcist 11y ago> Userify Which turns out to be a Cloud solution that promises "root privileges with just one mouse click" across all my servers. What could possibly go wrong?
- nadams 11y agoWhat I would like is an open source/self hosted solution where if I login as root to a system I would get a pop-up or message asking to verify this. Obviously for the individual sys admins it may not be useful - but for a company it makes sense. Personally I just want it as a sanity security check. I could probably easily write it - just haven't had a chance to do it.
- jamiesonbecker 11y agoFWIW, don't login as root or su to root. Force yourself to always have to type in sudo. That half second is a good sanity check on whatever you're about to do. Plus, figuring out how to do crazy pipe things or here-docs as root is part of the fun :)
- WizzleKake 11y agoSeveral ciphers will be disabled by default [in the next release]: blowfish-cbc, cast128-cbc, all arcfour variants and the rijndael-cbc aliases for AES. I still use arcfour; it seems to be the fastest when using scp or rsync (rsync -e 'ssh -c arcfour') for copying large files. I hope the OpenSSH package manager for my distribution keeps arcfour enabled for this reason.
- cesarb 11y agoRC4 (arcfour) should not be used, because it's broken. It has biases in its output (which is XOR-ed with the plaintext), which given enough cyphertext allows one to recover the plaintext (see http://www.rc4nomore.com/ http://www.rc4nomore.com/ for the most recent result). OpenSSH since the 6.5 release (http://www.openssh.com/txt/release-6.5 http://www.openssh.com/txt/release-6.5) has a better alternative, ChaCha20. It's even faster than RC4, and has no known weaknesses AFAIK. Some more information: https://security.stackexchange.com/questions/46812/what-does-chacha20-poly1305openssh-com-mean-for-me https://security.stackexchange.com/questions/46812/what-does...
- Scaevolus 11y agoChaCha20 is slower than RC4 in my testing (176MB/s vs 213MB/s). Since I have AESNI and PCMLMUL, aes128-gcm is the fastest-- 430MB/s. $ for c in $(ssh -Q cipher); do echo $c; dd if=/dev/zero bs=1M count=8K | ssh -o Compression=no -c $c localhost dd of=/dev/null 2>/dev/null; done
- thebeardisred 11y agoExcited for this. Now we just need an RSA implementation for OpenSSH which doesn't require OpenSSL for the RSA.
- yellowapple 11y agoI'd imagine that OpenSSH is likely designed around using libressl for that, no?
- sshuser2 11y agoI bet Linux distros will have this in a day or two, while most BSDs will have to wait months or years to get OpenSSH 7.0.