Slashdot Mirror


OpenSSH Local Root Hole

maelstrom writes: "Looks like someone's found a local root exploit for OpenSSH versions between 2.0 and 3.0.2. Seems as though its a one-off error, there is no public exploit, but there is sure to be one shortly. They aren't ruling out remote exploit. Recommending patching and upgrading ASAP."

2 of 490 comments (clear)

  1. Please stop writing network apps in C! by Tom7 · · Score: 5, Interesting

    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.

  2. Performance of network software by Tom7 · · Score: 5, Interesting

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