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

More suspicious of OpenSSH?

[jamus]

The way I read the headline, "OpenSSH Gets Even More Suspicious", it sounded like we're supposed to be more suspicious of OpenSSH.

What has the world come to, where we can't even trust OpenSSH?

Oh, OpenSSH is more suspicious of its environment! That makes more sense! :P

Re:More suspicious of OpenSSH?

[neuroticia]

I read that too and my mind quickly said to me "Oh great, time to turn off SSH and only allow shell access to people who physically sit down at the computer.

Then I realized that it's "suspicious" as in "the suspicious wife accused her husband of sneaking another computer into the house" and not "the actions of the husband were suspicious, leading his wife to accuse him of sneaking another computer into the house."

Should have said "Open SSH has just become even more paranoid."

THIS is why computers don't speak English. =]

-Sara

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:No thanks

[Admiral Burrito]

Telnet wins hands down. Just use a difficult password, and change it frequently.

Except telnet does zero encryption. It is a trivial matter to sniff passwords from an unencrypted link, and inserting data is not much harder. Changing passwords frequently is kind of pointless if you are setting your new password over an insecure link.

One-time passwords are better, but they are still vulnerable to TCP insertion attacks.

Yes, these things have been exploited in the wild. SSH exists for a reason.

If security problems in SSH itself worry you (and they should), privilidge-seperated ssh is the answer. By seperating the privilidged code from the code that talks to the client and defining a good interface between them, it limits the amount of stuff that can go wrong and the quantity of code that needs to be audited.

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".

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".

No thanks???

[Nonesuch]

kevinqtipreedy writes:

Trust old telnet works fine, unless you are worried about people seeing your passwords, and everything you are doing.

And you're not?

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.

That is one of the many points of SSH. The protocol also supports public-key authentication, so you don't need a "shared secret" (reusable password) at all. The protocol also provides authentication that you are really talking to the remote server you think you are, preventing MITM attacks (e.g. spoofing DNS so your telnet session goes through my server). SSH also offers compression, for faster file transfers. And port forwarding, including X11. and much more.

A difficult password is just as important on telnet as in is on ssh because they can still be cracked either way.

It is unlikely that anybody is going to bother cracking your telnet password- if they don't sniff it, then there are few scenarios where somebody has the ability to obtain the shadow file from a server but does not already have root.

One issue with password cracking and sniffing is that it is critical to have a unique password for every site you have accounts at.

Under SSH, I can set up systems so that password logins only work on the physical console, not over the network. I can create a strong private key (passphrase protected) and install my public key on the remote servers, using the same key for many different servers without the security issues that come from using the same password across disparate sites.

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:Necessary and useful

[Jeremi]

but how exactly do you define "free" in a way it doesn't match FreeBSDs license? The usual complaint from people favoring the GPL is that it's not Copyleft, so it's free even for people not interested in freedom for anyone but themselves

I think the GPL people would say that FreeBSD isn't Free in the "Free Willy" sense... GPL software cannot be captured back into proprietary software and made non-free again, whereas BSD licensed software can be (and often is). So while Linux code will always roam the wild plains, BSD code spends some of its time laboring in the Microsoft prison camps.... or something like that. :^)

Re:SSH is magnificent!

[demaria]

Thanks for the info. Something else cool, SSH with Tokens. I saw a demo at N+I on the commercial SSH 3.0 by SSH Communications. You need to have a token (such as an e-Aladdin USB eToken) plugged in during the entire session. If the token is removed, the shell instantly drops.

Re:Necessary and useful

[Jeremi]

Code that's already out there will always be free to "roam the wild plains" ... it can't be made non-free again. People can base non-free derivative products off it but that still doesn't "un-free" the original code...

Technically, you're correct, but in the larger view, there is a historical pattern where free code gets 'adopted' by a company, and the company adds lots of functionality to the free code, so that eventually the free code is no longer competitive, and everyone switches over to using the closed-source product. At that point, the code is no longer free (except for the "old" code which is no longer useful or used, and thus doesn't count). This is what happened to Unix in the 70's and 80's, leading to Unix's fragmentation and irrelevance as a platform. With GPL code, you don't have to worry so much about v2.0 coming out as closed-source, leaving you with a choice between staying with v1.0 or losing the benefits of open source.