Remote Root Exploit In lsh

skookum writes "After last week's OpenSSH patch-fest, a lot of people suggested GNU lsh as a replacement. Unfortunately, it seems that the lsh team has recently discovered a heap overflow bug of their own that can lead to compromise. An exploit was posted to BugTraq two days ago. Happy patching."

Comments

Ha-Ha

[Anonymous Coward]

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????

Re:Ha-Ha

[larry bagina]

liar. NetBSD kernel (and probably open + free as well) can be built with gcc, lcc, icc, sun's cc, and hp's cc, among others.

The *BSD userland code is generally less compiler and architecture dependent than GNU or "linux" utilities. The instructions for any non-trivial GNU or linux utility usually start off by telling you to install GCC, gnu/make, gnu/flex, gnu/bison, etc before you can compile it. lots of "linux" software won't build or run properly on anything but linux/x86

Compare that to BSD code which is useable as-is almost anywhere (it's been used by Windows 95-xp, Solaris, Aix, HPUX, OpenVMS, MacOS 7-X, minix, ATT SYS V, XINU, Xenix, etc)

So what did we learn?

[evn]

We should all take this to heart; any computer that isn't turned off and locked in a safe at the bottom of an ocean on jupiter should be considered insecure, and even then...

Re:So what did we learn?

[Doppler00]

Aha... so that explains why NASA is letting Galileo decend into Jupiter. Must be a security measure against all these recent buffer overflow exploits.

What is the point of lsh?

[Anonymous Coward]

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

What idiots.

The standard conclusion

[Overly Critical Guy]

Nothing is 100% secure, nothing is flawless, all operating systems are imperfect pieces of junk we're lucky to have running in the first place.

Re:The standard conclusion

[GammaTau]

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.

Re:The standard conclusion

[ScrewMaster]

I might add that this philosophy applies to organic systems as well, and for the same reason. A sufficient degree of diversity in any population, whether it be microbes, human beings, or operating systems, helps assure that no single pathogen can be totally destructive. Certainly, in this modern age of world-wide non-OS-specific internetworking protocols and data interchange formats, we should promote operating-system diversity as an additional level of safety.

I see many large corporations enforcing enterprise-wide standards. That is, everyone will run the same version of Windows, with the same applications software, same service packs, same anti-virus and firewall software ... which just means that when one machine does get compromised the entire organization is at risk. On the other hand, this situation is very convenient from the IT professional's point of view, so there is some argument for it. But I maintain that having a mix of operating systems, applications and protective software can provide more security than a more homogenous approach, and security is what we all want, right? Right?

Re:The standard conclusion

[pebs]

If monocultures are bad, then why does the 'linux camp' only advocate Linux? Why do firms that have names for parts of them like the Open Source Development Network or Open Source Development Labs spend their money on GNU/Linux - thus creating a new monoculture?

Someone has to focus on it. There will always be those groups of people who want to specialize in one area, and advocate the same specialization. But that's ok, as long as there are different groups doing different things. When everyone starts doing the same thing *cough* Windows *cough*, then we have a problem.

That's it

[Anonymous Coward]

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

That is it I quit

[Anonymous Coward]

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

Re:That is it I quit

[nacturation]

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

Well, I guess you'll have to settle for frosty piss instead.

Can someone explain to me why..

[Anonymous Coward]

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

[lcs]

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.

Re:Can someone explain to me why..

[FooBarWidget]

Because GNU Ish was created before OpenSSH. It's as simple as that.

GPL?

[ashkar]

Why would anyone voluntarily use software liscenced under the GPL when there is a much better, more servicable, and well tested application that runs under a less restrictive liscence? With the speed OpenSSH was patched, what is there to complain about. I mean, people still use sendmail with its track record of security bugs galore. It's unlikely anyone will switch because of a single bug.

BSD, the way the world is supposed to be.

Telnet

[Henry V .009]

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

[daeley]

While I would agree with you in the abstract that the open source community can do a lot better on some things, the bug was confirmed 2 days ago and patched immediately. Good software !== no bugs ever.

Re:Telnet

[runderwo]

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.

Re:Telnet

[cscx]

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.

Don't you mean "the admin," or is there really more than one person using lsh?

Re:Telnet

[matusa]

It seems to me that the only projects which can attest to an admirable security record are the ones that not only pursued security with a paranoid fervor for the entirety of their development, but furthermore were envisioned/designed with security as a prime consideration and can comment on security as a foremost issue in basically any context. If you go through examples in your head (postfix, openssh), you'll realize what I say.

Re:Telnet

[quantaman]

Good software !== no bugs ever.

Just like good posts don't require logical operators that actually exist.

Re:Telnet

[ajs]

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

[daeley]

Just like good posts don't require logical operators that actually exist.

And anal rejoinders don't require snooty pseudo-knowledge that's actually wrong.

Re:Telnet

[quantaman]

Grrr, stupid PHP!

Re:Telnet

[TomV]

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

[zangdesign]

I think the idea here was that security should be considered at every step of the way, which is absolutely true. While the speed of fixing the bug is certainly commendable, it should not have been there in the first place as this is a fairly common mistake.

I can understand it from someone new to programming, but if it's going to be something that is touted as being secure, that should be the first consideration in every line of code. Especially if it's something that allows deep access into the system.

I realize that such an undertaking is herculean, but that is what we, as programmers, should shoot for every time.

Re:Telnet

[DA-MAN]

Good one there, secure telnet has yet to show any weekness. Good ol standard SSL wrapping telnet is an unbeatable match. But most people don't have this client lying aorund anywhere and thus use ssh because of convenience.

Personally I agree, secure telnet is better.

Re:Telnet

[Spy Hunter]

Time and time again, it has been proven that software written in C will be insecure. If you don't take extraordinary precautions which are far too inconvenient for most programmers to accept, you *will* have security holes in a network service written in C. And if you do take those precautions, they will interfere with the goal of providing a feature-rich, modern, up-to-date piece of software. Why oh why hasn't there been a move toward writing network services in languages which make most common kinds of security holes impossible? A SSH server written in Java will have zero buffer overflows. Nada. Zilch. It won't have any double-free bugs, or stack-smashing attacks of any kind. That way, developers can focus on fixing the logic bugs and implementing new features.

It's very easy to understand. If you write your server in a language that prevents several common sources of root exploits, then the number of root exploits present in your code will be dramatically reduced. I would definitely be willing to put up with a server that was twice as slow if it had no possibility of buffer overflows, ever.

Re:Telnet

[Bronster]

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.

#include <standard f&*(ing merkin who thinks the world is all merkia>

Re:Telnet

[AxelTorvalds]

I full heartedly agree. For home use and most small things the whole find the problem, patch it quick and upgrade system works really well. The code is getting much better but if you're deploying a producting system in an important business environment it's not always so easy. For real production stuff you've probably been safer with telnet instead of ssh over the last few years because the weaknesses of most telnet deamons require sniffing which is a solvable problem in other ways and it's much harder for your script kiddies to just sniff an arbitrary connection. Worse, the OpenSSH stuff that has happened has shown how we need a more layered approach, OpenSSH has failed and people got root access, not shell access but they got remote root, it was a catastrophic failure.

I see this largely as a problem of the integration. If there is an OpenSSL issue, it affects which programs? Apache, OpenSSH, tcpdump (yep, it can use OpenSSL to the decodes) and dozens of others including databases that use SSL for secure connections. Depending on which vintage of the software you are on it potentially means you'll end up updating all of that stuff. RPM and deb fixes a lot of this stuff but I bring it up becuase I've seen the problems happen in the real world. A stupid SSL vuln caused us to update a database which is used for production data, it becomes a risk problem at that point, what's a lower risk the possiblity that someone may use the SSL attack or the possiblity that upgrading the database will be more complex than installing an RPM and require hours and hours of downtime? Once you're making those kinds of tradeoffs you've already lost.

Some opensource secure coding standards and guidelines would be nice and I think they could help cut down on these kinds of problems, they won't fix them but they can help. C and C++ aren't the problems, there are plenty of embedded programs that don't have those problems and they use different coding strategies and practices. You have to have a complete knowledge of the system to do secure coding. Java based daemons is kind of a solution but it ties us to a vendor and it's really heavy handed and takes a lot of memory to perform, worse it's not a small undertaking and Tomcat and JBoss have had some terrible security problems also. We end up trading one class of problems for a different set.

I just scanned the OpenBSD site and did a quick google, no OpenBSD secure coding standards and guidelines document exists... We need something like that, we already have groups doing audits and some very very good people doing them like Solar Designer and Theo de Raadt. What are they doing and looking for? Why isn't there a document for OpenBSD that explains why it's supposed to be more secure? If we came up with some good standards and practices for the whole community to emulate we'd be much better off.

Re:Telnet

[groomed]

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.

Re:Telnet

[zCyl]

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.

Exactly. And the only reason this is different with bridges is because people don't ACCEPT bridges falling, we consider it a tragedy, so we're willing to accept the amount of resource investment it takes to make the bridge stable with redundant defensive systems. And it's precisely this reason that we need to get rid of the attitude that having security holes in software is acceptable and unavoidable. (Thus, the above post not being a troll post.)

Materials have defects, so engineers got used to compensating for this with redundant systems, and the end result is a structure which is typically stable and fault tolerant. Programmers look at code as exact, so they think they should fix the problem by getting rid of the defects, but this makes the arrogant assumption that we're smart enough to spot every defect just by looking. This needs to be changed to the assumption that the best programmers will make mistakes and introduce defects, and therefore these defects should be compensated for defensively.

Re:Telnet

[groomed]

I consider bugs that can only cause a DoS much less bad than bugs which can cause the machine to be compromised.

Then the question becomes: how helpful is defense against stack smashing in preventing exploits, given that most exploits come about through social engineering or bugs at the application level (see VB macros, JavaScript holes)? Because the defense comes at a cost. You can argue that the cost is immaterial, that no cost is too high to prevent even the most innocent and trivial exploit.

That's a reasonable, principled argument, but not one I agree with. I take an economists view. If the estimated cost of an exploit is $25,000, but the cost of a thousand employees running slow, cumbersome software is $50 per employee per year, then the choice is clear. Especially since there is no guarantee that the slow, cumbersome software won't be subject to an exploit!

I'll even admit, shamefully, that I've personally written Java software where, due to a deadlock, a thread that should have been killed for security reasons was never notified of such and kept running. I don't blame Java for that. Maybe I'm just a bad programmer. But that's the whole point: the language's ability to provide application level security is limited. Conversely, also the degree to which a language can be held responsible for security breaches is limited.

What on earth do these two things have to do with Java's buffer overflow protection? If these things are hard to do in Java, that's because the APIs are badly designed, not because the language itself is secure.

Many of the Java security guarantees are derived by isolating programs from the underlying system. That is not a bad approach per se (it's pretty much the definition of an operating system kernel for example). But it does have its limitations. One of them being that you almost always end up with a lowest-common denominator design, through which the systems inherent capabilities cannot fully be excercised.

I have to laugh

[kakos]

All the people that were saying that the lsh code just 'looked' better than the OpenSSH code, a word of advice: looks don't mean jack or shit.

I don't know much about the development process of lsh, but I'm betting it doesn't do any security audits like OpenSSH does.

Re:I have to laugh

[cduffy]

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:I have to laugh

[zulux]

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. ;)

Still diversity is good.

[Coryoth]

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.

Re:Still diversity is good.

[HermesHuang]

Still, I'm not about to choose one implementation over another simply to add diversity. I'm going to pick the one I think is the best. Perhaps the reasons I use are wrong, and I probably don't know all the facts. But I tend to trust OpenSSH more then the other implementations. So I'm going to use OpenSSH. Period. I choose what I do because I don't want to deal with a worm at all. Not because I want to set things up so that when I do get a worm, it's only me and half of the sshd servers out there, rather then all of them. I acknowledge that diversity is good, but it's never going factor into my decisions regarding my security software.

After 20+ years of buffer overflow exploits...

[kcbrown]

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

Re:After 20+ years of buffer overflow exploits...

[Garen]

Took the words right out of my mouth. For large scale software that's this critical, we really need more safety guarantees to achieve adequate confidence that it's secure. That rules out C.

Re:After 20+ years of buffer overflow exploits...

[2Bits]

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

[kcbrown]

I'll agree that C lends itself to these things, but its the standard for a number of reasons, and frankly, anything else will introduce the same types of problems.

There will always be security vulnerabilities in software, of course. But buffer overflows are a class of vulnerabilities that simply shouldn't exist. C is unsuitable for system software because there are far too many ways (both subtle and gross) to wind up with buffer overflow bugs. It's what happens when the language is designed to make direct memory access easy.

You have to remember that C wasn't created to make writing system software easy, it was created to make writing operating systems easy. For that you have to be able to manipulate memory directly, and C is very well suited to that mission.

System software has different needs. It needs to be able to send and receive data, to manipulate strings, and to store and retrieve information from files, and do so securely. You may still need to manipulate buffers but that's a far cry from needing to manipulate memory directly. System software is very different from operating systems, and calls for a different language.

Re:After 20+ years of buffer overflow exploits...

[Chester K]

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.

Re:After 20+ years of buffer overflow exploits...

[fw3]

There are several available solutions to this

Libsafe, one of the oldest use LD_PRELOAD to replace the dozen-odd most often problematic library functions with safe/checked versions. It's been available for several years. Requires no code modifications (beyond setting the LD_PRELOAD env).

Propolice, stackguard, patches to Gcc / kernel provide various stack protections. Propolice has been built into OBSD for about a year now. These require object recompilation. PaX provides various randomizations thru the kernel. All fo these significantly complicate the attakers task.

Re:After 20+ years of buffer overflow exploits...

[vt0asta]

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

Re:How thoughtful

[mcpkaaos]

Think of it this way:

With the exploit patched, releasing the code for the exploit is one hell of a confident way to say, "Hey, we patched it." It also allows anyone to make sure that the machines they are responsible are, in fact, patched.

If you ask me, this beats the hell out of either admitting to an exploit and keeping the details hidden regardless of whether or not it's patched.. or just not squeaking any info about any exploit whatsoever.

Or.. think of it this way:

Maybe it's just a sure-fire way to light a fire under your ass to apply the necessary patch before someone figures out the exploit and turns your computer into another node in yet another attempt to DDoS microsoft.com.

Take yer pick, I guess. :)

A replacement for C?

[guacamole]

Does there exist a good replacement for C? Obviously, things aren't getting any better even though most programmers are aware of and try to avoid various types of typical C problems like buffer overflows, "off by one" errors, "double free" errors, fmt string vulnerabilities, etc. This language should be reserved for low level programming tasks like OS and compiler development only. For other tasks we need an efficient, portable language with automatic memory management, easy string handling, and object oriented facilities. For efficiency reasons, I think that Java or scripting languages like Pythnon are not a good replacement for C. What other alternatives are out there?

Re:A replacement for C?

[cduffy]

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

Thank God!

[Unominous Coward]

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

oh, right

[SweetAndSourJesus]

The five people on the planet using ish really slowed down those who sought to exploit the ssh vulnerability.

Re:oh, right

[jonabbey]

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?

hubris is never safe

[Build6]

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.

Ish instead of OpenSSH?

[coene]

Who would say such a thing? Are you high? Low blood pressure not getting enough of the red stuff to your brain?

You cannot beat the OpenBSD/OpenSSH coding standards, audit process, or documentation. Every software will have bugs, but replacing it with something more likely to have bugs, with a more restrictive license, less documentation, and next to no track record isnt a good idea just because it has "GNU" in it's name.

How about FreSSH?

[Dahan]

Anyone up to finding a root hole in FreSSH, another SSH implementation that nobody's heard of? :)

lsh?

[Sexy Commando]

Hey, for gentoo users, if a piece of software is not in portage tree, it never exists.

At least that's how I feel.

Re:Another forum for bashing Microsoft

[UserGoogol]

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

Smug.

[Alioth]

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.

lsh Pre-dates OpenSSH

[divec]

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.

The quality of Theos work

[aliquis]

Thought this is rather old news I never thought that anyone else could do an ssh application better then the one the openbsd team could bring out. I'm confident that they do their best and look thru the code very carefully and still this kind of things happen.
I find it strange that there never seems to be an end of the openssh, apache, php, sendmail and mysql vulnerabilities. I suppose it's just damn hard to write secure code all the time. I blame the C language a little for this, should you really have to be this careful all the time? Do you really have to reinvent the wheel every single time?
Imho c is just something you should use because the application you are editing already uses it or the teacher has told you so. There are lots of better languages out there. Can't understand all the complains on java for example.
Does anyone have some suggestions about libraries, special functions, compiler mods and so on which make C programs a little more secure? Any suggestions of other languages which is available for different platforms but more secure and with less reinventing of the wheel all the time? The ones which come to my mind are as I said java and scripting languages like python, ruby and so on. But there got to be atleast one which isn't interpreted?
Suggestions are more than welcome.

Re:The quality of Theos work

[SmallFurryCreature]

Yeah java, yippie, not like that never makes computers crash. (sorry freenet just crashed my pc again)

C is like steel. Sure you can make cars from different materials. Sure certain cars are known to be unsafe. Certain cars are in fact known to be real deathtraps. These cars are made out of, shock and horror, steel!. Steel therefore is unsafe and we should all move to a different material. Then all cars will be safe and we can all rejoice in having squashed the evil and unsafe steel.

C is a tool. Tools are not inherintly safe or unsafe. Watch some "real-tv" programs and you will see that people can do amazing damage with something as harmless as a hammer, a tool that has been around for several millenia and people still don't use it safely.

You are the tool user. It is up to you to use it safely. I fear very little will be accomplished by going to a different tool. In fact it may be worse. You seem to suggest a language were the language does the error checking so that programmers no longer need to worry about. Great so in a few years times we will have no coders left who know how to write their own error checking code. Who is then going to write the error checking code in these languages?

Even worse what would happen when a security bug is discovered in that error checking code? Then suddenly every piece of software ever written in that language has a hole in it. Whee! (can this happen, I am just speculating. kinda like when openssl has a bug every piece of software that uses it is affected)

C can be used with appropriate measures

[Serious Simon]

C doesn't impose measures against buffer overflows, but that doesn't mean it is prohibitively difficult to implement them.

You can easily find information on how to avoid buffer overflows, such as in this article.

However, the developers in the lsh project (for example) do not appear to have given this subject much thought. In the lsh manual, the chapter on Threats silently assumes the software works as designed. It does not mention protection against exploits such as buffer overflows.

And the coding standards outlined in the lsh hacking guide are targeted at avoiding breakage by the programmers, not by outside attackers.

Projects developing exploit-sensitive software should implement proper measures to avoid buffer overflows. As long as this is done, C may still be the appropriate language for such projects.

Complain all you want about OpenSSH

[Anonymous Coward]

It is interesting to see the types of holes that have been found in OpenSSH to date - these are *far* beyond typical buffer overrun problems that some other software projects suffer. Because of its popularity, it has become an attractive target and thus something of proving ground for new attack methods - int overflows, malloc corruption / free() exploits. OpenSSH is getting the bugs slowly beaten out of it.

Maybe the standard Winlot conclusion

[RoLi]

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.

Re:Maybe the standard Winlot conclusion

[Overly Critical Guy]

Nobody ever claimed it would be.

You do visit Slashdot, don't you? It is claimed all the time. The prevailing attitude and anecdotal evidence about how secure Linux is and how insecure and unstable Windows is runs through every discussion thread even remotely involving anything Microsoft. A large part of this site is just reactive hysteria to "Microsoft worms." Heck, whenever there's an X-Box article, you get the requisite hundreds of "jokes" about green screens of death.

You claim to get virus-mails, which usually require user intervention to spread. Then you mention IIS intrusions, despite the fact that Slashdot recently posted an article called "Linux Most Attacked Server?" which showed Linux was the most breached operating system on the net.

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.

No. The true conclusion is that your personal disdain for Microsoft products in an OS war doesn't matter in the end. All operating systems are insecure and vulnerable. They are equal.

The true heart of security lies in your system administrator. Period.

EXCEPTION_RAISE doesn't raise - bad naming

[ThePythonicCow]

This bug doesn't surprise me - the previous line reads "EXCEPTION_RAISE ...". One would expect from the verb "RAISE" that it was going to jump out of line right there, and that the next line would be NOTREACHED.

A proper fix for this would change the name of that EXCEPTION_RAISE macro to something that doesn't suggest out of sequence execution.

Someone should grep through the source for lsh, and see if there are any other places where after this macro is called, the code really is expecting execution to continue inline.

Re:How thoughtful

[skookum]

Do you honestly think that the kind of people that would want to use such an exploit would actually learn about it from slashdot? Don't you think they'd know how to find the BugTraq archives themselves?

Do you honestly think that by pretending that an exploit doesn't exist you're any safer? Do you think you will patch your systems (and urge your supervisors to grant you the priority to patch those systems) faster knowing that an exploit is easily available? Do you not agree that it doesn't matter whether you feel good or bad about the situation, what matters is how fast and to what extent all vulnerable systems are patched? Do you not think that knowing of an exploit helps that goal?

Yet another SSH server

[Anonymous Coward]

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

Mmmmm. monoculturelicious.

Re:How thoughtful

[AKnightCowboy]

People can know their system is patched by patching their system. They dont need to test the exploit on it.

Actually, yes, some of us need to. Part of our security policy is to test an exploit (if available) against the patched system to verify the system is not vulnerable. Blindly accepting that "yes, the magic version number has changed so I am safe" is not reasonable for many people. It's always best to disseminate exploits as fast and as far as possible to get people to patch their systems. Take for example the recent Windows RPC vulnerabilities. 75% of the people wouldn't have patched it this year if it hadn't have been for the Blaster worm.

How old is C now anyway?

[presidenteloco]

A language like Java, with a carefully designed JVM implementation, is not subject to buffer overflow/heap overflow exploits. Is it maybe time to rewrite all of the higher level OS apps in Java? Sure, keep a microkernel in some blazing fast C/assembly code if you must, but there's not reason something like SSH can't be written in Java (in fact it has been.) Why not all of the high-level Linux apps (i.e. the GNU stuff)? If you don't like Java's license, then do as MS did with C#, and clean-room rewrite Java under a GNU project first. I'd do it myself but I'm still trying to figure out how to make a living in this damn business.

Re:How to tell if you are a MS fanatic

[Bull999999]

I'll have to agree with you on that one, as it is possible to run Office on "Linux" and therefore, by their logic, it would also be a "Linux" flaw. However, it would be correct to call it a MS flaw.