Are we talking about the same lsh? The one that doesn't do X forwarding in the server?
No, we're talking about the lsh that does do X forwarding. And port forwarding. You can even tell it to just open a connection and not spawn a shell, in case you need just the port forwarding.
Well, I need two things from my ssh implementation:
- encrypted and authenticated communication with other hosts - security against network attacks.
OpenSSH provides only one of the two. It has repeatedly had security problems. You know, if it *has* to be C, you have to write in a certain style to prevent against buffer overflows. We have statistical evidence that the code is problematic.
That's got nothing to do with avoiding mainstream, but rather with careful selection of the software I use. I had excellent experiences with switching over from Bind to tinydns: when the Bind 9 bug hit the roads, I could sleep in.
So, I'm giving lsh a chance. I'll even do some more code review, to convince myself that it is ok, and what I see so far looks quite good. In fact, you rarely see such fine code. Of course it will need a couple of extra eyeballs to make really sure, but I have a lot of faith here.
Yes, because you need to have a writable and executable heap area for shared library linking. You could protect a part of the heap, though, and for instance allocate all user-provided strings in a non-executable heap.
But kiss good-bye to JIT compilers when you do it.
And still it would be imaginable to write an exploit for such a system. Clever manipulation of pointers can go a long way.
Do you have *any* indication that lsh is broken or inferior, other than a five year old README?
I have taken a look at the source. I like the approach of the author a lot, the code looks solid, the version number is well above 1.0. It's not immature software.
I cannot stress enough that lsh is re-written from the grounds up, using a single buffer handling API everywhere. If you *have* to use C, this is the way to go. Also, it does garbage collection, avoiding all double free bugs.
Besides, we know about the bug because people have observed exploits happening in the wild. The release of the fix was just a reaction.
That's about the third time that OpenSSH has a critical bug, leaving *all* my machines vulnerable. It can't be worse with lsh, and I actually believe it to be much better.
This is the README from 1998, talking about a beta version of lsh. Don't let age-old doumentation fool you.
lsh has grown mature since then, and has an excellent code quality. I recommend it. Any day over OpenSSH, after having looked at the code of both projects. Up-to-date documentation, as on the web page, or the README inside the tarball, doesn't contain the warning.
I've just looked, that README is from 1998! A lot has happened since then, and the up-to-date documentation, as well as the README that comes with the source, don't have a warning anymore.
So, don't let five year old documentation scare you.
Yes, that might be what the README says, but the quality of code I've looked at speaks another language. I trust Niels Moller more than I trust Theo de Raadt. Besides, SPKI is a good idea too.
Of course, I'd feel even better if it was entirely written in a language not equal to C. But Niels goes great lengths to avoid many of the C problems, and other than OpenSSH started with clean code from scratch.
I've look at the code, and can confirm that there is a heap overrun bug there. How to exploit it is a little unclear, but rumors are that an exploit exists. If you want to see for yourself, follow what happens in buffer_append_space(), when fatal() is called, and then packet_free() due to that.
Personally, I have upgraded all my systems to lsh. The code looks much more trustworthy, and I'm sick of upgrading every few months.
It was a sieve of Erathostenes implementation that we did for several languages. Results are here.
The thing with new string libraries is that there's a lot of code out there that doesn't use them and which you need to use to get productive in C, and that there's not only strings, but also a lot of other kinds of arrays, vectors and buffers that need to be checked. Even if your own code is fine, a lot of third party code isn't, and will never be.
And CPAN shows that it is entirely possible to implement a wide and useful range of libraries for a language different than C.
Re:Lisp and Python are compilers AND interpreters
on
Secure Programming
·
· Score: 1
Uh, throw the words into google, there's lots of information out there. "Interactive" basically means that you can type language expressions into a running executable, and they get executed in that context. "Non-interactive" is your familiar edit-compile-run-crash development cycle.
"Compiled" means that the program components are translated into machine instructions, whereas "interpreted" means there is an intermediate representation, usually byte code, and a driver loop that interprets those byte codes.
Compilation is a performance feature, and interaction is a development convenience feature.
And again I have to pick nits:). Reference counting is a weak form of garbage collection, and indeed has problems with collecting circular structures. There are algorithms like mark&sweep that don't have this problem. But you're right, there are still some problems to worry about, but far less than with manual memory management.
And regarding device drivers: on the Lisp machine, they were written in Lisp. As was the garbage collector, scheduler, compiler... everything. I even have written a video card driver in Dylan, just to drive home the point that this is entirely possible.
The fact that these days operating systems are written in C doesn't mean that this has to be the case.
Again, you're confusing terminology: strong typing comes in two flavours: static typing and dynamic typing, and only the latter requires runtime type checks.
And you're still referring to systems with dynamic typing as "interpreted systems". This is wrong, dynamically typed systems can be compiled too.
I'm not saying this to win an argument with you, but to make sure people don't get misconceptions about alternatives to C.
You're right in saying that no language will magically solve all of the problems. But there are some classes of problems that we do have silver bullets for. Buffer overflows can be prevented by bounds checks, cast errors by strong typing, memory leaks and double frees by garbage collection.
And no, Java/C# are not the solution to everything. The Lisp family is much closer. So is OCaml for the statically typed folks.
And I see the place of C in the world dwindling.
Re:We really need a different language
on
Secure Programming
·
· Score: 1
A concept that Dylan, as a part of the Lisp family, introcuced, is "sealing". Basically, you have fine-grained control over reduction of dynamism, like preventing a class from being further sub-classed by other libraries.
This allows the compiler to deduce certain information at compile-time, producing code whose efficiency matches that of C++ code. So the distinction between compile-time and runtime is there, it just happens behind your back in the compiler.
Re:We really need a different language
on
Secure Programming
·
· Score: 1
I don't see anything doable with templates that couldn't be done using macros and generic functions.
Of course templates are one of the tastier ingredients of C++. Still doesn't make the end result palatable to me.
Re:Lisp and Python are compilers AND interpreters
on
Secure Programming
·
· Score: 1
Well, don't confuse "interpreted" and "interactive" here. The two are related, but different concepts.
You can have compiled, interactive implementations (some Common Lisp implementations), and you can have interpreted, non-interactive implementations (your typical Java VM). Some implementations even mix-and-match, giving you both a compiler and an interpreter at runtime, and interaction with both.
And Python performance was a serious show-stopper for the MojoNation project, so it does matter in the end.
The short answer is: because people still write software in C.
It is not a problem of laziness with programmers. People make mistakes, that's the nature of things. If you force people to take care of bounds checking themselves, they eventually will fail to miss a case. This has been proven over and over and over and over again, since buffer overflows became known as a security problem with the first Internet worm to appear.
The only thing you can do against buffer overflows is choosing an implementation language that doesn't allow buffer overflows to happen.
Of course you're entirely right (although a crash is always very suspect of being exploitable, and thus a security issue).
My point is, that there's an entire class of bugs that are security issues, which are closely related to the language C/C++, and that by getting rid of them by getting rid of C/C++, software will become more secure.
Re:We really need a different language
on
Secure Programming
·
· Score: 1
I hold that C shouldn't be used to write system components either. This does include kernels.
Regarding the semantical richness of C++: once you've tasted the sweet aroma of closures, higher-order functions, multiple dispatch and dynamic typing, you wouldn't want to go back to C++ anymore. It feels like wearing a straightjacket.
Re:We already HAVE the different language.
on
Secure Programming
·
· Score: 1
In fact, the application that McCarty thought about when designing Lisp was symbolic derivation. But Lisp always was a universal language.
Re:We already HAVE the different language.
on
Secure Programming
·
· Score: 1
I never said that LISP could not make a kernel, Just that it would not run as well. [...]you can do things in C a lot faster and easier that you would have a bit More trouble writing in LISP.
And that wouldn't be true. There's no reason, zero, zilch, nada, none, a Lisp kernel would do worse than a C kernel. It wouldn't be slower, and it would in fact be easier and faster to write code for such a system. It would even run more stable, since it would almost always give you a stack trace with a stable system afterwards, where Linux gives you a kernel oops and a reboot.
besides, why would you want to write a kernel in a language developed to make it easy to process strings?
You seem to have severe misconceptions about Lisp. It was designed to give you powerful abstractions, and make everything easier. It does happen to make string processing easier and more secure than in C, but that's just a side effect of vastly more powerful abstraction capabilities. It's the same capabilities that make operating systems easier to write, by allowing you to find powerful abstractions for addresses, disk blocks etc.
Just to give a example: on the Lisp machine, there were special data types for virtual addresses and physical addresses, with hardware type checking. Try to access physical memory with a virtual pointer, and you get an exception instead of a crash. The system enforces proper semantics here, and detects violations.
then lets not forget, learning LISP is like learning Japanese when you were raised in the west.
Well, languages like Python, Ruby and perl are closer to Lisp than you might imagine in a lot of aspects. If you mind the syntax, take a look at Dylan: it is basically Lisp with an Algol-like syntax, much more convenient to the average programmer, without sacrificing the power.
Sure. For example, you have an OpenGL loop that iterates in an array of visible objects to draw every one 60th of a second. The objects amount to some thousand (because of the requirements). Why should the compiler check the boundaries on every array access ? it should not. It would be much faster to allow me to have a pointer to each entry of the array, and then increase the pointers.
Well, according to measurements we have done, the bounds checking overhead is less than 0.1%. But in the case described by you, the compiler can do even better.
First of all, usage of pointer arithmetics instead of array subscripts in an iteration over a container doesn't buy you anything with modern compilers anymore. They do strength reduction, turning the multiplication of address calculation into an addition.
Next, the compiler can infer that for an iteration over your array your subscript will always be in range, by doing constraint propagation and loop invariant code motion. What you assume about compilers just isn't true anymore.
One would say that if iterators were used, the compiler would figure out that the iteration is from first to last object, so it would remove the bounds check. And I would say that is is not possible, since iterators are not first class objects in any language. And it would prevent from using more than one iterator at the same time.
Of course I cam talking about languages with first class iterators, and compilers smart enough to figure out this stuff. And of course you can have multiple iterators at the same time.
I've never had such an incident in my code, because I always check the bounds of my memory.
Well, I guess you never use other people's libraries then, but only stuff written by yourself. The point is: I have yet to see a programmer who consistently produces overflow-free code. DJB almost does, but his software has almost no features as a cause. Bounds checking is much too important to leave it to the programmer. In fact, *my* requirement would be to have everything bounds checked, unless proven safe not to by the compiler.
the 'real problems' that you mention, i.e. algorithmical problems that are not buffer bounds, memory management etc are solved at the design level.
Right, and I'd rather spend 100% of my scarce time on design issues, instead of implementation issues. A good programming language is almost invisible on the implementation level, and allows you to focus on design issues.
You get the flexibility of using checks only when needed.
No, I get the "flexibility" of omitting checks even though they are needed.
I don't understand your attitude: do you support the 'more choices are better' attitute or not?
If "more choices" means giving every moron who's barely able to write "Hello, World" the opportunity to screw the security of my system, the answer is a resounding "NO! RUN AWAY SCREAMING!". Sorry, the track record of existing programmers, as reflected by the Marine-Corps-Attitude "My code is buffer-overflow-free, because I am tougher than the weenies out there" is just too bad.
If you don't, then you shouldn't support Linux.
Well, the only reason I support Linux is that it comes with source, as opposed to that OS from Redmond. Technically, Linux is as bad as the language it is written in, and I'd rather get rid of it fast.
And the argument that "computers are fast enough today so as that everything could be checked on run-time" is not correct.
Oh yeah? Did you do research on the overhead of run-time-checks? Or on modern compiler technology for optimizations? I did, and let me tell you that for the monetary equivalent of the performance difference you don't even get an hour of a good programmer's time.
Slashdot Mirror
Of course. It works. With exactly the fingerprint copy distributed in the Datenschleuder.
No, we're talking about the lsh that does do X forwarding. And port forwarding. You can even tell it to just open a connection and not spawn a shell, in case you need just the port forwarding.
Well, I need two things from my ssh implementation:
- encrypted and authenticated communication with other hosts
- security against network attacks.
OpenSSH provides only one of the two. It has repeatedly had security problems. You know, if it *has* to be C, you have to write in a certain style to prevent against buffer overflows. We have statistical evidence that the code is problematic.
That's got nothing to do with avoiding mainstream, but rather with careful selection of the software I use. I had excellent experiences with switching over from Bind to tinydns: when the Bind 9 bug hit the roads, I could sleep in.
So, I'm giving lsh a chance. I'll even do some more code review, to convince myself that it is ok, and what I see so far looks quite good. In fact, you rarely see such fine code. Of course it will need a couple of extra eyeballs to make really sure, but I have a lot of faith here.
The README in question is indeed gone, so the above seemed to have been Niels. Please mod up somebody!
Yes, because you need to have a writable and executable heap area for shared library linking. You could protect a part of the heap, though, and for instance allocate all user-provided strings in a non-executable heap.
But kiss good-bye to JIT compilers when you do it.
And still it would be imaginable to write an exploit for such a system. Clever manipulation of pointers can go a long way.
Yes, because it's a heap overflow, not a stack overflow.
Do you have *any* indication that lsh is broken or inferior, other than a five year old README?
I have taken a look at the source. I like the approach of the author a lot, the code looks solid, the version number is well above 1.0. It's not immature software.
I cannot stress enough that lsh is re-written from the grounds up, using a single buffer handling API everywhere. If you *have* to use C, this is the way to go. Also, it does garbage collection, avoiding all double free bugs.
Besides, we know about the bug because people have observed exploits happening in the wild. The release of the fix was just a reaction.
That's about the third time that OpenSSH has a critical bug, leaving *all* my machines vulnerable. It can't be worse with lsh, and I actually believe it to be much better.
lsh definitely is an alternative these days.
So the existence of an old README on the FTP server might be an oversight, but is no indication of missing or wrong documentation.
And I find the performance of OpenSSH much more worrysome.
This is the README from 1998, talking about a beta version of lsh. Don't let age-old doumentation fool you.
lsh has grown mature since then, and has an excellent code quality. I recommend it. Any day over OpenSSH, after having looked at the code of both projects. Up-to-date documentation, as on the web page, or the README inside the tarball, doesn't contain the warning.
I've just looked, that README is from 1998! A lot has happened since then, and the up-to-date documentation, as well as the README that comes with the source, don't have a warning anymore.
So, don't let five year old documentation scare you.
Yes, that might be what the README says, but the quality of code I've looked at speaks another language. I trust Niels Moller more than I trust Theo de Raadt. Besides, SPKI is a good idea too.
Of course, I'd feel even better if it was entirely written in a language not equal to C. But Niels goes great lengths to avoid many of the C problems, and other than OpenSSH started with clean code from scratch.
Personally, I have upgraded all my systems to lsh. The code looks much more trustworthy, and I'm sick of upgrading every few months.
The thing with new string libraries is that there's a lot of code out there that doesn't use them and which you need to use to get productive in C, and that there's not only strings, but also a lot of other kinds of arrays, vectors and buffers that need to be checked. Even if your own code is fine, a lot of third party code isn't, and will never be. And CPAN shows that it is entirely possible to implement a wide and useful range of libraries for a language different than C.
Uh, throw the words into google, there's lots of information out there. "Interactive" basically means that you can type language expressions into a running executable, and they get executed in that context. "Non-interactive" is your familiar edit-compile-run-crash development cycle.
"Compiled" means that the program components are translated into machine instructions, whereas "interpreted" means there is an intermediate representation, usually byte code, and a driver loop that interprets those byte codes.
Compilation is a performance feature, and interaction is a development convenience feature.
And again I have to pick nits :). Reference counting is a weak form of garbage collection, and indeed has problems with collecting circular structures. There are algorithms like mark&sweep that don't have this problem. But you're right, there are still some problems to worry about, but far less than with manual memory management.
And regarding device drivers: on the Lisp machine, they were written in Lisp. As was the garbage collector, scheduler, compiler... everything. I even have written a video card driver in Dylan, just to drive home the point that this is entirely possible.
The fact that these days operating systems are written in C doesn't mean that this has to be the case.
Again, you're confusing terminology: strong typing comes in two flavours: static typing and dynamic typing, and only the latter requires runtime type checks.
And you're still referring to systems with dynamic typing as "interpreted systems". This is wrong, dynamically typed systems can be compiled too.
I'm not saying this to win an argument with you, but to make sure people don't get misconceptions about alternatives to C.
You're right in saying that no language will magically solve all of the problems. But there are some classes of problems that we do have silver bullets for. Buffer overflows can be prevented by bounds checks, cast errors by strong typing, memory leaks and double frees by garbage collection.
And no, Java/C# are not the solution to everything. The Lisp family is much closer. So is OCaml for the statically typed folks.
And I see the place of C in the world dwindling.
A concept that Dylan, as a part of the Lisp family, introcuced, is "sealing". Basically, you have fine-grained control over reduction of dynamism, like preventing a class from being further sub-classed by other libraries.
This allows the compiler to deduce certain information at compile-time, producing code whose efficiency matches that of C++ code. So the distinction between compile-time and runtime is there, it just happens behind your back in the compiler.
I don't see anything doable with templates that couldn't be done using macros and generic functions.
Of course templates are one of the tastier ingredients of C++. Still doesn't make the end result palatable to me.
Well, don't confuse "interpreted" and "interactive" here. The two are related, but different concepts.
You can have compiled, interactive implementations (some Common Lisp implementations), and you can have interpreted, non-interactive implementations (your typical Java VM). Some implementations even mix-and-match, giving you both a compiler and an interpreter at runtime, and interaction with both.
And Python performance was a serious show-stopper for the MojoNation project, so it does matter in the end.
The short answer is: because people still write software in C.
It is not a problem of laziness with programmers. People make mistakes, that's the nature of things. If you force people to take care of bounds checking themselves, they eventually will fail to miss a case. This has been proven over and over and over and over again, since buffer overflows became known as a security problem with the first Internet worm to appear.
The only thing you can do against buffer overflows is choosing an implementation language that doesn't allow buffer overflows to happen.
Of course you're entirely right (although a crash is always very suspect of being exploitable, and thus a security issue).
My point is, that there's an entire class of bugs that are security issues, which are closely related to the language C/C++, and that by getting rid of them by getting rid of C/C++, software will become more secure.
I hold that C shouldn't be used to write system components either. This does include kernels.
Regarding the semantical richness of C++: once you've tasted the sweet aroma of closures, higher-order functions, multiple dispatch and dynamic typing, you wouldn't want to go back to C++ anymore. It feels like wearing a straightjacket.
In fact, the application that McCarty thought about when designing Lisp was symbolic derivation. But Lisp always was a universal language.
I never said that LISP could not make a kernel, Just that it would not run as well. [...]you can do things in C a lot faster and easier that you would have a bit More trouble writing in LISP.
And that wouldn't be true. There's no reason, zero, zilch, nada, none, a Lisp kernel would do worse than a C kernel. It wouldn't be slower, and it would in fact be easier and faster to write code for such a system. It would even run more stable, since it would almost always give you a stack trace with a stable system afterwards, where Linux gives you a kernel oops and a reboot.
besides, why would you want to write a kernel in a language developed to make it easy to process strings?
You seem to have severe misconceptions about Lisp. It was designed to give you powerful abstractions, and make everything easier. It does happen to make string processing easier and more secure than in C, but that's just a side effect of vastly more powerful abstraction capabilities. It's the same capabilities that make operating systems easier to write, by allowing you to find powerful abstractions for addresses, disk blocks etc.
Just to give a example: on the Lisp machine, there were special data types for virtual addresses and physical addresses, with hardware type checking. Try to access physical memory with a virtual pointer, and you get an exception instead of a crash. The system enforces proper semantics here, and detects violations.
then lets not forget, learning LISP is like learning Japanese when you were raised in the west.
Well, languages like Python, Ruby and perl are closer to Lisp than you might imagine in a lot of aspects. If you mind the syntax, take a look at Dylan: it is basically Lisp with an Algol-like syntax, much more convenient to the average programmer, without sacrificing the power.
Sure. For example, you have an OpenGL loop that iterates in an array of visible objects to draw every one 60th of a second. The objects amount to some thousand (because of the requirements). Why should the compiler check the boundaries on every array access ? it should not. It would be much faster to allow me to have a pointer to each entry of the array, and then increase the pointers.
Well, according to measurements we have done, the bounds checking overhead is less than 0.1%. But in the case described by you, the compiler can do even better.
First of all, usage of pointer arithmetics instead of array subscripts in an iteration over a container doesn't buy you anything with modern compilers anymore. They do strength reduction, turning the multiplication of address calculation into an addition.
Next, the compiler can infer that for an iteration over your array your subscript will always be in range, by doing constraint propagation and loop invariant code motion. What you assume about compilers just isn't true anymore.
One would say that if iterators were used, the compiler would figure out that the iteration is from first to last object, so it would remove the bounds check. And I would say that is is not possible, since iterators are not first class objects in any language. And it would prevent from using more than one iterator at the same time.
Of course I cam talking about languages with first class iterators, and compilers smart enough to figure out this stuff. And of course you can have multiple iterators at the same time.
I've never had such an incident in my code, because I always check the bounds of my memory.
Well, I guess you never use other people's libraries then, but only stuff written by yourself. The point is: I have yet to see a programmer who consistently produces overflow-free code. DJB almost does, but his software has almost no features as a cause. Bounds checking is much too important to leave it to the programmer. In fact, *my* requirement would be to have everything bounds checked, unless proven safe not to by the compiler.
the 'real problems' that you mention, i.e. algorithmical problems that are not buffer bounds, memory management etc are solved at the design level.
Right, and I'd rather spend 100% of my scarce time on design issues, instead of implementation issues. A good programming language is almost invisible on the implementation level, and allows you to focus on design issues.
You get the flexibility of using checks only when needed.
No, I get the "flexibility" of omitting checks even though they are needed.
I don't understand your attitude: do you support the 'more choices are better' attitute or not?
If "more choices" means giving every moron who's barely able to write "Hello, World" the opportunity to screw the security of my system, the answer is a resounding "NO! RUN AWAY SCREAMING!". Sorry, the track record of existing programmers, as reflected by the Marine-Corps-Attitude "My code is buffer-overflow-free, because I am tougher than the weenies out there" is just too bad.
If you don't, then you shouldn't support Linux.
Well, the only reason I support Linux is that it comes with source, as opposed to that OS from Redmond. Technically, Linux is as bad as the language it is written in, and I'd rather get rid of it fast.
And the argument that "computers are fast enough today so as that everything could be checked on run-time" is not correct.
Oh yeah? Did you do research on the overhead of run-time-checks? Or on modern compiler technology for optimizations? I did, and let me tell you that for the monetary equivalent of the performance difference you don't even get an hour of a good programmer's time.