Remote Root Exploit In lsh

Ha-Ha by Anonymous Coward · 2003-09-20 18:20 · Score: 4, Insightful

I find it entertaining that the GNU zealot hippies suggest lsh as a replacement. That's like suggesting that the HURD is a replacement for the Linux kernel. Always trying to one-up the *BSD people by making something "more free", but never living up to the hype.

BTW, *who* uses lsh????

That's it by Anonymous Coward · 2003-09-20 18:24 · Score: 5, Funny

I am switching to a vendor, who takes security seriously. Enough of this patching crap.

That is it I quit by Anonymous Coward · 2003-09-20 18:24 · Score: 5, Funny

Between MS worms, SSH, and this I am throwing down my keyboard...

Oh wait is that a new slashdot article?

I might be able to get first post...

Can someone explain to me why.. by Anonymous Coward · 2003-09-20 18:25 · Score: 4, Insightful

We have a GNU ordained version of the SSH protocols when OpenSSH is doing a fantastic job?

Even if you are going to argue the BSD vs. GPL license issue, the lsh devs could have just taken the OpenSSH code, made some slight changes, and re-released it under the GPL.

So again I ask: Why?

Re:Can someone explain to me why.. by lcs · 2003-09-20 19:30 · Score: 5, Informative

I, like the author of lsh, is a member of the same
computer society, Lysator, and I happen to remember
reading about the early lsh developments.

It was started in August 1998, and that's as far
as I know, several months if not years before
OpenSSH was started.

Telnet by Henry+V+.009 · 2003-09-20 18:28 · Score: 4, Insightful

I was going to repeat "switch to Telnet joke" that I made last time, but I just can't get up will this time. These bugs are killing us. I seriously think that we need to take some time to consider how Open Source projects do security. The "more eyes" mantra doesn't cut it. We need security models, standards, testing, and god knows what else. We need to look at which projects have been successful, and which have been miserable security failures. I know the open source community can do a lot better.

Re:Telnet by runderwo · 2003-09-20 18:38 · Score: 4, Informative

I seriously think that we need to take some time to consider how Open Source projects do security. The "more eyes" mantra doesn't cut it.
Um, how do you think this problem was spotted? Read the mailing list post. There was a pair of eyes that found the bug, and he subsequently posted to the list.
In addition, a fix was checked in within four hours. 14 hours later, exploit code was posted to SecurityFocus, in the afternoon. Any admin who checked the lsh mailing list in the morning would have seen the error and the fix, and been well ahead of the exploit.

--
LRC, the best-read libertarian site on the web
Re:Telnet by ajs · 2003-09-20 19:10 · Score: 4, Insightful

These bugs are not killing us. In fact, they're helping us to make our code stronger.

I'm so sick of the "there are bugs in it, let's switch" mentallity. There are bugs in every piece of software ever written. Why? Because human beings have a hard time specifying exactly what they want.

Sometimes those bugs are dangerous (as in buffer overflows), but if you look at your average piece of source code long enough -- source of ANY number of lines -- I bet you can find a bug in it.

So, we should all switch to the abacus? No, we should all make sure we spend time and money on the problem of finding bugs before the black-hats do. And that's why I buy software like Red Hat... because they actually spend some of that money on auditing for security, and I like the results (many bugs found and killed).
Re:Telnet by TomV · 2003-09-20 20:50 · Score: 5, Insightful

Why the hell not? Good bridges are the ones that don't fall down

That's not the same as saying that good bridges have no faults. Bridges are built with a large safety factor. A large amount of the steel wire in the Brooklyn Bridge cables is hideously substandard, slipped in there by a currupt subcontractor. But because the safety factors were in place, even though the cables are probably about 5/6 as strong as they were designed to be, because they were designed to be 4 times as strong as strictly necessary, the Brooklyn Bridge is still there today. They paid for a lot more steel than strictly necessary, but they were proved right to have done so.

The bridge is Verifiably Strong Enough, but it certainly isn't Fault-Free. It was a product of defensive engineering, and software containing the inevitable bugs can be made much safer by taking a defensive approach to programming. It's better not to have an out-of-bounds situation at all, but that's no reason not to do bounds-checking wherever an OOB might pose a hazard. Yes it costs money to code all those extra checks, but that's what engineers do in most other disciplines.

TomV
Re:Telnet by groomed · 2003-09-21 03:33 · Score: 4, Informative

Sigh. The language card again. OK.

Java. Won't have any double-free bugs or stack-smashing attacks. But offers great potential for deadlock bugs due to the braindead IO model. And explodes in out of memory situations -- not unlikely given the tens or hundreds of MBs the Java runtime consumes. Further exacerbated by the ease with which memory is leaked. Then there are the subtle but devastating differences between the various Java runtimes. As well as the fact that the same isolationist principles that make Java immune to buffer overflows also make it very hard to interact meaningfully with the file system (ever tried setting creation dates on a file? ownership?).

Yeah. Java.

Still diversity is good. by Coryoth · 2003-09-20 18:30 · Score: 4, Insightful

Okay, there's a hole here, that's definitely bad. Still it would be nice if lsh could manage to gain some share of the ssh market. It has worried me for a while that OpenSSH has become the standard, which, unfortunately, creates a monoculture. A monoculture of ssh implementations is as vulnerable to massive infection as a monculture of windows boxes (okay, maybe windows has more holes, but its the massive part I'm concerned with).

If the market on ssh implementations was a little more split, it would be a little more difficult to write a worm that could wreak utter havoc. Repeat after me: Monoculture is bad.

Jedidiah.

--
Craft Beer Programming T-shirts

Re:The standard conclusion by GammaTau · 2003-09-20 18:34 · Score: 4, Insightful

Nothing is 100% secure, nothing is flawless, all operating systems are imperfect pieces of junk [...]

Which is why software monoculture is bad. The existence of competing implementations is always a good thing whether it's OpenSSH vs. GNU lsh or something else. That way not everything is compromised in one swoop once a new security flaw is discovered.

After 20+ years of buffer overflow exploits... by kcbrown · 2003-09-20 18:35 · Score: 4, Insightful

...you'd think that developers would finally know how to write software that doesn't have such vulnerabilities.

But unfortunately we don't seem to have made that much progress, despite the reasonably large number of development tools we have that address such issues (including anything from memory debuggers to string libraries). I mean, really ... people are still writing these things in C ... in the 21st century! I'm a big fan of picking the right tool for the job, but I think it should be clear by now that C isn't the right tool for writing secure software. There are simply too many ways to screw up.

I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.

You might still have to worry about buffer overflow exploits against the kernel, but that's a much more manageable problem.

--
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.

Re:After 20+ years of buffer overflow exploits... by 2Bits · 2003-09-20 19:03 · Score: 4, Interesting

That was something on my mind, when the problem was announced for openssh.

One thing we could do would be to "deprecate" funtions/modules that are known to be insecure, a la Java, and phase in the more secure ones. Like those old string manipulation funtions, if we can't make them secure and have already introduced something better, why not phasing them out?

And make the compiler flag it when it finds any deprecated functions.

Introduce this phase-in period over 2 to 3 years, that should be enough time for everyone to update their software, if that software is still maintained. And it's not maintained anymore, you prolly should be looking for something new anyways, unless your machine is not connected to the network, and you do not (absolutely not) introduce any new component to the system, or unless if you don't give a damn that the machine is owned.

If we are conservative, maybe introduce the phase in/out period longer, like 5 years or so.

I don't really give a darn about maintaining backward compatibility at all cost. Backward compatibility is good, but not at all cost. Software is an evolving thing. I code for a living, it sure is a pain, but sometimes, I just feel it's necessary to cut the bond and move to the next level.
Re:After 20+ years of buffer overflow exploits... by Chester+K · 2003-09-20 19:41 · Score: 4, Funny

I think it's time we started writing system software (that is, software which provides services but which runs as a process under the OS) in a language which doesn't have these problems. And if a suitable language is unavailable, that argues strongly for creating that language.

Careful there tiger, you're starting to sound exactly like Microsoft --- that's what they're in the middle of doing with C#; and we certainly don't want to imply that the OSS community needs to play catch-up with Microsoft when it comes to security practices.

--

NO CARRIER
Re:After 20+ years of buffer overflow exploits... by vt0asta · 2003-09-21 02:10 · Score: 4, Insightful

First things, first. C was meant to be a highly portable version of assembly. C successfully facilatated porting operating systems AND applications that used those operating systems.

People often think of C the wrong way, and that is often because languages considered "safe" borrow heavily from C syntax. If you have ever programmed in assembly/machine language, you know the programming bugs can do quite nasty and unexplained things (sometimes much worse than a buffer overflow). However, having coded in assembly one often becomes more rigorous with their coding, that same rigor is what is needed to carry over to C, and is what is lacking with some of the C coders of today.

Second, system software also often needs a low memory footprint. System developers often want to know where every little bit of memory went, and often find compiled code barely tolerable. Not everyone can afford the luxury of loading a perl, python, java, byte code interpretor du jour just to send and read data, manipulate strings, and do stuff with files.
System software is very different from operating systems, and calls for a different language.
Maybe you're right, problem is, many have tried almost all have failed to gain popularity for systems coding. Big problem for your argument and for developers who know, almost all of those different languages were first written in...drum roll...."C".

--
No.

Thank God! by Unominous+Coward · 2003-09-20 18:44 · Score: 4, Funny

I am even more glad than ever that I use telnet!

--
"Smoking helps you lose weight - one lung at a time" -- A. E. Neumann

hubris is never safe by Build6 · 2003-09-20 18:45 · Score: 4, Insightful

I remember reading the alert for the OpenSSH bug, where one of the options listed was to upgrade to lsh - not "change to", "try using", or anything of the sort, but "upgrade" - and I thought then that that demonstrated an unnecessarily... high-horse-y attitude. I'll bet they regret saying that now... . Humility really IS the best policy.

Re:Another forum for bashing Microsoft by UserGoogol · 2003-09-20 19:15 · Score: 5, Funny

And this, my friends, is why software should never be popular. Use OpenBSD!

Warning. The preceeding has been detected by Slashdot to contain sarcasm. OpenBSD is, of course, wonderful. Unlike those commies using FreeBSD.
--The Management

--
"Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor

Re:I have to laugh by cduffy · 2003-09-20 19:19 · Score: 4, Insightful

looks don't mean jack or shit.

In code, looks mean quite a lot.

Cleaner, more readable code is easier to audit.
Cleaner, more readable code is easier to bugfix.
Cleaner, more readable code is easier to add features to.
Cleaner, more readable code is simply Good Stuff.

Re:A replacement for C? by cduffy · 2003-09-20 19:37 · Score: 4, Interesting

A good replacement for C, eh? How 'bout C? Or, say, C?

Honestly, though: For low-level programming, there *is* no good replacement for C, for a simple reason: the same power that makes it dangerous is also the power that makes it useful. For high-level programming, there are lots of good replacements -- and you just mentioned, and wrote off, two of the best of them.

Java is getting better (witness the presence of the NIO API in 1.4), and I've got strong hopes for C# and its kin -- but part of what makes C# so useful is its simple API for access to C libraries, something that Java makes much harder. That said, for almost all of the high-level programming I do, I use Python (except at work, where I don't always get to pick; in the cases where I don't have the choice, I write Java).

Sure, Python and Java aren't suitable for low-level work -- but that's what C is good for. And since calling from Python down to C is simple, writing optimized versions of performance-sensitive routines is easy, in the rare event that it actually needs to be done (which has, in my five or so years of writing Python, happened all of once, when I needed some efficient drawing routines which were most readily available from a C library without preexisting python bindings).

Compiling Java to native code with GCJ also decreases the startup-time and runtime performance penalty without sacrificing type-safety -- and works for applications using an increasingly large subset of the available APIs.

Scheme is another language that many folks are too quick to write off. Not only does the language have the expected type-safety goodness -- but compiled scheme can be *very* fast. (On the down side, the lack of a useful standard runtime library is very disappointing).

So, yes, for high-level stuff, there are lots of alternatives... but what are you going to write your Python interpreter or low-level libraries in? For some jobs, there's still no good replacement for C. (Further, I'm not by any means convinced that low-level work *should* be done in an OO language... but that's a different conversation).

Re:I have to laugh by zulux · 2003-09-20 19:54 · Score: 4, Funny

Cleaner, more readable code is easier to audit.
Cleaner, more readable code is easier to bugfix.
Cleaner, more readable code is easier to add features to.
Cleaner, more readable code is simply Good Stuff.

I think you need to do a bit of re-factoring there. ;)

--

Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

Re:oh, right by jonabbey · 2003-09-20 19:55 · Score: 4, Interesting

The number of users of lsh today is immaterial to the question of justification for the lsh team's efforts, really. Ssh is critical stuff to have.. we have alternatives in mail transport servers, ftp servers and clients, web servers, programming languages.. why in the world not for free ssh implementations?

--
- jon

Ganymede, a GPL'ed metadirectory for UNIX

Smug. by Alioth · 2003-09-20 20:12 · Score: 4, Insightful

Serves those smug bastards right who were gloating the other day about how they use lsh and how it is so much better than OpenSSH. Hoist by their own petard, so it seems.

I _never_ gloat about running different software to $COMPROMISED_SW of the day. Just because I run exim, I don't think I'm magically more secure than a sendmail user. Exim users must keep up with the patches as well. Same goes for qmail. If you sit there smugly saying how superior your piece of software is, you're going to get bitten in the ass sooner or later, or at least end up looking very silly after all the gloating to find you're vulnerable too.

Dudes, doesn't matter what you run: don't gloat about it - be paranoid about the security of what you run, and keep up with the patches.

--
Oolite: Elite-like game. For Mac, Linux and Windows

lsh Pre-dates OpenSSH by divec · 2003-09-20 20:52 · Score: 4, Insightful

Does it exist solely because of the non-GNUness of other implementations?

When lsh was started, OpenSSH didn't exist. The original SSH was free till version 1.2.12, but was then put under a more restrictive licence. The licence on ssh version 2 was more restrictive still (I think it wasn't even free-as-in-beer). lsh was intended to be a Free, Open-Source replacement to ssh.

Then the OpenBSD people took the old, free 1.2.12 version of ssh, fixed all the known bugs which had accumulated since that release and updated it with the new features in the SSH protocol. This is OpenSSH.

--

perl -e 'fork||print for split//,"hahahaha"'

Maybe the standard Winlot conclusion by RoLi · 2003-09-20 21:08 · Score: 4, Insightful

nothing is flawless

Nobody ever claimed it would be.

However I've personally experienced that many systems are more secure than others. Almost all security problems on Unix didn't affect me (like this, BTW. This is actually the first time I've ever heard about lsh) and often were hyped up. In the meantime I get tens of Windows-Virus-mails and attemted IIS infections per day.

The true conclusion:

Windows is like a 50 year old car without safety belts, Unix is like a modern Volvo with safety belts and airbags.

Neither car is "flawless" and you can die in the Volvo too.

Yet another SSH server by Anonymous Coward · 2003-09-21 00:12 · Score: 4, Informative

There's always Dropbear, which seems fairly small and useful, and does SSH2.

Mmmmm. monoculturelicious.

27 of 445 comments (clear)