It's true that C has tools for simulating modern programming language features like Garbage Collection and array bounds checking. But the tools are pretty clumsy since the language wasn't designed to support them. (GC has to be conservative and can't compact the heap, etc.) However, I think that the existence of these tools is a testament to how much those features are needed in an appliaction programming language.
Unfortunately, whatever you do, C will never be a safe language. Why not just use one of the many new languages that support these features natively, and by design?
Guess what? The SSHD is doing its own bounds checking already.
I think before you say stuff like this, you should check out the performance of a modern safe language that's compiled (not JIT or VM). I recommend O'Caml for starters. They are quite fast!
I don't understand what you're saying. Neither of us are claiming it would eliminate the bug in the code, but that it would make it non-exploitable by raising an exception instead of entering "undefined behavior" land.
I assert that modern safe languages would make this TYPE of problem NON EXPLOITABLE.
1. I'm not talking about Java; it has a lot of problems and it is not really representative of what modern languages can do. Just to be concrete, let's choose SML as an example of a modern language.
2. Java does not need to be interpreted. SML is hardly ever interpreted; all of the SML compilers I know produce fast native code.
I don't know much about java, but you can feel free to look at the SML runtime libraries (all open source as far as I know) and try to come up with remote exploits. We'd love to hear about them, though I don't think you'll have much luck. You can find an index of some of the SML compilers at http://standardml.org/.
> And you may think your an expert since you wrote > an FTPD but is it as capable as wu-ftpd? Just > because you can serve a file as quickly doesn't > mean that it comes anywhere close to handling > all the features that wu-ftpd. Sit down and try > to write tens of thousands of lines in a > so-called "modern language" and you'll be back > to C.
I'm not calling myself an expert. It was a total joke to write the ftp daemon; it took me a weekend and it didn't involve any kind of research or learning. I just did it. It would be pretty easy to support the rest of what wu_ftpd supports, but as it is I am RFC compliant and I don't need to support any of the archaic character encodings or dubious "features" (like SITE EXEC) that wu_ftpd supports.
I did it as a proof of concept -- it's easy to rewrite software from scratch, and it's easy to do it in high level languages, and the resulting performance is more than acceptable. (And of course the code is nicer and the applications are more secure!)
I have written tens of thousands of lines in Standard ML, and I don't plan on going back to C! In fact, we're working on a compiler that's over 100,000 lines of code, and I couldn't imagine managing a similar project in C (nor can I imagine how long it would be!!)
Basically, it sounds like you have some more learning to do about what is out there.
> 1. Which implementation of Standard ML do you > prefer? I use Linux.
What I do is to use SML/NJ for development, because it has better error reporting and an awesome interactive loop, and then compile my programs for later use with MLton.
MLton is a command-line compiler that produces standalone binaries. It makes much better code than SML/NJ does, except that it has awful error reporting because the front-end, well, isn't there yet. =) (One is in the works...)
SML is standardized; there's a book with a more formal description than I've seen for any language (and which the authors have proved correct), and because of this, the various implementations tend to be *very* compatible with one another. (No "undefined" or "implementation defined" behavior like C.) The language will probably undergo revisions like C and other languages do, but the community is very conservative about breaking old code.
The other poster is right -- SML is the language hacker's language. There are like 10 implementations of it, which is of course less than C and C++, but probably more than any other language.
If the feel of SML isn't right for you, I recommend checking out O'Caml, another brand of ML (at caml.inria.fr). They only have one implementation, and it is much more "hacking" oriented. Unfortunately, the O'Caml language is much less stable.
Thanks for opening your mind! =) I hope you like it, but if not, well, at least you tried. =)
> So are you saying that "use a different language" > is a magic bullet that will fix all problems? > Maintanance and security patches will not > disappear, though they may be greatly reduced.
Of course I'm not saying it will fix all problems. It will fix all buffer overflow, string formatting, and heap corruption problems, which are where the vast majority of exploitable unix holes come from. That will greatly reduce the maintenance and security patches, yes. Isn't that good?
Purify is a great tool. It makes writing C and C++ programs bearable to me. Unfortunately, it'd be hard pressed to find this kind of error, since you'd need to *at runtime* replicate the conditions under which it's exploited (ie, passing in an id that is out of bounds), in which case you would have pretty easily figured out that there was a bug when your program crashed! In order to get security guarantees you'd need a more thorough static analysis of the code. (In general, the problem is undecidable, so the only practical full solution is to use bounds-checked arrays when the compiler can't determine that the index is always within bounds.)
I know you're just joking, but if you associate "modern" with Visual Basic, you need to do some more learning. There are loads of very interesting languages that are more powerful than C, as well as being easier to use.
Re:Please stop writing network apps in C!
on
OpenSSH Local Root Hole
·
· Score: 2, Interesting
AC Writes,
> So it still comes back to "don't do it if you > don't understand the problems"? It is conceivable > that someone could code a library poorly and cause > a security problem, but according to you it rarely > happens. This just leads me to believe that it IS > okay if you know what you're doing. What you mean > to say is that one should use a more recent > babysitting language if they're not capable of > doing it without having their hands held.
Yes, in a sense. Here's how I would say it, though: we want to minimize the amount of trusted code. To a certain extent we need to trust the OS kernel, the compiler, and some libraries (depending on what language they're written in). That's because everybody makes mistakes, even smart people who know all about good C coding (like the OpenBSD/openssh people), and mistakes in C are often disastrous. Even people who are really good at C should avoid using C whenever possible, because it increases that trusted code base.
Actually, my group at CMU is working on trustless compilers (that is, compilers that produce checkable certificites that they did a good job). I'll be back in a few years talking about how this technology can reduce the (already few) security concerns with using a compiler. But for now, the biggest step is to keep people from increasing the size of the trusted code by writing applications in low level languages like C!
> Just open top and press T to sort by CPU time and > S to turn on accumulation. The time displayed now > is the CPU time accumulated by the processes and > all the spawned children. On my server (up 2 days) > it is 39 seconds for sshd. A bit more than I would > have thought.;-)
Great!
According to my computer, sshd has used about 31 seconds of cpu time per day since I booted it months ago. Considering that I always have several ssh connections into it and often transfer large files via SCP, I think that's not very much at all...
> We write such servers in C for one reason: > speed. > The users demand it.
Do they? Maybe cdrom.com demands it, but I have never heard any of my linux-using friends complain about how much CPU their ftpd or sshd is taking up. However, I have definitely heard them complain about how many patches they need to apply, of about getting rooted yet again...
> Java has too many resource requirements (CPU,
I wasn't really suggesting java, actually, although natively compiled java could probably work if you need the language to feel like C.
> Don't give me that "hardware is cheap line". The > cheapest hardware is the hardware you don't have > to buy.
Hardware is cheaper than the time it takes me to install all of these damn patches.
Actually, I don't care much about DOS "exploits", especially ones that require the attacker to expend resources to keep the attack up. It's pretty simple to flood my connection and make my computer unusable anyway.
In the case of SSHD, the situation you described wouldn't happen -- it spawns a new process for each connection, so an exception thrown in one wouldn't cause the others to be dropped. The attacker would merely be using up your resources.
A programmer in a modern language has plenty of choices, too. He can catch exceptions and restart the server. He can log them. And of course, the users are safe from being rooted until a patch is out.
Re:Please stop writing network apps in C!
on
OpenSSH Local Root Hole
·
· Score: 3, Insightful
You don't need an interpreter to do bounds-checking on arrays. For instance, SML (that's what I wrote my ftpd in) compiles to native code and has bounds checking. There also exist native compilers for java.
It's *much harder* to make a mistake in a compiler that causes an exploitable hole in software compiled with it than it is to make the same errors over and over in the applications themselves. (Just compare the number of compiler/library-caused exploits to the number of application exploits!)
Re:Please stop writing network apps in C!
on
OpenSSH Local Root Hole
·
· Score: 4, Interesting
> How did it cope with 18,000 simultaneous > connections? Did you use mmap(), sendfile() and > friends on linux to get the best performance > possible? How did the xfer rates compare?
I can't handle 18,000 simultaneous connections, but I don't think that 99% of people actually care about that. In fact, I don't think linux even supports 18,000 open file descriptors at the same time. My ftpd is intended for the home user who cares more about getting rooted than the low-level performance of his servers.
Yes, it uses sendfile to transfer files when it doesn't need to do EOL conversion. I'm easily able to fill my 100Mbps connection without breaking a sweat either way. (In my informal benchmarks, my server got exactly the same transfer rates as wu_ftpd).
> I actually do agree with your points mostly, but > I would say "Don't use c for network apps unless > you have a good reason to"
Well, ok, but what would be a good reason to? One might be that you need to write a server that can really handle 18,000 connections. (Then, I hope that the users of your server have enough cash to pay someone to maintain them, apply security patches, etc.)
> In some ways SSH is a special case anyway. It > has all the intensive maths stuff to do for the > session key generation etc. Not a good idea to > code that in (eg.) perl imo.
Yes, that's true. SSHD probably uses much more CPU than a typical network app. Yet (see my other posts), it really doesn't use that much anyway.
I wouldn't suggest writing it in perl, since perl has its own kinds of easily exploitable bugs. Also, the performance of perl is not in the 20%-100% category that I mentioned.;)
> BTW, out of interest, what is your "favorite > modern language" ??
Standard ML. It's got loads of cool features like higher-order functions, polymorphism, datatypes, parameterized modules, and static typing (which also really helps to catch bugs). It's natively compiled and quite fast. You can learn about it at standardml.org. Hacker types might like O'Caml better, that's at caml.inria.fr.
I read the patch. It is not a buffer overflow in the traditional sense of strcpy, but it is an out-of-bounds write. You might consider that a buffer overflow, but maybe not. (Did I even call it that?)
Read my post again: I said that this error would NOT BE EXPLOITABLE in a modern safe language. You can still make the error, but the array write would be checked and would result in some kind of defined behavior (ie, an exception). This is true of buffer overflows as well.
Yes, that's true, but that doesn't imply that the situation is any better for C. In fact, I recall that libc had a globbing bug that caused an exploitable hole in ftpd (that was the reason I wrote this server in the first place) recently. Personally, I think it is extremely rare for a compiled language to have an implementation bug that leads to exploitable code. (I would be very interested in hearing examples, though, besides the one I mentioned.) As a practical matter, application-level bugs like the one in sshd are far far more common.
On a related side note:
I can't actually propose that people use this, because the technology is not that mature, but we are working on something called "typed assembly language" that would at least guarantee type safety of even the compiled code. (So that bugs in the compiler can't introduce certain kinds of security holes.) Check out http://www.cs.cornell.edu/talc/ for more info if you're interested.
> Does the compiler for your favorite modern > language support binary code optimizations that > let your ftpd run as quickly as a popular C ftpd
Yes, mlton (for my favorite modern language, SML) produces nice native code. I would guess that my server is no more than 20% slower than a C server implemented the same way.
> Does it have a GC thread that might kick in and > cause delays?
There is no GC thread in typical SML implementations. GC happens when an allocation fails because the heap limit is reached. GC times are typically very small (especially when amortized against essentially free allocation compared to malloc()), and in fact the compiler I'm working on at school has a real-time GC. But do you really need real-time guarantees for an FTP server? The actual transfer portion doesn't even do any allocation.
My ftpd can easily fill my 100Mbps connection at school without breaking a sweat. I don't know how many users it can handle, though.
> Or did you just use bounds-checked C++ arrays > and strings?
C++ wouldn't guarantee safety, even if using bounds-checked arrays and strings, since you can still do things like a double free of memory. Also, I find that C++ lacks many features that make writing software much nicer in SML, but that is of course a subjective thing.
That said, my ftpd would probably need more enhancements to support a *really* popular ftp site. But I think that would not be so hard; in fact, easier than C. My server is intended for the 95% of users who run a home machine and need to transfer files from time to time, but DON'T want to get rooted because they aren't up-to-date on patches. I would be VERY surprised if there is any exploitable bug in my daemon.
(Also, I think FTP sucks too. I just did it because it's a relatively simple protocol, and at the time (summer 2001) ftp servers seemed to have the highest profile security holes.)
Yes, I read it. The bug is that they write outside the end of an array.
A modern language would not catch this bug (unless you were using a data structure like a search tree instead of an array). However, it would make it NON-EXPLOITABLE, because a safe language would cause an error (ie, exception) on an out-of-bounds write, not corrupt the heap or stack and allow for an exploit.
> I cry BS. Your previous post claimed that > performance was not a reason and yet I don't > believe you. Wake up and stop acting as the HW > vendors lobbyist.
Actually, I am a "modern languages" lobbyist, not hardware. =) But that's because I study and believe in programming languages, not because I have some kind of financial interest.
I'd love to respond to your post but I don't know what your point is. I guess all I can do is reiterate my point on performance:
1. sshd, running on my machine for about 8 months, has accumulated a mere 2 minutes and 30 seconds of CPU time. Of course, sshd forks off a new process for each connection, but all of the ones on my machine (some of which are at least a week old) have used 0:00. If someone knows a way I can measure the actual time spent by the daemon, I'd like to hear it, but I assume for now that it is *very small*.
2. I can easily fill my 100Mbps connection without breaking 2% CPU usage. (In other words, sshd is bandwidth limited, not CPU limited.)
3. Most home / small business users do not have 100Mbps connections, and could care less about the difference between 2% or 5% CPU usage.
4. However, most home / small business users DO care about having to download patches when their C programs contain buffer overflows.
5. Modern languages are not actually much slower than C. (I estimate worst case 2x slower, typically more like 20% for SML, which is what I wrote my FTPD in.) Being easier to write in, they also give more opportunity for high-level optimizations.
Therefore, I conclude that for almost every user, security is a more important concern than speed, at least as far as network daemons go. How can you argue the opposite?
This kind of bug would NOT BE EXPLOITABLE if sshd was written in a modern safe language.
If the canonical secure software from the canonical secure software people has bugs like this, I don't see how anyone can argue that it's possible to write secure code in C. C makes it easy to make this kind of bug, and the bugs are often exploitable.
Check out my previous post and ensuing discussion on this http://slashdot.org/comments.pl?sid=24271&cid=2629 013 for more info. Synopsis: There are some reasons to use C for a project, but none apply to network daemons. As a proof of concept, I rewrote FTPD in my favorite modern language; the source went from 24,000 lines to 3000 (including support code, like PAM_MD5 password encryption), took me only a weekend to write, and is 100% buffer overflow / format string / heap corruption free.
I'm trying to raise awareness about this because I think it's a real obstacle to us having secure software.
/dev/urandom uses all sorts of hardware timings (like incoming packets, hard drive seeks, etc.) to produce add entropy to its pool. Typing or moving the mouse improves this, though I think "inferior" might be too strong a word since they are both nearly unpredictable anyway.
You don't have to program with objects in Java. You can program totally C-like code (you just have to do away with some unsafe C idioms that aren't very good anyway) in Java and just benefit from its type safety, memory management, portability, and large library of utilities.
I think maybe you just haven't had enough experience with Java? Having no core dumps, memory leaks, or buffer overflows really is a nice thing, especially for network apps...
The fact that more people use C says little about the language except that it is older and popular. (Lots of people here would be upset if you applied the same argument to Linux versus Windows.)
For a network app, it is ludicrous to write in C. You have to deal with buffer overflows, memory leaks, cumbersome char*-handling routines, and portability problems. Out of it you get a whole lot more code for a lot more time and headache, and also some speed increase. During the same time, you could have been optimizing your Java (or whatever) program and improving things like data structures and algorithms (which as we all know is what *really* matters in performance).
I ran a freenet node for a while and speed was not a problem. Ease of development and security are much more important, and Java (or other, better modern languages) win hands down for these.
I don't think it's just the available content that's crappy, it's more about the content meta-data and how it's searched and ranked. Gnutella has essentially the dumbest search strategy of any P2P network: if the query appears in the file name, then it is a hit (and the hit is as good as any other).
Morpheus had reasonable meta-data and let you search based on other qualities. There's no real reason that a P2P network shouldn't support this, it's just that gnutella was a bit too early for that idea, and hasn't really caught up since then.
Slashdot Mirror
Guess what? The SSHD is doing its own bounds checking already.
Yeah, and the hole is an error in doing it manually instead of leaving it to the compiler...
Exactly.
It's true that C has tools for simulating modern programming language features like Garbage Collection and array bounds checking. But the tools are pretty clumsy since the language wasn't designed to support them. (GC has to be conservative and can't compact the heap, etc.) However, I think that the existence of these tools is a testament to how much those features are needed in an appliaction programming language.
Unfortunately, whatever you do, C will never be a safe language. Why not just use one of the many new languages that support these features natively, and by design?
Um...
Guess what? The SSHD is doing its own bounds checking already.
I think before you say stuff like this, you should check out the performance of a modern safe language that's compiled (not JIT or VM). I recommend O'Caml for starters. They are quite fast!
I don't understand what you're saying. Neither of us are claiming it would eliminate the bug in the code, but that it would make it non-exploitable by raising an exception instead of entering "undefined behavior" land.
I assert that modern safe languages would make this TYPE of problem NON EXPLOITABLE.
Your post has some fundamental mistakes...
1. I'm not talking about Java; it has a lot of problems and it is not really representative of what modern languages can do. Just to be concrete, let's choose SML as an example of a modern language.
2. Java does not need to be interpreted. SML is hardly ever interpreted; all of the SML compilers I know produce fast native code.
I don't know much about java, but you can feel free to look at the SML runtime libraries (all open source as far as I know) and try to come up with remote exploits. We'd love to hear about them, though I don't think you'll have much luck. You can find an index of some of the SML compilers at http://standardml.org/.
> And you may think your an expert since you wrote
> an FTPD but is it as capable as wu-ftpd? Just
> because you can serve a file as quickly doesn't
> mean that it comes anywhere close to handling
> all the features that wu-ftpd. Sit down and try
> to write tens of thousands of lines in a
> so-called "modern language" and you'll be back
> to C.
I'm not calling myself an expert. It was a total joke to write the ftp daemon; it took me a weekend and it didn't involve any kind of research or learning. I just did it. It would be pretty easy to support the rest of what wu_ftpd supports, but as it is I am RFC compliant and I don't need to support any of the archaic character encodings or dubious "features" (like SITE EXEC) that wu_ftpd supports.
I did it as a proof of concept -- it's easy to rewrite software from scratch, and it's easy to do it in high level languages, and the resulting performance is more than acceptable. (And of course the code is nicer and the applications are more secure!)
I have written tens of thousands of lines in Standard ML, and I don't plan on going back to C! In fact, we're working on a compiler that's over 100,000 lines of code, and I couldn't imagine managing a similar project in C (nor can I imagine how long it would be!!)
Basically, it sounds like you have some more learning to do about what is out there.
> 1. Which implementation of Standard ML do you
> prefer? I use Linux.
What I do is to use SML/NJ for development, because it has better error reporting and an awesome interactive loop, and then compile my programs for later use with MLton.
MLton is a command-line compiler that produces standalone binaries. It makes much better code than SML/NJ does, except that it has awful error reporting because the front-end, well, isn't there yet. =) (One is in the works...)
SML is standardized; there's a book with a more formal description than I've seen for any language (and which the authors have proved correct), and because of this, the various implementations tend to be *very* compatible with one another. (No "undefined" or "implementation defined" behavior like C.) The language will probably undergo revisions like C and other languages do, but the community is very conservative about breaking old code.
The other poster is right -- SML is the language hacker's language. There are like 10 implementations of it, which is of course less than C and C++, but probably more than any other language.
If the feel of SML isn't right for you, I recommend checking out O'Caml, another brand of ML (at caml.inria.fr). They only have one implementation, and it is much more "hacking" oriented. Unfortunately, the O'Caml language is much less stable.
Thanks for opening your mind! =) I hope you like it, but if not, well, at least you tried. =)
AC writes,
> So are you saying that "use a different language"
> is a magic bullet that will fix all problems?
> Maintanance and security patches will not
> disappear, though they may be greatly reduced.
Of course I'm not saying it will fix all problems. It will fix all buffer overflow, string formatting, and heap corruption problems, which are where the vast majority of exploitable unix holes come from. That will greatly reduce the maintenance and security patches, yes. Isn't that good?
Purify is a great tool. It makes writing C and C++ programs bearable to me. Unfortunately, it'd be hard pressed to find this kind of error, since you'd need to *at runtime* replicate the conditions under which it's exploited (ie, passing in an id that is out of bounds), in which case you would have pretty easily figured out that there was a bug when your program crashed! In order to get security guarantees you'd need a more thorough static analysis of the code. (In general, the problem is undecidable, so the only practical full solution is to use bounds-checked arrays when the compiler can't determine that the index is always within bounds.)
I know you're just joking, but if you associate "modern" with Visual Basic, you need to do some more learning. There are loads of very interesting languages that are more powerful than C, as well as being easier to use.
AC Writes,
> So it still comes back to "don't do it if you
> don't understand the problems"? It is conceivable
> that someone could code a library poorly and cause
> a security problem, but according to you it rarely
> happens. This just leads me to believe that it IS
> okay if you know what you're doing. What you mean > to say is that one should use a more recent
> babysitting language if they're not capable of
> doing it without having their hands held.
Yes, in a sense. Here's how I would say it, though: we want to minimize the amount of trusted code. To a certain extent we need to trust the OS kernel, the compiler, and some libraries (depending on what language they're written in). That's because everybody makes mistakes, even smart people who know all about good C coding (like the OpenBSD/openssh people), and mistakes in C are often disastrous. Even people who are really good at C should avoid using C whenever possible, because it increases that trusted code base.
Actually, my group at CMU is working on trustless compilers (that is, compilers that produce checkable certificites that they did a good job). I'll be back in a few years talking about how this technology can reduce the (already few) security concerns with using a compiler. But for now, the biggest step is to keep people from increasing the size of the trusted code by writing applications in low level languages like C!
A friendly AC writes,
;-)
> Just open top and press T to sort by CPU time and
> S to turn on accumulation. The time displayed now
> is the CPU time accumulated by the processes and
> all the spawned children. On my server (up 2 days)
> it is 39 seconds for sshd. A bit more than I would
> have thought.
Great!
According to my computer, sshd has used about 31 seconds of cpu time per day since I booted it months ago. Considering that I always have several ssh connections into it and often transfer large files via SCP, I think that's not very much at all...
An AC writes:
> We write such servers in C for one reason:
> speed.
> The users demand it.
Do they?
Maybe cdrom.com demands it, but I have never heard any of my linux-using friends complain about how much CPU their ftpd or sshd is taking up. However, I have definitely heard them complain about how many patches they need to apply, of about getting rooted yet again...
> Java has too many resource requirements (CPU,
I wasn't really suggesting java, actually, although natively compiled java could probably work if you need the language to feel like C.
> Don't give me that "hardware is cheap line". The
> cheapest hardware is the hardware you don't have
> to buy.
Hardware is cheaper than the time it takes me to install all of these damn patches.
Actually, I don't care much about DOS "exploits", especially ones that require the attacker to expend resources to keep the attack up. It's pretty simple to flood my connection and make my computer unusable anyway.
In the case of SSHD, the situation you described wouldn't happen -- it spawns a new process for each connection, so an exception thrown in one wouldn't cause the others to be dropped. The attacker would merely be using up your resources.
A programmer in a modern language has plenty of choices, too. He can catch exceptions and restart the server. He can log them. And of course, the users are safe from being rooted until a patch is out.
You don't need an interpreter to do bounds-checking on arrays. For instance, SML (that's what I wrote my ftpd in) compiles to native code and has bounds checking. There also exist native compilers for java.
It's *much harder* to make a mistake in a compiler that causes an exploitable hole in software compiled with it than it is to make the same errors over and over in the applications themselves. (Just compare the number of compiler/library-caused exploits to the number of application exploits!)
> How did it cope with 18,000 simultaneous
;)
> connections? Did you use mmap(), sendfile() and
> friends on linux to get the best performance
> possible? How did the xfer rates compare?
I can't handle 18,000 simultaneous connections, but I don't think that 99% of people actually care about that. In fact, I don't think linux even supports 18,000 open file descriptors at the same time. My ftpd is intended for the home user who cares more about getting rooted than the low-level performance of his servers.
Yes, it uses sendfile to transfer files when it doesn't need to do EOL conversion. I'm easily able to fill my 100Mbps connection without breaking a sweat either way. (In my informal benchmarks, my server got exactly the same transfer rates as wu_ftpd).
> I actually do agree with your points mostly, but
> I would say "Don't use c for network apps unless
> you have a good reason to"
Well, ok, but what would be a good reason to?
One might be that you need to write a server that can really handle 18,000 connections. (Then, I hope that the users of your server have enough cash to pay someone to maintain them, apply security patches, etc.)
> In some ways SSH is a special case anyway. It
> has all the intensive maths stuff to do for the
> session key generation etc. Not a good idea to
> code that in (eg.) perl imo.
Yes, that's true. SSHD probably uses much more CPU than a typical network app. Yet (see my other posts), it really doesn't use that much anyway.
I wouldn't suggest writing it in perl, since perl has its own kinds of easily exploitable bugs. Also, the performance of perl is not in the 20%-100% category that I mentioned.
> BTW, out of interest, what is your "favorite
> modern language" ??
Standard ML. It's got loads of cool features like higher-order functions, polymorphism, datatypes, parameterized modules, and static typing (which also really helps to catch bugs). It's natively compiled and quite fast. You can learn about it at standardml.org. Hacker types might like O'Caml better, that's at caml.inria.fr.
I read the patch. It is not a buffer overflow in the traditional sense of strcpy, but it is an out-of-bounds write. You might consider that a buffer overflow, but maybe not. (Did I even call it that?)
Read my post again: I said that this error would NOT BE EXPLOITABLE in a modern safe language. You can still make the error, but the array write would be checked and would result in some kind of defined behavior (ie, an exception). This is true of buffer overflows as well.
Yes, that's true, but that doesn't imply that the situation is any better for C. In fact, I recall that libc had a globbing bug that caused an exploitable hole in ftpd (that was the reason I wrote this server in the first place) recently. Personally, I think it is extremely rare for a compiled language to have an implementation bug that leads to exploitable code. (I would be very interested in hearing examples, though, besides the one I mentioned.) As a practical matter, application-level bugs like the one in sshd are far far more common.
On a related side note:
I can't actually propose that people use this, because the technology is not that mature, but we are working on something called "typed assembly language" that would at least guarantee type safety of even the compiled code. (So that bugs in the compiler can't introduce certain kinds of security holes.) Check out http://www.cs.cornell.edu/talc/ for more info if you're interested.
OK, I'll tell you a bit about it.
> Does the compiler for your favorite modern
> language support binary code optimizations that
> let your ftpd run as quickly as a popular C ftpd
Yes, mlton (for my favorite modern language, SML) produces nice native code. I would guess that my server is no more than 20% slower than a C server implemented the same way.
> Does it have a GC thread that might kick in and
> cause delays?
There is no GC thread in typical SML implementations. GC happens when an allocation fails because the heap limit is reached. GC times are typically very small (especially when amortized against essentially free allocation compared to malloc()), and in fact the compiler I'm working on at school has a real-time GC. But do you really need real-time guarantees for an FTP server? The actual transfer portion doesn't even do any allocation.
My ftpd can easily fill my 100Mbps connection at school without breaking a sweat. I don't know how many users it can handle, though.
> Or did you just use bounds-checked C++ arrays
> and strings?
C++ wouldn't guarantee safety, even if using bounds-checked arrays and strings, since you can still do things like a double free of memory. Also, I find that C++ lacks many features that make writing software much nicer in SML, but that is of course a subjective thing.
That said, my ftpd would probably need more enhancements to support a *really* popular ftp site. But I think that would not be so hard; in fact, easier than C. My server is intended for the 95% of users who run a home machine and need to transfer files from time to time, but DON'T want to get rooted because they aren't up-to-date on patches. I would be VERY surprised if there is any exploitable bug in my daemon.
(Also, I think FTP sucks too. I just did it because it's a relatively simple protocol, and at the time (summer 2001) ftp servers seemed to have the highest profile security holes.)
Yes, I read it. The bug is that they write outside the end of an array.
A modern language would not catch this bug (unless you were using a data structure like a search tree instead of an array). However, it would make it NON-EXPLOITABLE, because a safe language would cause an error (ie, exception) on an out-of-bounds write, not corrupt the heap or stack and allow for an exploit.
> I cry BS. Your previous post claimed that
> performance was not a reason and yet I don't
> believe you. Wake up and stop acting as the HW
> vendors lobbyist.
Actually, I am a "modern languages" lobbyist, not hardware. =) But that's because I study and believe in programming languages, not because I have some kind of financial interest.
I'd love to respond to your post but I don't know what your point is. I guess all I can do is reiterate my point on performance:
1. sshd, running on my machine for about 8 months, has accumulated a mere 2 minutes and 30 seconds of CPU time. Of course, sshd forks off a new process for each connection, but all of the ones on my machine (some of which are at least a week old) have used 0:00. If someone knows a way I can measure the actual time spent by the daemon, I'd like to hear it, but I assume for now that it is *very small*.
2. I can easily fill my 100Mbps connection without breaking 2% CPU usage. (In other words, sshd is bandwidth limited, not CPU limited.)
3. Most home / small business users do not have 100Mbps connections, and could care less about the difference between 2% or 5% CPU usage.
4. However, most home / small business users DO care about having to download patches when their C programs contain buffer overflows.
5. Modern languages are not actually much slower than C. (I estimate worst case 2x slower, typically more like 20% for SML, which is what I wrote my FTPD in.) Being easier to write in, they also give more opportunity for high-level optimizations.
Therefore, I conclude that for almost every user, security is a more important concern than speed, at least as far as network daemons go. How can you argue the opposite?
This kind of bug would NOT BE EXPLOITABLE if sshd was written in a modern safe language.
9 013 for more info. Synopsis: There are some reasons to use C for a project, but none apply to network daemons. As a proof of concept, I rewrote FTPD in my favorite modern language; the source went from 24,000 lines to 3000 (including support code, like PAM_MD5 password encryption), took me only a weekend to write, and is 100% buffer overflow / format string / heap corruption free.
If the canonical secure software from the canonical secure software people has bugs like this, I don't see how anyone can argue that it's possible to write secure code in C. C makes it easy to make this kind of bug, and the bugs are often exploitable.
Check out my previous post and ensuing discussion on this http://slashdot.org/comments.pl?sid=24271&cid=262
I'm trying to raise awareness about this because I think it's a real obstacle to us having secure software.
> I have a hard time believing this... You're /dev/urandom?
/usr/src/linux/drivers/char/random.c.
> seriously implying that Linux servers (no
> keyboard) have an inferior
That's true, actually. Check out
/dev/urandom uses all sorts of hardware timings (like incoming packets, hard drive seeks, etc.) to produce add entropy to its pool. Typing or moving the mouse improves this, though I think "inferior" might be too strong a word since they are both nearly unpredictable anyway.
You don't have to program with objects in Java. You can program totally C-like code (you just have to do away with some unsafe C idioms that aren't very good anyway) in Java and just benefit from its type safety, memory management, portability, and large library of utilities.
I think maybe you just haven't had enough experience with Java? Having no core dumps, memory leaks, or buffer overflows really is a nice thing, especially for network apps...
Just because something is, doesn't mean it ought.
The fact that more people use C says little about the language except that it is older and popular. (Lots of people here would be upset if you applied the same argument to Linux versus Windows.)
For a network app, it is ludicrous to write in C. You have to deal with buffer overflows, memory leaks, cumbersome char*-handling routines, and portability problems. Out of it you get a whole lot more code for a lot more time and headache, and also some speed increase. During the same time, you could have been optimizing your Java (or whatever) program and improving things like data structures and algorithms (which as we all know is what *really* matters in performance).
I ran a freenet node for a while and speed was not a problem. Ease of development and security are much more important, and Java (or other, better modern languages) win hands down for these.
I don't think it's just the available content that's crappy, it's more about the content meta-data and how it's searched and ranked. Gnutella has essentially the dumbest search strategy of any P2P network: if the query appears in the file name, then it is a hit (and the hit is as good as any other).
Morpheus had reasonable meta-data and let you search based on other qualities. There's no real reason that a P2P network shouldn't support this, it's just that gnutella was a bit too early for that idea, and hasn't really caught up since then.