Remote Root Exploit In lsh 445
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."
Ha-Ha (Score:4, Insightful)
BTW, *who* uses lsh????
Re:Ha-Ha (Score:2)
ish is the Japanese version (Shift_JIS, EUC-JP, etc) of what uuencode and base64 does in ASCII.
Re:Ha-Ha (Score:3, Insightful)
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 w
So what did we learn? (Score:2, Interesting)
Re:So what did we learn? (Score:3)
What is the point of lsh? (Score:2, Insightful)
What idiots.
lsh Pre-dates OpenSSH (Score:5, Insightful)
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 standard conclusion (Score:4, Interesting)
Re:The standard conclusion (Score:5, Insightful)
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 (Score:4, Insightful)
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
Re:The standard conclusion (Score:3, Informative)
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 d
Re:The standard conclusion (Score:2)
Oh [cr.yp.to] really [cr.yp.to]?
I don't get it... (Score:2)
Maybe the standard Winlot conclusion (Score:5, Insightful)
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 (Score:4, Insightful)
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.
That's it (Score:5, Funny)
That is it I quit (Score:5, Funny)
Oh wait is that a new slashdot article?
I might be able to get first post...
Re:That is it I quit (Score:3, Funny)
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.. (Score:4, Insightful)
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.. (Score:2)
Re:Can someone explain to me why.. (Score:2)
It's good to have competing implementations of critical protocols like this, to avoid monoculture.
See, if everyone had been using OpenSSH, then an exploit against an OpenSSH vulnerability would have worked everywhere. This way, the script kiddies need to come up with two separate exploits, and try to figure out which one is applicable for any given system.
Of course, it looks like this lsh vulnerability is much worse than the OpenSSH theoretical vulnerability was, but the ecological argument still perta
oh, right (Score:2, Funny)
Re:oh, right (Score:5, 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?
Re:oh, right (Score:2)
(Before you complain... Go Fuck Yourself!)
Re:Can someone explain to me why.. (Score:2)
Regardless, I doubt that increasing security via more alternatives was the reasoning behind starting this project. I would much rather see these developers group together to debug problems and eliminate security issues.
Re:Can someone explain to me why.. (Score:5, Informative)
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.. (Score:3, Informative)
GPL? (Score:2, Insightful)
BSD, the way the world is supposed to be.
Re:GPL? (Score:2)
Theo has a horrible track record, I wouldnt trust him to secure my porn collection. That openssh hole wasnt the first remote root on openbsd, just the first one that was too big for theo to deny and silently patch to keep his ego up.
Compare old(vuln) talkd in openbsd to current.
No security professional worth anything would honestly say they trust any code theo is at all responsible for.
For anyone looking for a good alternative: telnet over an ssl tunnel or v
Re:GPL? (Score:2)
BSD can be highjacked anytime (exactly what happened to Unix) and it doesn't protect you from patents.
The GPL is a true hassle-free "no-sue" license.
Telnet (Score:5, Insightful)
Re:Telnet (Score:4, Insightful)
Re:Telnet (Score:4, Funny)
Just like good posts don't require logical operators that actually exist.
Re:Telnet (Score:4, Informative)
And anal rejoinders don't require snooty pseudo-knowledge that's actually wrong [php.net].
Re:Telnet (Score:4, Funny)
Re:Telnet (Score:5, Insightful)
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 (Score:3, Insightful)
Exactly. And the only reason this is different with bridges is because people don't ACCEPT bridges fall
Re:Telnet (Score:5, Informative)
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 (Score:4, Funny)
Don't you mean "the admin," or is there really more than one person using lsh?
Re:Telnet (Score:3, Insightful)
#include <standard f&*(ing merkin who thinks the world is all merkia>
Re:Telnet (Score:3, Interesting)
Re:Telnet (Score:5, Insightful)
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 (Score:3, Insightful)
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 r
Re:Telnet (Score:2)
You are exactly correct. In fact I would be wary about a working exploit posted within hours and a patch a little after. That leaves x amount of time for someone with a compiler and ten minutes to try to compromise me. But, these things happen. Its software, its supposed to happen.
If you're running remote admin apps without another layer of protection for redudancy like a VPN tunnel to your firewall, IP range blocking, etc you aren't properly defending yoursel
Re:Telnet (Score:2)
Re:Telnet (Score:2)
Re:Telnet (Score:4, Interesting)
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 (Score:5, Informative)
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 (Score:3, Insightful)
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 r
Re:Telnet (Score:3, Interesting)
I have to laugh (Score:4, Interesting)
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 (Score:5, Insightful)
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 (Score:5, Funny)
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.
mod parent up! (Score:2)
Re:I have to laugh (Score:2)
You see BSD is good and pure, sure nobody is talking about it but then nobody ever talks about good security. Good security goes unnoticed and unapreciated.
Gnu team can not hope to compete, bunch of beared hippies. Why if only they
Still diversity is good. (Score:5, Insightful)
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. (Score:3, Insightful)
After 20+ years of buffer overflow exploits... (Score:4, Insightful)
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... (Score:3, Insightful)
Re:After 20+ years of buffer overflow exploits... (Score:2)
Re:After 20+ years of buffer overflow exploits... (Score:2)
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.
Building on what we have makes the most sense, and given a bit more time, I'm confident that OpenBSD will be there.
Re:After 20+ years of buffer overflow exploits... (Score:3, Insightful)
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
Re:After 20+ years of buffer overflow exploits... (Score:5, Insightful)
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.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:After 20+ years of buffer overflow exploits... (Score:5, Interesting)
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... (Score:2)
Re:After 20+ years of buffer overflow exploits... (Score:2)
And this deprecation mechanism must be emphasized. If the functions are known to be insecure and not fixable, this has to be emphasized. Like in Java, when the class or method is deprecated, it's really explained why (e.g. not secure, not thread safe, etc), and points to the replacement.
The C/C++ community does not seem
Re:After 20+ years of buffer overflow exploits... (Score:4, Informative)
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... (Score:5, Funny)
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.
C can be used with appropriate measures (Score:3, Interesting)
You can easily find information on how to avoid buffer overflows, such as in this article [linuxjournal.com].
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 [lysator.liu.se] silently assumes the software works as designed. It does not mention protection against exploits such as buffer overflows.
And the coding sta
Re:C can be used with appropriate measures (Score:2)
A replacement for C? (Score:4, Interesting)
Re:A replacement for C? (Score:2)
how efficient do you need? (Score:2)
Maybe a C or C++ ssh daemon would take half the CPU time as one written in Java, but who cares when it's taking up less than 1% of the CPU? Memory and processor are cheap, having your system rooted is expensive.
Re:A replacement for C? (Score:5, Interesting)
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:A replacement for C? (Score:2)
Does there exist a good replacement for C?
At the risk of having my head handed to me... C++? I'm kinda fond of it.
Thank God! (Score:5, Funny)
hubris is never safe (Score:5, Insightful)
seriously, though (Score:2)
Is it just a different implementation of ssh2, or is there more to it than that?
Ish instead of OpenSSH? (Score:2, Insightful)
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? (Score:3, Interesting)
lsh? (Score:2, Funny)
At least that's how I feel.
Re:lsh? (Score:2)
advantages of lsh? (Score:2)
Smug. (Score:5, Insightful)
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.
Re:Smug. (Score:2)
The quality of Theos work (Score:3, Insightful)
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 (Score:3, Interesting)
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
Complain all you want about OpenSSH (Score:3, Interesting)
EXCEPTION_RAISE doesn't raise - bad naming (Score:2, Informative)
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
Yet another SSH server (Score:4, Informative)
Mmmmm. monoculturelicious.
Re:How thoughtful (Score:2, Insightful)
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
Re:How thoughtful (Score:4, Insightful)
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?
Re:Another forum for bashing Microsoft (Score:5, Funny)
Warning. The preceeding has been detected by Slashdot to contain sarcasm. OpenBSD is, of course, wonderful. Unlike those commies using FreeBSD.
--The Management
Re:Another forum for bashing Microsoft (Score:2)
ObMontyPython:
Splitters!
Re:Another forum for bashing Microsoft (Score:2)
All my open source software cost me $0, and has never once let an intruder in or brought my system to its knees.
We have a right to bash. I've wasted weeks of my life because of Microsoft's poor quality control and lack of source code control.
Re:Another forum for bashing Microsoft (Score:2)
the windows as an os IS an insecure system by _design_, even ms admits that(heck, they don't recommend rpc to be used in possibly hostile environments
Re:Telnet (Score:2)
Of course if I connect to some hosts in a galaxy far, far away, that's a completely different story. (i.e. use the exploit to
Re:Telnet (Score:3, Interesting)
Personally I agree, secure telnet is better.
rant continued... (Score:2)
What's even more sick is that when looked at carefully, everything on this site shows pure propaganda in the works. The core people who would read the 'developers' thread are in effect the people who have something at stake, their cherrished little holy grail. But what you don't realize is that as with any propaganda machine, you are dimming th
Re:How to tell if you are a MS fanatic (Score:3, Insightful)