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

SSH is magnificent!

[dmarien]

When I first started using linux, I was absolutely blown away by telnet, and the capabilities for remote administration.

Then came SSH... Not only is the grade of encryption absolute phenomenal, but the extras above and beyond remote shell's are astounding!

X Forwarding, SCP, FTPs, etc... they all rock! I can't remember the last time I coped a file over any protocol other than SSH's scp command. WinSCP has replaced puTTY as my favorite WIN32 application, and combined with puTTY and secure shells it's now wonder how I've managed to keep my home router/server up for 180 days w/o even having a monitor plugged into it!

Thanks OpenSSH team!

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.

Uh...?

[JanusFury]

For those of us without much experience in the encryption and networking fields, anyone mind explaining exactly what this does? I read the page but I'm not sure I understand exactly what's going on.

Re:um, inetd?

[PacoTaco]

It's totally different. If you run sshd from inetd, you are still processing network data as root. If someone finds a buffer overflow (or whatever) they can execute arbitrary code as root on your system. This strategy uses an unprivileged user to do most of the network data processing, with a privileged parent process for verification and authentication. At worst, a remote attacker could only get access as the unprivileged user.

Packet sniffing

[PatJensen]

Everyone says SSH is great, because your passwords and session information cannot be sniffed and I know that - but how important is it now? You cannot sniff packets on a switched network without SPAN access or port mirroring access on the switch itself. And over multiple switches, it is not trivial to gain access to do that since multiple access ports do not receive unicast frames. Unless you were the switch administrator of all the core and access switches I don't see this happening easily.

Is there a tool that allows you to force the switch to forward ethernet frames so they can be sniffed without switch administrator access? Please offer some information on how this is done as I'd like to have a better understanding on how this works. What platforms does the tool run on, and on what switch platforms would it work against?

-Pat (a CCNP and MCSE)

Re:Packet sniffing

[mlyle]

There are plenty of attacks that if you reside on the same virtual lan as one of the victims that allow you to intercept traffic.

One is sending traffic from the victim's mac address, so that the switch "learns" that MAC is out your port. Port security features on switches can help fix this but are oft-unused.

Another is ARP spoofing and using that to man-in-the-middle the session. You tell the person logging in that your MAC address is the victim host, and it cheerfully sends all packets to you. This is difficult to detect and prevent.

In conclusion: switches do not provide security against packet sniffing attacks.

Re:Packet sniffing

[nr]

You can sniff switched networks as the ARP querys are sent out to the broadcast address and received by all hosts on the segment, and then you send a fake ARP replie to that ARP query fooling the victim into beliving you are the real host. Poisoning the victims APR cache with your MAC address instead of the real destionation hosts MAC address.

There exists a sniffer tool called EtterTap that can do this automaticly for you.

Re:Packet sniffing

[mrmag00]

The correct conclusion would be "Any cheap switch does not provide security against packet sniffing attacks."

These things are nothing new, and cisco catalyst switches can be configured to prevent all of these. Of course, they come at a cost - about $1000 for bottom of the line.

Re:Ettercap (was Re:Packet sniffing)

[PatJensen]

Thanks for the informative response. Is there a place where I can read whitepapers on the viability of CAM overflows and MAC and ARP spoofing? Does Cisco have anything available that relates to this security? I'm aware of port security (only allowing certain MAC address to join a port) and VMPS (a centralized MAC database for VLANs, network wide).

Would either of these be helpful in prevent these types of attacks?

Thanks again.

-Pat

Re:More suspicious of OpenSSH?

[vsprintf]

Complete agreement. When I read the headline, there was a sudden pang of fear. If we had to close down SSH, there wouldn't be any more working-from-home Fridays. :)

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. :^)

There is a better way to fix one of these problems

[thogard]

You must be root to bind to any port <1024 as a form of "security" however this stupid rule has been the way in for most internet based security problems in the Unix world. Some systems (like Soalris) allow you to turn it off and that lets any process bind to any port but that has issues as well.

The correct solution is you let a process bind to any port >1024 and any port where the port number is in its group list. This means you put apache process owner in group 80 and 443 and then it can bind it its needed ports no matter who it runs as. Wiht the linux 2.0 kernal this required changing some of one line.

As far as the other problem of becoming someone else, there are no clean solutions to that but I think it would make sense to allow any process id 10 to become someone else. You also need to allow for some id's to give away files. The problem with this is that it intoduces magic numbers into the system which is bad.

Based in this, you could set up the ssh user as uid 1 in group 22 and it could bind to port 22 and then become any other user (or maybe any userid > 100). Bind would be running as user 53 with group 53 and have no special privs. The Apache user id would be in group 80 & 433 and its version of suexec would be uid 2 so it could change ownership to any user > 100 to run their cgis.