OpenSSH Gets Even More Suspicious

If you remotely administer any computers, or need to check your email over an untrusted network, odds are you're already familiar with the wonders of OpenSSH. Markus Friedl yesterday posted a release announcement for the newest version, OpenSSH 3.3. Privilege separation in OpenSSH is now enabled by default, another sign of the entire OpenBSD project's appropriate paranoia.

Comments

Re:Even OpenBSD developers can be vain...

[The_Final_Word]

upgrade to Apache 1.3.26 or 2.0.39, it's an Apache problem and it is on their home page.

http://httpd.apache.org/

The OpenBSD folks gave a patch for the OS before the new Apache binaries were released as a work around.

Re:No thanks

[kevinqtipreedy]

Trust old telnet works fine, unless you are worried about people seeing your passwords, and everything you are doing. That is the point of ssh; it encrypts what you do, including passwords so it can not be seen by people on the same network segment. Telnet send your password and everything you do right over the wire without encoding it at all. A difficult password is just as important on telnet as in is on ssh because they can still be cracked either way.

Re:Necessary and useful

[GreenHell]

Yes, portability is...

Of the 3 major BSD's, NetBSD's goal is to run on as many platforms as possible, FreeBSD's goal is to create a reliable, free UNIX (it may not meet your definition of free, but that's another story), and OpenBSD's goal is to provide the most secure distro possible.

Re:oxymoronic

[Anonymous Coward]

> Open Secure Shell? Is that like Passive Agression?

No, it's the opposite of Closed Secure Shell, any SS product that you must trust to be secure, because no one but the vendor can verify the sources.

It's actually *more* secure due to being open. No oxymoron at all.

Re:SSH is magnificent!

[p3d0]

Just remember to use the "blowfish" cypher for large files. It's much faster than the default 3DES.

I use: alias scp="scp -c blowfish-cbc".

Re:Uh...?

[PacoTaco]

Handling arbitrary data from the network as root is a bad thing. Basically, an attacker's exploits run at the same privilege level as the daemon they break in through. The new OpenSSH strategy uses a non-root user to do most of the work. That way, the attacker doesn't have immediate root access to your system if sshd is compromised.

Re:Uh...?

[LinuxGeek8]

I'm not into it that much too. But simply said it starts different processes.
The parent process starts with root priviliges, and the child processes handle the actual connections, and do not run with root priviliges.
For things like authentication the child communicates with the parent. Hmm, would that mean a new connection needs to authenticate itself twice then? (in 1 login) I assume so.
If the child gets corrupted, or someone tries to break in, he will not have the root priviliges of the parent process.

In previous ssh versions it was always running with root priviliges, even if you were logged in as user. So every exploit in openssh is immediately a remote root exploit.

This is sort of the same model that Apache has, one root parent, the rest runs as user www or whatever.
The same as postfix, the secure alternative for sendmail, which also runs only as root I believe).

Ettercap (was Re:Packet sniffing)

[Nonesuch]

Packet sniffing traffic that crosses your ISP and then the public Internet is definitely a serious and real risk.

PatJensen asks:
Is there a tool that allows you to force the switch to forward ethernet frames so they can be sniffed without switch administrator access?

There are tricks to force the switch to 'flood' ethernet frames (overflow the CAM table, etc). Two common attacks against switched segments are MAC spoofing (easily detected and protected against on Cisco) and ARP spoofing (more difficult to protect against).

There is also a tool to permit packet sniffing, see ettercap on Sourceforge.

Ettercap is a multipurpose sniffer/interceptor/logger for switched LAN. It supports active and passive dissection of many protocols (even ciphered ones) and includes many feature for network and host analysis.

Ettercap is actively being used by the "black hat" community, and has been found on compromised systems on switched LAN segments "in the wild".

What it does - Program, not Protocol Security

[billstewart]

This isn't a change to the communications protocols or any of the encryption - it's a change to the Unix implementation of the server to make it much less likely that any bugs can let someone break in. (Initially this works for OpenBSD, should be easy to port to other BSD implementations, probably to Linux and Solaris, maybe to WinNT but maybe not.) The basic way that a communications server like this works is

• A process sits around listening to the well-known TCP port for connection requests. The process needs to be privileged for two reasons
• The port is a system resource so only the system should be able to control it
• When a user logs in (on Unix), their connection needs to operate with the permissions of that user, so the server needs to be root so it can start a session as any user who logs in (as opposed to a Web Server, which usually only needs access to publicly readable files.

When a request comes in, it hands it to a subroutine that handles requests for the server to do different functions, including authentication.

For some services, such as SSH and FTP, the server may set up multiple connections for things like transferring files, etc.You can write a server like this as one big single-threaded process, or as one big process with multiple threads if your operating system and programming environment support it, but it's more common, especially on Unix, for the main process to spin off several child processes to do the work and go back to listening for new incoming requests. In this case, it spins of one process to handle the control channel communications and that process spins off other processes to handle specific tasks like file transfers, after checking that the connection and the request are authenticated. In a simple-minded implementation, the control channel process runs as root, and any task channel processes start off as root, and maybe change their privileges to an individual user's privileges if they need to (for instance if you're using SSH to log in to a remote system.)

The problem with this is that if there are any bugs that let a remote connection send messages with unexpected data in ways that break or take over the server process, the server is running as root so it can do anything it wants, however evil or dangerous (or if it's a minor bug that doesn't lead to a complete takeover, it may still be able to burn critical resources and stall the system or do some other denial of service attack.) Two popular kinds of attacks are sending a message that overflows a field (the result of bad protection in the C language combined with careless programming), or sending a message that asks the process to do something that the programmer didn't expect and protect against, such as setting permissions on a system file or making a user's program privileged, so that it can be exploited later, either by another communication from the attacker or by routine activities by the system or the user.

What the new OpenSSH implementation does is takes the bottom two server processes (the control channel server and the task servers) and splits each of them into two parts that communicate with each other. One part of each processes is a master, that keeps running privileged if it needs to, and the other is a slave process that runs as a non-privileged user (either the user who's requesting the service, for tasks like logins, or as the "nobody" user) and does most of the actual work, passing messages back and forth to the master process to communicate about status and request anything that still requires privileges. This gives you a bunch of security advantages:

• Each part of the system is smaller, with fewer functions to perform and well-defined interfaces to other parts, so you can do a better job of checking for bugs and each part can validate incoming messages before doing anything.
• The parts of the system that need to be privileged aren't communicating directly with the remote user, only with the slave processes, so they have a much smaller set of messages to validate.
• If there's some bug in the system that lets a remote attacker take over one of the control or task processes by sending an craftily designed message, the bug is in the non-privileged slave process, which doesn't run as root, can't do as much damage, and has a limited set of messages that the master process will accept from it.

The rest of it is basically detail about which functions they separated into which programs, how they made sure that each piece has enough capabilities to do the job without giving it too much power that could be exploited by an attacker, and some stuff about how they validated the pieces. It's adding more complexity to the total system, but each piece is more limited in function, and the security-critical pieces are much easier to validate against bugs and malicious input.

Re:SSH is magnificent!

[Sircus]

SCP runs over the standard SSH protocol (either SSH1 or SSH2). All SSH security features therefore apply to SCP.

128-bit AES/Rijndael is one of the "recommended" ciphers for SSH2, but is not supported by SSH1. 192 and 256 bit AES/Rijndael are "optional" for SSH2.

Re:SSH is magnificent!

[evilviper]

An alias is not the best idea.

Best thing to do, edit your ~/.ssh/config and stick your options in there (or machine-wide if you edit /etc/ssh/ssh_config).

So, enter something like:

host *
Compression no
Ciphers Blowfish-cbc,3des-cbc
Protocol 2,1


Additionally, use DSA/RSA auth, (NOT PASSWORD), and use ssh-agent so that you only need to enter your key's pass-phrase once in a while.

Anyone that uses SSH (and doesn't yet know about scp, port forwarding, ssh-agent, key-based auth & configuration like above) should buy the O'reilly SSH book.

Re:SSH is magnificent!

[rweir]

X Forwarding, SCP, FTPs
You think that's impressive? Have a look at the -D flag to OpenSSH >3.0: That's right, ssh can now run an encrypted forwarding SOCKS4 server!
Goddamn!

Re:There is a better way to fix one of these probl

[tigga]

Well, it's something like Network ACLs..

And it's done, for example in MicroBSD - http://www.microbsd.net

Garbage

[batdragon]

1. I'd rather have a 2n length key to encrypt an n length chunk, rather than an n-length key to encrypt a 2n length chunk.
   Helps spread the bits of "randomness" a little further. Why would you like it the other way around? Sounds insane.
2. What information have you found that proves blowfish is insecure? Links or your own cryptanalysis are welcome.
3. Anyone who wants some actual facts about blowfish should start here. I doubt if the AC who posted the parent will produce anything to refute the specs.

Re:There is a better way to fix one of these probl

[DavidTC]

The first solution would have made sense, except for the fact group ids are not that changable on production systems. There probably already is a group number 80. But it's a nice start, someday you'll invent ACLs. However your second suggestion is the silliest thing I've ever heard.

The problem is that ssh can change to any user it wants. That's the PROBLEM, that's the reason that bit was seperated out and away from the network traffic bit. It's not a solution.

Making it where the process id X (Where X is supposed to be sshd), can change to anyone else, is pretty much a negative solution to the problem, because now people can get root even after it's dropped privs. Not to mention now you cannot restart sshd if you need to, because it has to be pid X. And god help you when the kernel people come up with yet another 'fake' process that runs when the kernel starts, using no memory but taking up a pid.

And there is functionally no difference between being able to change to any user except root and being able to change to root. If you can change to the sysadmin's non-root account you can get root trivially by trojaning 'su', or, if he's very paranoid, by trojaning his shell.

Re:SSH is magnificent!

[evilviper]

But I only want blowfish for file transfers.

Well, you could set up seperate config entries like so:

host mercury-scp
hostname mercury.domain.com
cipher blowfish-cbc
Compression Yes

host mercury
hostname mercury.domain.com
Cipher 3des-cbc
Compression No

3des is better (I understand) for interactive shell sessions.

I not only don't agree, but I fail to even see any logic behind that. Blowfish is a quicker alogrithm any way you look at it... Myself, and many others, regard it as amply strong, very unlikely to be cracked (as DES was), etc. Perhaps you'd clarify why one form of encryption would be better than another for extremely similar uses.

What's wrong with an alias?

It's just not a clean way to do it. Perhaps if you use something like the TCL/TK frontend in the future, your alias will not work... I'm sure there are other situations where a shell alias won't work, so I say: why not just do it the proper way in the first place? Of course you can do *much* more with the ~/.ssh/config file. Or, you could make the change machine-wide by editing /etc/ssh/ssh_config.