Remote Root Exploit In lsh

So what did we learn? by evn · 2003-09-20 18:21 · Score: 2, Interesting

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

The standard conclusion by Overly+Critical+Guy · 2003-09-20 18:23 · Score: 3, Interesting

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.

--
"Sufferin' succotash."

I have to laugh by kakos · 2003-09-20 18:29 · Score: 3, Interesting

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.

A replacement for C? by guacamole · 2003-09-20 18:41 · Score: 3, Interesting

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? 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:Telnet by matusa · 2003-09-20 18:59 · Score: 2, Interesting

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

How about FreSSH? by Dahan · 2003-09-20 19:04 · Score: 2, Interesting

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

hang on a minute by Anonymous Coward · 2003-09-20 19:17 · Score: 1, Interesting

1) The bug in lsh was a heap overflow, which is somewhat different than the more common stack based attacks.

2) The true underlying problem is the x86 hardware. It is somewhat... lacking in the areas of privilege separation and permissions.

Yes, using well-tested libraries instead of rolling your own can help. Using certain languages can help. But the fundamental weaknesses of the x86 make securing code much more of a headache than it should be.

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

C can be used with appropriate measures by Serious+Simon · 2003-09-20 21:00 · Score: 3, Interesting

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 by Anonymous Coward · 2003-09-20 21:05 · Score: 3, Interesting

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.

Re:Telnet by DA-MAN · 2003-09-20 21:41 · Score: 2, Interesting

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.

--
Can I get an eye poke?
Dog House Forum

Re:The quality of Theos work by SmallFurryCreature · 2003-09-20 22:52 · Score: 2, Interesting

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)

--

MMO Quests are like orgasms:

You may solo them, I prefer them in a group.

Re:Telnet by Spy+Hunter · 2003-09-20 22:52 · Score: 3, Interesting

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.

--
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}

Re:Telnet by AxelTorvalds · 2003-09-21 03:06 · Score: 2, Interesting

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.

16 of 445 comments (clear)