[Ma-linux] Two Sun Announcements

[Michael Stone]

On Tue, Feb 13, 2007 at 03:41:28PM -0500, jason wrote:
>If someone has compromised your box there are a variety of ways that ssh 
>still helps.  Use keys and no passwords get transferred.  

Instead the key is compromised. Not a win. Even worse, in a lot of ways.

>SSH will help dramatically if your switch gets compromised.  The majority 
>of cracking comes from inside.

And 80% of statistics are made up on the spot. That's a good example of 
a statistic that's been passed around as true without any critical 
review. If you research its origins you'll find that it has to do with 
numbers reported to the fbi (therefore inherently self-selected) more 
than a decade ago (essentially pre-internet). Again, be cautious of 
security based on "everyone says so".

>Why *not* use ssh?  What complexity does it add? 

If you don't know that, you probably shouldn't be making proclamations 
about what is secure and what isn't. (Some suggestions on things to 
review: the various authentication methods, how those methods interact 
with native authentication methods, the key exchange protocols, ssh 
services, channels, native vpns, etc. The protocol can do a lot more 
than most people realize; many of those things can also be done over a 
telnet session, but it's a lot easier to identify oddball use of a 
plaintext protocol than unauthorized use of legitimate facilities.) 
Truth be known, I'm actually fairly concerned about the ssh monoculture 
deployed on unix systems these days; the openssh team produces fairly 
decent code, but nobody is perfect. IIRC, most of the real bad ssh 
problems in the last few years were introduced after the code was forked 
by the openbsd team. (Lest I draw down the wrath of theo, I'll note that 
many [most?] of those were in the portable code [that most people use] 
rather than the openbsd code itself.)

>You say SSH makes it harder to monitor what's going on?  Well, if SSH adds 
>so little to security it should be easy enough to get around, right?  If 
>it's hard for you, the legitimate admin, to get around it'll make it 
>harder for the black-hat too.

That's simply a facile assertion; you're raising a straw-man argument 
about the security of ssh's encryption which is altogether unrelated to 
the points that I made. To illustrate that specific point, consider the 
possibility of a legitimate user on a compromised client logging in to a 
server with valid credentials. An intruder on the client could open a 
second ssh channel within the existing authenticated session and execute 
commands *without interfering with the user's session*. Can you explain 
how ssh, in that situation, has made things harder for both the admin 
*and* the "black-hat"? As far as monitoring that situation, you *might* 
be able to catch it if you have enough host-based monitoring on the 
server, and only if you catch it *before* the server is compromised. 
You've got essentially no chance of catching it on the network (there 
are actually ways to do it, but I've never seen a viable non-trivial 
deployment).

If you respond to what I wrote in a more critical fashion rather than 
dismissing it out of hand, we could have a more productive discussion.
Note that I didn't say "don't use ssh", I just said that it wasn't a 
magic bullet, and that security should be more carefully thought out 
than making fun of people for using telnet instead of ssh. There's a 
general tendency in this industry to focus on fairly narrow 
technological solutions that don't address a lot of the underlying 
problems we face in the real world. ssh is a good example of that--a lot 
of time and effort has been put into securing it from crypto attacks, 
but there's not a lot of evidence that weak encryption routines are a 
major problem in the wild. What is a real-world problem is that people 
tend to not understand the complexities of the software they're using, 
and say "yes" when asked about accepting a new host key. So you've got 
software that's very immune to cryptographic man in the middle attacks, 
but all that work is wasted if a bad guy gets a user to simply accept a 
new host key. In deploying complex solutions to problems we may not even 
have, we are simply pushing more and more of the security burden onto 
end users who frankly don't have an ability to make sense of all the 
things they have to do to keep their systems secure. There's been some 
work on different approaches--but there the ssh monoculture really bites 
because there's almost no interest in considering other approaches or 
other implementations--everyone already has ssh, and ssh fixes our 
problems, right? It's not like we're running telnet, right?

Mike Stone