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

Comments

More Proof

[SquierStrat]

This is just more proof that nothing is 100% secure. :-) How does that saying go, if it can be devise it what? Some want to finish that for me?

Regardless of that though, I get on my knees and thank God everyday for SSH. It's saved me many many many hassles from simply forgetting to turn it off on computers on my home's network.

Re:More Proof

[Anonymous Coward]

Does it bother anyone else that the last THREE releases of OpenSSH were because of discovered holes? Not very encouraging from a group of induhviduals who like to pride themselves (and very loudly at that) on security.

Re:More Proof

[SquierStrat]

I'm sure it's more than the last three. Really, how many new features does SSH need? Bugs in an application of this type that is as mature as SSH tend to be security related. It actually makes me feel better that they're quickly responding to security bugs and doing new releases because of it.

Re:There goes OpenBSDs slogan...

[TheConfusedOne]

Ummm, RTFP!

It's a LOCAL exploit. You have to be logged in to exploit it.

Re:There goes OpenBSDs slogan...

[SonicBurst]

Actually, they may have to backdate that slogan. The problem has existed since version 2.0, so this hole would have existed since whenever they started shipping with at least version 2.0. And by the way, it is local exploit as of yet, however, remote exploitation has not been ruled out.

Commercial SSH

[Stavr0]

Does the same issue exist in Commercial SSH? The advisory makes no mention of it.

I assume it wouldn't be as it's on a different code base, then again 'assume means making an ASS out of U and ME'

Re:Commercial SSH

[jonnythan]

If you look at the patch, it's an error in the for loop.. a > instead of a >=.

If the same error existed in Commercial SSH, someone stole some code.

Re:Commercial SSH

[zulux]

If the same error existed in Commercial SSH, someone stole some code.

Not nesessarly true: OpenSSH and Commercial SSH have the same roots - http://www.openssh.com/history.html

Re:Commercial SSH

[Corgha]

Does the same issue exist in Commercial SSH?

A cursory glance through the code just now did not turn up anything.

However, even if an off-by-one error *did* exist in some function analogous to channel_lookup, the ssh2 binary is not setuid in the ssh.com version, so my guess is that a similar programmer error in the ssh2 code could not lead to an escalation of privileges (except perhaps by a malicious server getting your local privileges, but that's a different matter entirely).

The hostkey signing in ssh.com's ssh is handled by a separate setuid binary, ssh-signer2, which doesn't have anything to do with channels (not that it couldn't have other bugs, but it does have the advantage of having a smaller codebase to audit).

Note that I actually use both OpenSSH and ssh.com, so don't try to drag me into some flamewar about which one is "better." They each have their advantages and disadvantages. If you want to trash anyone, trash F-Secure; they really suck.

Re:Full disclosure = annoying.

[SquierStrat]

Script kiddiesprobably has known about this for a while. Full diclosure is not only a way to get the word out so that it can be quickly patched (which apparently it already is) but also a way to kind of force people into an upgrade. That way no one with an old version of ssh is sitting there being unknowingly used for DDOS attacks because they didn't know he needed to upgrade.

Full disclosure has its downsides,but the upsides pretty much cancel them out.

Re:linux patch available

[MrDingDong]

Its out there - at least on ftp.openssh.com. I built and installed 3.1p1 a couple of hours ago on Linux.

Correction: off-by-one

[MarkusQ]

Seems as though its a one-off error

One-off: Something done intentionally but with no intention of repeating; a custom product, sample, or prototype.

Off-by-one error: An error in enumeration, such as starting or ending a count at the wrong value (e.g. 0 vs. 1), counting the starting/ending value in a cycle twice or not at all (e.g. in counting a group of people which includes yourself), counting delimiters as opposed to the items delimited (e.g. the "fence post" problem), or any analogous error.

These are rather different! When I read the abstract my first thought was "how can they determine that?"

-- MarkusQ

Re:Correction: off-by-one

[Cardhore]

Time and time again the same exact off-by-one bug is made again and again in C and C++ programs. This is a design specific to C and C++ and Java, in which the first item in an array is accessed with an index of 0 (as opposed to 1 which is more intuitive). So the fifth element in an array is accessed with array[4]. The first element array[0] is accessed with the index 0. The second element is accessed with the index 1! No wonder this bug happens again and again.

Re:Correction: off-by-one

[Dwonis]

Sigh. The subscript of an array is the offset from its starting address.

Re:There goes OpenBSDs slogan...

[Chundra]

Ummmm, RTFP!

They aren't ruling out the possibility of a remote exploit.

OpenSSH site already updated?

[Noryungi]

Here is what can be found on their web site:

"OpenSSH 3.1 released March 7, 2002."

Hmmm... That was quick! Especially since the advisory reads:

Pine Internet Security Advisory

Advisory ID : PINE-CERT-20020301
Authors : Joost Pol
Issue date : 2002-03-07
Application : OpenSSH
Version(s) : All versions between 2.0 and 3.0.2

Pretty good job.

Re:OpenSSH site already updated?

[leviramsey]

The vulnerability was sent to the OpenSSH team a few days ago. It was not publicized until a fix was in CVS.

Re:OpenSSH site already updated?

[BlowCat]

Good thing that it's not a remote root exploit. Otherwise www.openbsd.org would now read:

Four days without a remote hole in the default install!

Not sure if OpenSSH is enabled by default though.

Re:OpenSSH site already updated?

[passion]

If you act quick, you'll notice that you can't download the new source code from all the mirrors yet...

Re:OpenSSH site already updated?

[Tuzanor]

Not sure if OpenSSH is enabled by default though.

It is. Luckily, so far it doesn't look like a remote hole. Even if it was, OpenBSD would still have a far better track record than any other OS out there.

Re:OpenSSH site already updated?

[sheetsda]

OK, I'll bite.

The OpenSSH people corrected the bug in their own source, which they would have had access to even if it was closed.

Sure, if they found out about it before a blackhat did. There's a good chance they wouldn't have. And anyone could've corrected the issue and submitted a patch; in OSS there may be a patch before the public even knows there was a vulnerability.

The vendor was notified ahead of time, which is one of the things that MS has been campaigning for. Why aren't we beating up on the guy who released this to the vendor first and not to the community immediately?

There's a policy among bug reporters to give the author a reasonable period of time to fix a bug before releasing it. MS gets that grace period about as often as everyone else, but they're so slow at getting out patches that the vulnerability runs rampant. If an OSS project is slow at getting patches out, someone else takes it upon his or herself to write a patch. Its sort of a self-correcting system.

smallest possible patch

[bill_mcgonigle]

For you guys too lazy to read:
http://www.pine.nl/advisories/pine-cert-20020301.t xt
( I was going to post the patch here, it's really small, but apparently slashcode doesn't know what the blockquote tag is for, despite claiming it's supported)

But this isn't just an attempt at karma whoring, there is a point. When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that Microsoft secured their software over the last month?

Re:smallest possible patch

[ghjm]

When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that C is the right language to do coding in?

Re:smallest possible patch

[Alsee]

== vs. =

No, it is &GT vs. &GT=

-

I can't wait for djbssh

[Russ Nelson]

I can't wait for the Daniel J. Bernstein version of ssh.
-russ

Re:I can't wait for djbssh

[Anonymous Coward]

you mean the one that requires you to set up 3 accounts for the client, 3 accounts for the server, and comes with its own inetd replacement?

Re:I can't wait for djbssh

[biot]

It would be incompatible with the rest of the world's ssh implementations, of course, but I guess he'd write a DJB-RFC to take care of that.

Re:I can't wait for djbssh

[tzanger]

you mean the one that requires you to set up 3 accounts for the client, 3 accounts for the server, and comes with its own inetd replacement?

You forgot the part about the code being totally undocumented (including no descriptive variable names whatsoever) and that it will only securely talk to djbssh clients since ssh is a useless tool of a protocol that should have never been passed as in RFC. :-)

qmail is an awesome program. Too bad it's almost impossible to understand the code. :-(

Re:I can't wait for djbssh

[Russ Nelson]

If "incompatible" results in "is secure", then it's worth having to install it everywhere. I mean, ssh is incompatible with telnet, and yet you installed ssh everywhere you needed to?
-russ

Re:I can't wait for djbssh

[Russ Nelson]

It's not as bad as all that. First, there just aren't so many global names that you need to have them be descriptive, but they are reasonably so anyway. flagcritical is set when you're in a critical section of the smtp dialogue.

Most of the global names are quite descriptive, e.g. byte_copy(). What does it do? Copy bytes. case_lowers()? Lowercases strings.

It's really not that bad once you spend a bit of time on it.
-russ

Re:I can't wait for djbssh

[Electrum]

And since nobody would use it because of the incompatibility issues, it would be REALLY secure. He could then afford to offer a $1000 bounty to anyone able to 'sploit it. 8-)

qmail is the second most common SMTP server on the internet, so it's hardly fair to say that nobody uses it. He can afford to offer guarantees because there are no security holes.

Re:I can't wait for djbssh

[Fjord]

Blah. Nevermind. This one is way more recent (didn't watch where I was). It still lists it at 3rd, but says
"qmail now accounts for more addresses than Exchange, and almost as many as all Microsoft SMTP products" although I don't understand why it lumped Exchange and IIS SMTP together to make it 2nd.

Re:I can't wait for djbssh

[dougmc]

How are you getting that? This page [cr.yp.to] seems to place it 24th (removing "Unknowns").

Did you even read the page? Allow me to show you the relevant header line --

Date: 29 Nov 1996 08:51:00 GMT

Last I checked, 1996 was a Long Time Ago [tm] in Internet Time [tm].

Re:I can't wait for djbssh

[krogoth]

You forgot to mention the complex directory structure that uses files as variables...

Re:I can't wait for djbssh

[shogun]

Well if your really good at doing complex math in your head you can always login to an sshd server with a simple telnet client...

Re:I can't wait for djbssh

[Russ Nelson]

Must ... reply ... to ... qmail ... post ....

-russ

Re:I can't wait for djbssh

[dougmc]

Yes, I read it. Well after I posted my reply.

It wasn't there when I started my reply. Remember, we're talking about a period of mere minutes here. Your correction came in only 11 minutes before I pushed for the final time.

Re:I can't wait for djbssh

[Dwonis]

Would you like to explain what is wrong with this approach?

Re:linux patch available

[Asgard]

Looks like it is already availble in tarball and RH72 RPM format.

Re:Full disclosure = annoying.

[Sarin]

Nah they don't.;) But I'm working on exploit code as we speak.

Re:Full disclosure = annoying.

[SquierStrat]

I'm going to disagree. Script kiddies don't look at security focus, they go looking for things to exploit the vulnerabilities written by well skills hackers/crackers. If they waiting any amount of time to upgrade, the only people who would have upgraded would have been people like me who download and install the latest version of EVERYTHING just because they can. The people with the bandwidth that need to upgrade wouldn't do it, because they can't afford the service outage. With full disclosure they'll be more or less forced into upgrading. I'm sure the multi-platform release will be done in a few hours also.

Re:There goes OpenBSDs slogan...

[Gabey]

You must be a troll, but for the benefit of others, OpenBSD doesn't install telnetd, named, or sendmail by default.

Please stop writing network apps in C!

[Tom7]

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.

Re:Please stop writing network apps in C!

[MartinG]

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?

BTW, 24,000 lines is a hell of a lot. If you want to compare like for like, have a look at vsftpd by Chris Evans. It's written entirely in c. Have a read of the source - it's quite interesting how it has been done. I would be surprised if you could find a buffer overflow.

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" and also "don't use c for network apps unless you _really_ know the hazards"

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.

BTW, out of interest, what is your "favorite modern language" ??

Re:Please stop writing network apps in C!

[coyul]

Did you even look at the patch?

--- channels_old.c Mon Mar 4 02:07:06 2002
+++ channels.c Mon Mar 4 02:07:16 2002
@@ -151,7 +151,7 @@
channel_lookup(int id)
{
Channel *c;
- if (id < 0 || id > channels_alloc) {
+ if (id < 0 || id >= channels_alloc) {
log("channel_lookup: %d: bad id", id);
return NULL;
}

You want to explain to me how any "modern safe language" is going to stop me from saying 'greater-than', when I really mean 'greater-than-or-equal-to'?

Re:Please stop writing network apps in C!

[abaptist]

If you look further down in the patch, it then references an array with offset 'id'. In a language like Java this would throw an ArrayIndexOutOfBounds exception, NOT read random memory and possibly cause a crash.

So in fact a stricter language would fix this problem.

Re:Please stop writing network apps in C!

[smallpaul]

Someone please moderate the parent up! I could repeat what it says and karma-whore but I'd rather help the poster get his intelligent argument promoted!

Re:Please stop writing network apps in C!

[Tom7]

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.

Re:Please stop writing network apps in C!

[adubey]

In languages without pointers, assuming there are no compiler bugs, there will be no heap corruption.

In languages with array bounds checking, assuming there are no compiler bugs, there will be no undetected buffer overflows.

The original poster was saying, with a good enough language, there are certain classes of bugs you don't have to worry about.

Re:Please stop writing network apps in C!

[Tom7]

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

Re:Please stop writing network apps in C!

[Tom7]

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!

[Mignon]

further down... it then references an array with offset 'id'

Has anyone been able to catch this error with a tool like Purify? Language arguments aside, the reality is that the program is already written. In my experience, debugging a complex existing program with good tools is easier than writing the same program from scratch.

Re:Please stop writing network apps in C!

[Tom7]

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!

Re:Please stop writing network apps in C!

[bentini]

SML/NJ is done at Bell Labs amongst other places. Fantastic. Try googling it.

Will I still be able to compile my code in 15 years like I will with ANSI C or Fortran 90? I guess what I mean is are there set-in-stone ML standards that assure me that future tools will work with code I write now?

Surprisingly enough... "Standard ML" is in fact STANDARD. ML has been around for a while, since at least the 80's and I believe before that. Will a compiler in the future still handle the same language? I hope not. I hope that ML remains vibrant. But will there exist compilers for this language in the future? Yes. There will. A lot of people like ML, especially the type of really smart people who port languages to new platforms well and efficiently.
-Dan

Re:Please stop writing network apps in C!

[krogoth]

It would only detect a side-effect of the problem. That would have eliminated this problem, but not this type of problems.

Re:Please stop writing network apps in C!

[ecampbel]

While switching over to a safer language would solve the exploit problem, it wouldn't solve the any of DOS problems. If a program had an exploitable overflow, it would be easy for a nefarious hacker to repeatedly bring it down (albeit safely) by exploiting it. Thus, the severity of any bugs would be lessoned, but if one wanted to keep their server stable and performing at a high level, an equal amount of maintenance and security patches will have to be installed.

Re:Please stop writing network apps in C!

[Alex Belits]

And in languages without anything at all there can't be any bugs.

The problem is, lack of any of mentioned things isn't without a price -- it's either performance or functionality. And also it's worth to remember that none of so-called "modern" languages are self-hosted, they all are written in something else that has all those features they are so proud of lacking. That code is usually unbelievably hairy, and has no chance to even be audited by a human.

Re:Please stop writing network apps in C!

[adubey]

Sir,

You have no idea what you're talking about. All modern languages are Turing-complete, most are self-hosting or at least have compilers written in other "modern" languages such as SML or Haskell, and often compile straight to assembly. I have no idea where you get the impressed that NONE of these languages are self-hosted.

Moreover, the language the original poster was talking about - SML - offers a number of abstractions that simply aren't there in C. In comparision, C is the one with missing functionality. This is why the SML version of the code was so much smaller.

You may lose some speed by going to a higher level, but for 80% of the code out there, a 20% slowdown doesn't even register on today's processors. The time you save coding, moreover, gives you more time to optimize your algorithms.

Re:Please stop writing network apps in C!

[Alex Belits]

You have no idea what you're talking about. All modern languages are Turing-complete, most are self-hosting or at least have compilers written in other "modern" languages such as SML or Haskell, and often compile straight to assembly. I have no idea where you get the impressed that NONE of these languages are self-hosted.

If the self-hosted implementation is not usable, and not self-hosted one is used instead because of that, language is still not self-hosted. Also self-hostedness of the compiler is of little help when runtime has huge amount of native code written in a manner that doesn't allow any hope for security (ex: Java).

Moreover, the language the original poster was talking about - SML - offers a number of abstractions that simply aren't there in C. In comparision, C is the one with missing functionality. This is why the SML version of the code was so much smaller.

By functionality I mean not the functionality of the language but functionality of the program -- most of functionality that the program has is based on what it can do with the OS, and all "modern" languages usually pretend that 80% of what OS (or at least Unix) can do, isn't there (ex: Java's interface to anything networking-related is horrendously crippled by Java's designers idiosyncarsies).

Re:Please stop writing network apps in C!

[dvdeug]

lack of any of mentioned things isn't without a price -- it's either performance or functionality.

Better languages will offer a choice to turn off bounds checking or garbage collection in specific places, if you really need that speed. Also, it's easier for a compiler to optimize away automatic bounds checking rather than manual bounds checking, since it knows exactly what it's looking for.

But, yes, there's always tradeoffs. But I don't feel a need to provide the fastest system for script kiddies to use as a DOS platform.

And also it's worth to remember that none of so-called "modern" languages are self-hosted, they all are written in something else that has all those features they are so proud of lacking.

So I was just imagining SmallEiffel and SML/NJ.

Re:Full disclosure = annoying.

[gehirntot]

Full disclosure is where the script kiddies get their tools.
Now this is public knowledge, an exploit will be available within hours.
You do not know what you are talking about. Full disclosure has greatly improved security awareness and turn around time for fixes. If you want to turn your back on full disclosure, you are heading back into the middle-ages of computer security.

This should have been fixed before it was announced, and a period of time waited for people to upgrade.
The information was leaked by someone who jumped the gun. That is the reason why the relase and advisory happened today instead of Monday. Nothing to be done about it. Instead of bitching, fix a bug in your operating system and send a patch to the developers. Much more useful behaviour for all of us.

Of course, you should be running with ln -s AJ /etc/malloc.conf anyway. It will fill freed memory with junk, and quite often finds conditions where memory is referenced after it has been freed. In that case, there is no problem anyway. If your operating system of choice has not support for malloc debugging, looby your developers, it is a very useful feature.

OpenBSD upgrade.

[saintlupus]

OpenSSH 3.1 was released this morning. The info and tarball for OpenBSD systems is available at:

http://www.openssh.com/openbsd.html

Mine's compiling now.

--saint

RPM's Compiled For i386

[Mr_Perl]

Help yourselves:

http://www.geniusweb.com/RPMS/

SSH 3.1p1 RPM's compiled without gnome-askpass, everything else is default vanilla.

Re:RPM's Compiled For i386

[Mr_Perl]

Done. The reason I put em up was the only mirror that has the active file is ftp.openbsd, and it will probably be swamped pretty promptly hereafter.

Did a md5sum that anyone's free to check against the original also for the paranoid among you.

Re:RPM's Compiled For i386

[Scoria]

Oops, it appears that in my haste I overlooked a critical step of installation.

After executing the command "tar xvfz openssh-3.1p1.tar.gz", you must then type "cd openssh-3.1p1" (without quotations). :)

Re:RPM's Compiled For i386

[Mr_Perl]

BTW for those who want to do this themselves it's not hard. If you have a server without gnome libs installed you need to do it this way:

rpm -ivh openssh-3.1p1-1.src.rpm

then edit /usr/src/redhat/SPECS/openssh.spec
and set the options as you like, in my case I changed the 0 to a 1 where the gnome-askpass bit is.

Then use rpm to build it, cd to the SPECS directory on your system (may also be /usr/src) and do:

rpm -bb openssh.spec

Then watch the messages at the end which tell you where the finished RPM's are. Usually ../RPMS/i386/

For those who want the gnome-askpass, just do

rpm --rebuild openssh-3.1p1-1.src.rpm

Re:RPM's Compiled For i386

[Siva]

I've got zlib 1.1.3 installed...

ah, but do you have zlib-devel installed (assuming mandrake splits up libraries and headers into two packages like RH)?

--Siva

FreeBSD affected; patches available

[Dom2]

Unfortunately, I can't post the advisory here due to the lame lameness filter. But here are the patches:

ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/S A- 02:13/openssh.patch
ftp://ftp.FreeBSD.org/pub/Fre eBSD/CERT/patches/SA- 02:13/openssh.patch.asc

Execute the following commands as root:

# cd /usr/src
# patch < /path/to/sshd.patch
# cd /usr/src/secure/lib/libssh
# make depend && make all
# cd /usr/src/secure/usr.sbin/sshd
# make depend && make all install
# cd /usr/src/secure/usr.bin/ssh
# make depend && make all install

If you've got the ssh port installed, check out the advisory for details on what to do:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0 +c urrent/freebsd-announce

Does this affect non-suid root clients?

[Dast]

I don't see any mention of non-suid clients in the advisory? Does any fellow /.er know if such clients are vulnerable to escalation of privileges?

There are some reasons to use C for a project

[MrFredBloggs]

Phew! Thought i`d wasted the last 5 years of my professional life using the wrong language!

Visual Basic

[wiredog]

Has all the features any Modern Programmer could want. And it has the Highly Secure .net framework built in. What more could you want?

Re:Visual Basic

[killmenow]

Plus, you don't have to mess with that "windowless" crap you get with those braindead console apps. God, those are so hard to use. I mean, if you can't point, how can you click?

Re:There goes OpenBSDs slogan...

[Mordac the Preventer]

"Four years without a remote hole in the default install!"

Is ssh server enabled in the default install? I would think (hope) not - You don't want to run services that you do not need, and does a workstation need sshd?

Isn't this a bit dodgey?

[SomethingOrOther]

Errrrrm
Isn't it a bit dogey just grabbing and installing a binary (rpm) from an untrusted source (ie you) for security software like SSH ?

I'll get my source code from a reputable mirror and compile it myself thanks.

Re:Isn't this a bit dodgey?

[Mr_Perl]

Yup, but there are folks here who know and trust me. =)

If you're concerned, just don't download em.

Re:Isn't this a bit dodgey?

[Mr_Perl]

Haha, gimme a break. =) I guess I should know better than to let my helpful side show on slashdot. Download mine or go build it yourself, sheesh.

*** Help on upgrading a remote server?

[TomatoMan]

Since I'm probably not the only bonehead out there in this situation, could someone more knowledgable than me advise on proper procedure for upgrading OpenSSH on a remote server via an ssh connection?

My server runs 2.2.0p1. I've got the 3.1p1 source and I'm ready to go. I'm always afraid that a glitch in the build procedure - or even a success - could replace the existing 2.2.0p1 sshd binary while it's talking to me and cut me off, and if something goes wrong in the process, leave the server unreachable, which means a long drive to the colo facility to sit down with a keyboard and monitor.

Can anybody help? I've never been able to find a clear answer for this question.

TIA.

Re:*** Help on upgrading a remote server?

[Bluecoat93]

Known to work on Solaris, OpenBSD, and Linux. YMMV elsewhere, but it should work fine.

1) Use SSH to log into your server.

2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.

3) Run 'ps -ef | grep sshd' or 'ps auxw | grep sshd' (depending on your UNIX flavor)

4) find the sshd instance with a parent process ID of '1' -- this will be the actual daemon spawend by init. The other process will be the one spawned by sshd itself to handle your connection.

5) kill

6) the parent sshd process will terminate, but yours will stay running

7) start up the new sshd

8) from another workstation or window telnet to port 22 on your server and verify that the version number reflects the new version.

9) from another workstatino or window, ssh into your server to make sure you still have access.

10) close your original ssh session

I've used this exact process to upgrade many machines at remote locations. As long as you verify that the new sshd is running before you close your existing connection, you should have no problems.

Re:*** Help on upgrading a remote server?

[gid]

Sure I do it all the time, I'd suggest install the newest openssl first. Then unpack openssh and cd into the dir:

./configure --with-md5-passwords --etc etc etc, configure options here
make
cat /var/run/sshd.pid
kill <pid from above command>

This kills off the master ssh process, you will still stay connected, just don't kill off any other ssh processes.

Now:

make install
/usr/local/sbin/sshd (or wherever you installed it to start it up)

Don't dissconnect yet! Try sshing in again and see if the machine is accepting connections, if not, you might have to try giving it different ./configure options, like --without-pam, --ipv4-by-default etc

If it's your first time try it remotely, you might not want to do this on a server that's a 3 hour drive away. :) FYI, I've already upgraded 3 servers this way just 30 minutes ago, still have many more.... :(

Re:*** Help on upgrading a remote server?

[TomatoMan]

2) Find the parent sshd process and kill that one only! (don't do a killall) "pstree -p" is good at that.

Am I hosed if I start sshd with inetd? In the display below, which is the parent process? Or do I have to kill them all?

(stripped of nearly all useful information to get around the useless, brainless lameness filter: hopefully good enough. The "|" and "`" are supposed to line up under the "+" so that all of the sshds are in the same column, but we can't use <pre> tags so we can't do that.)

inetd(408)-+-sshd(5980)
|-sshd(9627)
`-sshd(23148)

Re:*** Help on upgrading a remote server?

[Neon Spiral Injector]

If you replace the openssl while SSH is running it will detect the version change and kill all running sshd sessions. Then you'll have a half installed openssl and not be able to start sshd.

You don't want to upgrade the SSL libs remotely.

Don't ask how I know. :P

Re:*** Help on upgrading a remote server?

[yason]

2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.

Ahem. Wrong. Linux is nice, it will keep the old version of the binary accessible for the running image as long as there are any, but e.g. SunOS doesn't do that. Modifying the binary will cause wrong code to be read from the disk whenever the OS reads the binary file again. This will happen for example when the code has been paged out from the main memory after which the program becomes active again and the OS loads the code of the process from the original binary. Try this:

cp /bin/cat foo ; ./foo
Hit ctrl-z to suspend the copy of cat, truncate the file:
echo > foo
and type
fg
to resume the copy of cat -> boom, segfault most likely unless the machine is very idle and not having paged out the code section of "foo" out.

Re:*** Help on upgrading a remote server?

[tzanger]

f you replace the openssl while SSH is running it will detect the version change and kill all running sshd sessions. Then you'll have a half installed openssl and not be able to start sshd.

Not entirely true; I had one server do this to me, but the six others that I upgraded work fine... update openssl, update openssh, kill running sshd parent, run new one, verify, exit. no problems.

If anyone can exlain why this one system may have done that, I'd appreciate it. It did this tlast time around too. :-(

Re:*** Help on upgrading a remote server?

[Dahan]

So use install(1), or rm the old binary first.

Re:*** Help on upgrading a remote server?

[mcrbids]

Ouch!

You do things the hard way! I much prefer:

1. rpm -Uvh openssh*.rpm
   
2. /etc/rc.d/init.d/sshd/restart
   

   We could exit here, but I like to be sure..

3. ssh localhost login, make sure it works ^D
   
4. ^D
   

Sooooo much easier....

-Ben

Re:*** Help on upgrading a remote server?

[Neon Spiral Injector]

A little late to reply, but just incase anyone looks.

Older versions of OpenSSH didn't have this security feature. You probally will run into it every time now.

Performance of network software

[Tom7]

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

Re:Performance of network software

[dvdeug]

Modern language does not mean interpreted, and especially doesn't mean Java. There are plenty of open source modern languages - Ada (GNAT), ML (SML, O'Caml), Eiffel (SmallEiffel). All compile to executables, and produce efficent executables.

They do not allow sufficent control over program behavior to make the kind of assurances that high-performance applications need to make.

If you're worried about that, why do you use the inefficent language known as C? There's no better way to get efficency and low-level control than Assembly.

Sit down and try to write tens of thousands of lines in a so-called "modern language" and you'll be back to C.

Really. I haven't reached the tens of thousands mark yet, but I've written thousands, and when I curse Ada, it's because it doesn't have garbage collection and because it encourages fixed length, single-byte strings over unbounded Unicode strings. Both C problems.

Re:Performance of network software

[dvdeug]

The issue is not necessarily efficency. It's about control.

And again, assembly gives you more control than C. If it didn't, then you wouldn't see Linux (the kernel) developers show up on the GCC lists every so often complaining about the latest (ISO C legal) optimization that broke Linux.

The fact is, you can do ANYTHING in C.

Duh. In its weakest sense, that's trivially true - all programming languages have the same power as a Turning machine. In a stronger sense, it's not true - there are parts of the kernel written in assembly because they can't be written in C. There's no way to use the hardware BCD commands from C, short of inline assembly. (And, yes, C is not the only language to let you use inline assembly.)

If you want garbage collection, get a library, or make your own. [...]

And then I end up using a kludgy half assed solution that's either non-portable, painful to use, and/or increadibly slow. Gee, thanks. A properly garbage collected language will be faster and more reliably garbage collected than anything you can do with C.

it's not any worse than using a language that supports those features because in all likelyhood that "other" languages was written in C.

Huh? Besides the incorrect assumption that all compilers and interpreters are written in C (a huge number bootstrap), there are worlds of difference what can be done with built-in syntax and hacked up macros and functions. The built-in syntax usually runs faster (since the compiler knows exactly what to look for to optimize), is usually more convienent to use, and nobody accidently uses malloc or native arrays if GC and bounds checking are built in.

Re:Performance of network software

[dvdeug]

When in the world did Ada become a modern language???

Why isn't it a modern language? It's got object orientation, templates, all the features you'd expect out of a modern language.

I beg to differ about C being less efficent than assembly. Anything that can be done in assembly can be done just as effectently in C.

Can I have what you're smoking? A person with unlimited time can always beat a compiler at optimization, if only because he can look at the compiler's output.

C is a great language. C++ is a better language because it has many more features.

So you can measure the goodness of a programming language by counting features? Then PL/I is much better than C. Why did so many people use C then?

C++ has any (and probably more) features than SML, ADA, & Eiffel.

I take it you aren't familiar with those languages? Among other things, Ada has tasking and Eiffel has preconditions and postconditions, neither of which are in C++.

A language shouldn't be gauged on how idiot-proof it is though.

There are no perfect programmers. If many good programmers make a particular style of error that results in a root hole because of a language, perhaps some other language should be used. The other solution, hire only perfect programmers, doesn't work because they don't exist.

Re:Performance of network software

[dvdeug]

The object oriented paradigm isn't the only paradigm out there.

True, and interestingly enough, Ada supports all the paradigms that C++ does - procedural, object orientated, generic.

You may say it's object oriented

Are you claiming it isn't?

but it doesn't support MI, partial specialization, or operator overloading

Partial specialization has nothing to do with object orientation, and Ada does support operator overloading, and always has.

The fact is that there is an aweful lot of code written in C/C++ and the percentage of exploits to number of SLOCS of C/C++ is not as high as many would like you to believe.

That's not an interesting number. The absolute number of exploits is much more interesting, and it's much too high, and too many of them are the same old buffer overflows.

having access to those features allow for extremely efficent code to be written by more experienced programmers.

But I have access to those features in Ada. I just have to turn array overflow checking off. Unsafe features just aren't the default.

Re:Performance of network software

[zerocool^]

hrm
is it bad if sshd has used about twice the time that httpsd has?

~z

Yes, of course I read the patch.

[Tom7]

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.

Re:Yes, of course I read the patch.

[adubey]

Right. You have two choices:

1) Getting a root exploit and not knowing about it.
2) Getting a DOS attack, and having a log file say exactly how the attack was occuring (because SSH was logging all the errors into a file).

Hmm... maybe number 2 isn't a panacea or placebo, but maybe it is better than you're making it out ;)

Re:Yes, of course I read the patch.

[Florian Weimer]

A modern language would not catch this bug

Languages with array types tend to avoid such bugs because you can test for the validity of an array index using special constructs ("Channel_Id in Channels'Range" or something like that), and you don't have to resort to comparision operators.

Re:Full disclosure = annoying.

[SquierStrat]

If you had a T-1, I'm sure you know how. Since when does security focus distribute exploit code? Script kiddies scavenge ready made exploits, Security Focus doesn't provide that.

FYI: my box may have been exploited by this

[umoto]

Two weeks ago my Mandrake box, connected to a cable modem, was rooted. The only port open to eth0 was ssh (openssh-3.0.2p1). I analyzed the logs and they indicated someone had spent an hour trying to exploit various SSH bugs that have been fixed in the past. Then there was an 8 minute pause before "linsniffer" was installed and eth0 went into "promiscuous mode".

I haven't been able to verify openssh-3.0.2p1 was truly the cause, but it seems likely. This may have been the remote root exploit which the advisory "does not rule out".

Should be "between vers. 2.0 & 3.02 **INCLUSIV

[Zocalo]

Given that OpenSSH.org just released v3.1 to fix the exploit.

And I thought it was just about time to go home too. Now I'm warming up my compiler... :-(

No need to give up

[Fritzy]

As I scan through, I see several posts of people giving up hope, and even those showing signs of dispair because they have an ssh server that they don't want to remove that service from. Fear not my friends. Simply download the rpms (openssh, openssh-askpass, openssh-clients, openssh-server) and give it an old rpm -iU openssh, openssh-askpass, openssh-clients, openssh-server It'll update everyting for you /and/ restart your services real quick. Or, if you feel like being a man, you can compile the sucker, and copy over the older versions and restart the services manually. Either way, there is no need to dispair. You're not going to lose your ability to serve ssh securely to your users. Of course, this comes as no news to most of you, but just wanted to explain it to the people who didn't seem to understand.

Re:Full disclosure = annoying.

[andy@petdance.com]

This should have been fixed before it was announced, and a period of time waited for people to upgrade.

If it's fixed, then that in itself announces what the fix is. Just do a diff between vN and vN+1 and see what changed. "Hey, look, it's a buffer overrun they fixed."

Security through obscurity is no security.

I'm going back to telnet

[cluge]

How many exploits can one "secure" softare package have? I mean jesus, BSD is fairly secure and this project is supposed to have BSD style security checks. What went wrong.

Information like this makes me

A. Consider purchasing SSH from a commercial source because the AMOUNT of problems with it is less

B. Going back to telnet!

Not many people out there with sniffers between my box and my connection. Lots of l33t haX0rS with worms probing port 22.

Re:I'm going back to telnet

[gypsyx]

Think back to the recent /bin/login CERT advisory. Telnet and the R-services use /bin/login. Telnet was, therefore, exploitable on many boxes.

Re:Full disclosure = annoying.

[SquierStrat]

How many clueless users are going to a) have a dedicate server and b) be using ssh in the first place?

About the server

[Tom7]

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

Re:Full disclosure = annoying.

[Vincepb]

A hell of a lot.
(I'm in the webhosting business myself...)

Vince.

No, you're wrong...

[Tom7]

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.

Re:Full disclosure = annoying.

[SquierStrat]

Well then you should be responsible enough to tell you users they need to upgrade and/or to do it for them. It's not that difficult, my little brother and sister do it all the time for me in linux when I'm away. I just say type this and this and this and ttyl. Not very difficult. But truly, how many of them use SSH? I somehow don't buy that absolutely clueless people are using some like SSH. The two are mutually exclusive it would seem to me.

Couple things

[clump]

The most important thing to realize is that when a machine is comprimised, it cannot be trusted. You may think that you were running only OpenSSH but you may have been runnning other services started a long time ago. I would be curious to know what kind of logs you had to go by to see what this attacker did. Slightly-smart ones clear every trace.

Also of note is that this particular advisory is known only to affect local users. I don't think this particular bug is the cause. It may have just been a friend shoulder-surfing.

If you want to do analysis on a cracked machine, you should place the hard disk into a different machine and examine the contents.

Denial of Service vs. Root Exploit

[Tom7]

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.

Or use Kerberos

[fw3]

Kerberos developed at MIT and used in many (most?) large-scale production systems. Source available.

Kerberos has been around since '88, opensource (MIT license). It is not developed at the breakneck pace of the more modern SSH and to my knowlege has had fewer exploit bugs in 14 years than the assembled flavors of (commercial *&* open) SSH have exhibited in the last 2 years.

Krb5 is not slick as SSH, you can't use it for a poor-man's VPN; it uses a more expensive cypher (3DES) for both auth and fully encyphered network connections. Rsh, rlogin rcp all available with strong encryption. It's not as easy to setup, nor well suited to very small networks but for my money where applicable it's a far more solid solution.

And yeah OpenSSH's seriously checkered security record has done very little to make me think of applying OpenBSD .. thoughts?

Exploiting scenario

[pmf]

After analysis, I can say, that this vulnerability is 4 bytes heap overflow, VERY hard to exploit. Problably only Linux will be affected, because Doug Lea's malloc() depends on control structures located just after malloced buffer.

Re:Exploiting scenario

[pmf]

Each user has it's own fork()ed copy of sshd running, so overflow can occur only in your own copy of sshd. The ONLY way to exploit it is to fool glibc free() by overwriting fd->prev or fd->next pointer.

Re:Being helpful and encouraging security risks

[Mr_Perl]

You may have had the best intentions, but in reality (by uploading untrusted SSH binarys) you are encouraging people to take stupid risks.

They're very trusted. I downloaded them from the vendor's site and built them myself. Anyone who trusts me (note the link to my homepage if you care to do research on myself or my company) can go download them. Anyone who has doubts can wait a week for their distro to put out updated RPMS.

I think anyone like yourself can be an armchair "security expert." Come up with something USEFUL yourself instead of whining at those of us who are trying to make life easier for others.

MacOS X

[jjeffrey]

MacOS X 10.1.3 (latest version as of now) includes OpenSSH 3.0.2p1. I wonder how long before Apple get a patch out... I don't really want to rebuild from source on MacOS X, even though it did only take 5mins to build 3.1p1 on my FreeBSD firewall.

Re:MacOS X

[ChrisDolan]

No luck with fink.sourceforge.net either. They're at 2.9.9p2.

Ha ha, ignorance is funny.

[Crag]

If there were such a thing, it would use ucspi-tcp, not an additional inetd replacement, and like qmail. Ucspi-tcp provides functionality that inetd doesn't, and maintains the "connection handling" vs "services" separation that inetd provides. It is a natural step to replace parts which do not provide whatever is needed, and to reuse those parts.

Also, qmail's division of the jobs into multiple independant modules makes security analysis and improvement of the whole package much easier. Every module is completely and explicitly documented in man pages and numerous web pages, so even a less advanced programmer like me can write a wrapper for a module to add funcionality to. The risk of unexpected consequences is FAR lower because modules have their own UIDs.

If there's a good reason for it, why not do it?

Re:There goes OpenBSDs slogan...

[segmond]

In theory everything is possible, until someone demonstrates that possiblity in reality. OpenBSD is still right with her claim.

Re:There goes OpenBSDs slogan...

[ncc74656]

Is ssh server enabled in the default install? I would think (hope) not - You don't want to run services that you do not need, and does a workstation need sshd?

How else are you going to do remote maintenance on it? What are you going to use for remote access to your stuff? You sure as hell don't want to use telnet.

(If you think you'll never need remote access, though, you can leave it out. As for me, I like the ability to tap into my home machines anywhere I can run SSH and VNC. I even have Win32 SSH and VNC clients on my webserver that I can download on a random Win32 box (even many public systems) to access my systems (both Linux and Win32) at home.)

How is this offtopic?

[Pinball Wizard]

I just got the exact same thing compiling for OpenBSD 2.7. Yes I installed the patch first. Any ideas?

ignorance and self deceit

[wallshot]

Over the course of my years of slashdot reading, I have noticed that while many are quick to point out interesting tidbits on the negative aspects of OS's, Software, and Hardware. While these reviews and notes are useful, it seems that nothing is as unbiased as it might seem.

MS exploits often announced on here (yes i like to know about them) and in this case open's dev team mistakes are also what I consider news, however I cannot remember the last time anybody pointed out the dangers of RedHat. While every new version of a linux distro is waved about with great expectations and cheer, other OS's are actually being analyzed for the bad as well as the good. I won't say that nobody posts unbiased articles, and I will even admit that if every stupid needless redhat exploit were listed on slashdot, RedHat would look as bad as Windows. Almost every OS and piece of network software has exploits, and very VERY few developers ever get it right the first time. I just wonder why it's so easy to see all of the mistakes for software that we may not (choose/want to) use while pretending all those dozens of RedHat exploits we had to patch never really were a problem.

Those who even bothered to reply to this newsworthy post with openbsd-bashing, are the ignorant monkeys of the open source community and have obviously never really compared UNIX's in the server world.

Those who bothered to reply to this stating that C is the wrong language to code in bring up minor points and expect the code that drives the internet to change. C is small cpu load and if it turns out buggy, it is the developers fault. But to expect software developers who write based upon existing libraries and code concepts they have developed over decades of work to stop and try writing their apps in an experimental (and YES, pretty damn potentially exploitable itself being so new) language is just silly. PHP is "a modern language" and was just recently found exploitable despite years of development in the PHP arena. IMAGINE the chaos if the development language that your OS/net apps were written in was found to be buggy? To date I have not had to download a new version of gcc and recompile my OS/kern/3rd party apps due to a "C vulnerability". Using experimental non-prooven ( 10 years?) languages for OS/kern/apps is a pretty stupid risk.

Re:ignorance and self deceit

[dvdeug]

But to expect software developers who write based upon existing libraries and code concepts they have developed over decades of work to stop and try writing their apps in an experimental (and YES, pretty damn potentially exploitable itself being so new) language is just silly.

Huh? The first Ada standard came out in 1983, 6 years before the first C standard. The latest Ada standard came out in 1995, 4 years before the latest C standard. What's so experimental about that?

I have not had to download a new version of gcc and recompile my OS/kern/3rd party apps due to a "C vulnerability".

I take it you missed the whole remote hole due to globbing bug in glibc issue, then?

Using experimental non-prooven ( 10 years?) languages for OS/kern/apps is a pretty stupid risk.

So Kerrigan and Richtie were pretty stupid for writing their new OS in C, weren't they? They should have stuck with assembly and Fortran, should't they?

Somebody's got to prove the things. Considering the number of security holes due to things in C that other languages would prevent, and the comparitive rarity of compiler security holes (and it's a lot easier to fix bugs in one code base than a thousand), I'd say you're looking pretty good.

Re:Full disclosure = annoying.

[bluebomber]

An unrestricted maniac runs around the streets, shooting people in the name of improving security because he aims to increase the public use of bullet-proof vests.

Alternatives to wearing bullet-proof vests:

1. Get your own fucking gun and shoot the SOB.
2. Armored vehicle.
3. Stay home.

Your analogy doesn't make sense. Finding a root-exploitable weakness in v1 isn't the same as developing an armor-piercing bullet.

OpenSSH?

[Anonymous Coward]

When they said OpenSSH I didn't think they were so serious...

Re:Sigh..

[iamsure]

But they are not listening to an externally accessible port, and thus are not REMOTELY COMPROMISABLE.

Re:How embarrassing for them...

[Mike Buddha]

If you think you can help, why not pitch in, instead of merely complaining? Your complaints, although valid, aren't of much use to anyone after the fact (and they do sound conceited and self-righteous, considering how little you've offered to the community, thusfar).

3.1 will NOT build on linux

[TheGratefulNet]

fyi:

cipher.c : 497 : structure has no member named `flags'
cipher.c : 497 : `EVP_CIPH_CBC_MODE' undeclared (first use in this function)
cipher.c : 497 : `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function)
cipher.c : 498 : `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function)

(sigh)

Re:3.1 will NOT build on linux

[Alioth]

Did you build the *portable* version (not the *BSD version?)

The portable version built cleanly and ran on both my Intel-based Linux system and my ancient MIPS-based Linux system. The *BSD version will not compile on Linux. Make sure you have the right version!

Re:3.1 will NOT build on linux

[gskouby]

Check your openssl version. You need 0.9.6

Re:3.1 will NOT build on linux

[TheGratefulNet]

I AM running .9.6 (openssl-0.9.6c)

I configured pam and tcp-wrappers, if that matters.

and yes, I did use the 'portable' version and not the bsd version. still not building on linux.

Re:3.1 will NOT build on linux

[pryan]

Yep, that was my thought, too. It built perfectly for me, and I'm running Debian testing with OpenSSL 0.9.6c.

Re:I don't think so.

[Alioth]

The hacker world would rather beat more simple targets like Windows than go for something complicated like SSH on Linux.

Don't bet on it. A while back, for kicks, I checked to see who was bombarding what ports on my box with attempted hacks. A large portion of them came from 0wn3d Linux systems. I'm just glad that (a) I kept things patched (b) didn't have a default RedHat install and (c) had a MIPS processor that obfuscated any hole I didn't yet know about.

If you don't patch a potentially remote-root hole, it's not a case of "if". It's a case of "when" you'll be 0wn3d.

I wish they'd bring back Red Hat 6.2 RPMS.

[emil]

This was a very strong distribution; I dislike the current requirement that I build the RPMs myself, especially for a major problem like this.

Re:There goes OpenBSDs slogan...

[tzanger]

OpenBSD is still right with her claim.

I don't think so... IIRC there was a remote root exploit in ssh < 3.0p1 which caused me to update my systems, and now this.

Re:There goes OpenBSDs slogan...

[Chundra]

Everyone knows that to iterative over an array of n elements, you do this: for(i = 0; i arraySize) { error(); } else { ... }

Reeeeeeeeeeally? In what language?

How can someone like you have the nerve to criticize the OpenSSH guys?! Missing '<' and '>' in such a critical spot! Jeez! It might be a common error to make, but I would think people trying to illustrate the incompetance of a talented security software coder making a minor mistake would constantly be thinking to themselves about the consequences of these kinds of trivial syntactic errors. It's also a real bonehead mistake. Everyone knows that you use & lt ; and & gt ; in HTML to get the '<' and '>' symbols. I'm sorry if this sounds conceited (that isn't my intention) but when I look at this I have an almost subconscious SCREAMING reaction. For whatever reason, the days when I made mistakes like this have come and gone -- whenever I use '<' or '>' to illustrate how stupid someone else is (when they're trying to illustrate how stupid someone else is) I always think about it, and I cannot imagine someone not thinking about what they are doing. Especially in a piece like this. How completely, and totally embarrassing for you, Briosa.

Re:I don't think so.

[Alioth]

Well, for any attempt on my box from a machine where I could trace someone responsible, I'd email them. I often got "Thanks, yes we were owned" replies, or replies from sysadmins telling me "I told that idiot to secure his RedHat box three months ago" kind of thing.

Also, hack attempts from systems that have reverse DNS entries like "ns1.foo.com" or "smtp.bar.net" are almost certainly 0wn3d machines - it's unlikely that a legitimate user is using those boxes as hack-launch platforms. I got a surprisingly large number attempts on my box from machines like that.

Then there were the hundreds of Linux systems on RoadRunner, @home etc. which were more than likely 0wn3d boxes (because rr.com and @home tend to kick people off for hacking, so it's unlikely the box owner was aware of what was going on).

Some attacks were undoubtedly done by the machine owner, but a large volume really was from 0wn3d Linux and Solaris systems.

As for the MIPS system, it doesn't run Irix. It's Linux on a MIPS system - and therefore reasonably obscure. Don't get me wrong - I do take security very seriously and I upgraded OpenSSH on this box as well as on the Intel machine - you never know who's lurking out there looking for any chink in your armour. Most skript kiddie tools are aimed squarely at the ubiquitous - Linux on Intel (or AMD). That's not to say that there's NOT someone out there targetting Linux/MIPS, but there are many orders of magnitude of attacks aimed at the Intel boxes.

Re:There goes OpenBSDs slogan...

[Florian Weimer]

This is not a local exploit. And didn't OpenBSD ship vulnerable SSH server implementations (with the CRC32 attack decompensator buffer overflow)?

Re:Full disclosure = annoying.

[Florian Weimer]

This is not full disclosure. Details on how to exploit this vulnerability have not been released yet. In fact, I wouldn't have thought that this off-by-one error is exploitable.

Of course, this makes it more complicated to determine whether only authenticated users can exploit it. (I think so, because channel message processing starts only after authentication.)

Somebody should tell Oracle, and many others.

[emil]

Why does RH62 improve on all preceeding and following versions? Let me count the ways...

1. It has inetd
2. It does not have some bizarre mix of 2.2/2.4 kernel components
3. It does not require two separate compilers (kgcc)
4. It does not compile the filesystem driver as a kernel module
5. It runs Oracle 8.1.7 just fine
6. It has an up2date agent that is every bit as functional as the later versions
7. It does not implement stupid firewall rules out of the box
8. It is stable

Lots of people have said that 2.2 was Linux's "sweet spot" and this revision is great for servers - the only thing it lacks is JFS and large files. I use SGI's XFS shim for RH71 for that (should try 72 one of these days).

Re:Full disclosure = annoying.

[arkanes]

If you feel this way, why are you using OpenSSH? Go with a closed source implementation where that's exactly what you'll get - no documentation, no posts, no exploit code. Also no updates, unless they feel like it.

Slackware 8.0

[bjtuna]

Has anyone gotten openssh-3.1p1 to compile and run properly on Slackware 8.0? I got it to compile (with a HELL of a lot of warnings), but when it starts up, it refuses to accept my password.

Anyone seeing anything similar?

Re:Slackware 8.0

[bjtuna]

Nevermind, I got it to work:

LIBS=-lcrypt ./configure --prefix=/usr \
--sysconfdir=/etc/ssh

had to put that LIBS= in there... grabbed that off the OpenSSH FAQ.

Re:I guess you don't want speed, then.

[dvdeug]

We write such servers in C for one reason: speed. The users demand it. Java has too many resource requirements (CPU, memory) for ultra high traffic on a single uniprocessor box.

Besides the fact that Java is not the only modern language, I really don't care about "ultra high traffic". If my sshd gets two connections, I'm multitasking; three I've probably been hacked. I don't need it to be faster; I need it to be secure and simple to set up and admin. Maybe the big sites should be running something else, but probably 99% of the sites that run ssh don't get heavy ssh traffic. Those sites need to worry about being hacked more than they need to worry about that last 20% of sshd speed. (If sshd is taking up 39 seconds of cpu time over 8 weeks, then 20% is a second a week; for more security, it's a great tradeoff.)

O BOB!!!

[Kirkoff]

For all the trouble we made in my computer science class in High School, that had to be the best thing to come out of it. The teacher decided that Off-by-one Errors were to be called OBOBs (think Oh Bob!) for Off By One Bug. I dunno, it just feels more personal... Maybe I should find something productive to do.

--Josh

Re:This is why I use commercial SSH!

[WildBeast]

You should read a letter than Linus wrote a few months ago.

Re:There goes OpenBSDs slogan...

[Tuzanor]

sendmail is enabled by default, but listens only on loopback...

Advice from a frustrated sysadmin...

[doughmein_dot_net]

As an OpenBSD serveradmin running a number of co-located webservers, I can offer this advice:

Do not install OpenSSH 3.1 over OpenBSD 2.8 unless you desire intense pain, punishment, or peril.

I tried this, and immediately ran into error messages since my OpenSSL library was out of date. (OpenBSD 2.8 ships with OpenSSL 0.9.5a by default) Once I got a new version of OpenSSL built and installed, I tried to compile OpenSSH 3.1 again, but the end result would not allow password interactive logins for some odd reason. I spent a few hours working on this issue, which put some of my paying customers in a tough position as they were unable to access the server through SSH.

I finally gave up on the 3.1 release, and found the security patch for OpenSSH 3.0.2 issued by the kind folks at pine.nl (thank you!), which, when recompiled, worked flawlessly.

The only clue that I had as to the OpenSSL library version dependency was one short, obscure mail message on the openssl-unix-dev mailing list, at this URL:

http://marc.theaimsgroup.com/?l=openssh-unix-dev &m =101473993002531&w=2

This is another example of some of the frustrating aspects of OpenBSD and the way it is maintained. This OS is well-written in general, but the documentation and help text for server admins is quite lacking. Nowhere on the OpenSSH webpage was there any mention of a version incompatibility with OpenBSD 2.8's default OpenSSL installation. Nowhere on the OpenBSD pages is there a quick, easy, simple set of steps that one can take to update just one's local source tree to the current version of OpenSSL as approved by the OpenBSD team.

(Yes, I know there are man-pages for CVS. I don't care to take the time to learn the entire set of command-line options, and in situations like this, it is far more useful to get clear, simple and relevant instructions for how to fix the latest hole before some script kiddie beats me to the punch and "0wnz" my server.)

I would also caution Slashdot readers not to automatically assume that OpenBSD is "secure by default" just because the development team says so. Smart server administrators will quickly realize that a number of things need to be closed up after the default install. However, this is still *BY FAR* more secure than other OS's, which is why I will continue to run OpenBSD. For now.

Regards,
support at doughmein dot net

Upgrading your RH 6.2

[martial]

(lines preceeded by ">" are command prompt lines)

Get the latest source rpm for openssl (I used : openssl-0.9.6-3.src.rpm). It can be obtained from rpmfind.net
Get the latest source rpm for openssh (3.1p1 ;) )

as root, do :
> rpm --rebuilbd openssl-0.9.6-3.src.rpm
and let the system build

> cd /usr/src/redhat/RPMS/i386
> rpm -Uvh --nodeps openssl-*
the nodeps is because two files called
"/usr/lib/libcrypto.so.0" and "/usr/lib/libssl.so.0" (not owned by any
RPMs) need to be properly relinked.

In order to do so, please do :
> rm -f /usr/lib/libcrypto.so.0
> rm -f /usr/lib/libssl.so.0
> ln -s /usr/lib/libcrypto.so /usr/lib/libcrypto.so.0
> ln -s /usr/lib/libssl.so /usr/lib/libssl.so.0
note that until you do the next line, you can not use "ssh"
anymore (mismatch between the openssl version used by the previous
openssh installation). Now to upgrade to the latest version of openssh

> rpm -Uvh openssh-*
note that files called "/etc/ssh/ssh_config.rpmnew" as well as
"/etc/ssh/sshd_config.rpmnew" will be created. They are the default
configuration files and will not replace your modified configuration
files

Hope this helps ;)

Re:Upgrading your RH 6.2

[martial]

Of course I forgot to add that between :
> ln -s /usr/lib/libssl.so /usr/lib/libssl.so.0
and
> rpm -Uvh openssh-*

you have to do :
> rpm --rebuild openssh-3.1p1.src.rpm
let it run
> cd /usr/src/redhat/RPMS/i386

(sorry)

Re:Upgrading your RH 6.2

[Siva]

i obtained openssl-0.9.6b-8.src.rpm from the redhat 7.2 SRPMS archive. in order to get around the stupid libcrypt.so.0/libssl.so.0 problem, i modified the spec file slightly. everything seemed to build and install correctly. here is a patch:

--- openssl.spec.orig Fri Mar 8 10:52:52 2002
+++ openssl.spec Fri Mar 8 13:14:03 2002
@@ -3,7 +3,7 @@
Summary: The OpenSSL toolkit.
Name: openssl
Version: 0.9.6b
-Release: 8
+Release: 8.1
Source: openssl-engine-%{version}-usa.tar.bz2
Source1: hobble-openssl
Source2: Makefile.certificate
@@ -30,6 +30,7 @@
BuildRoot: %{_tmppath}/%{name}-%{version}-root
BuildPreReq: perl, sed
Requires: mktemp
+Provides: libcrypto.so.0, libssl.so.0

%define solibbase %(echo %version | sed 's/[[:alpha:]]//g')

@@ -219,11 +220,21 @@
%attr(0644,root,root) %{_mandir}/man1*/*.pl*
%{_datadir}/ssl/misc/*.pl

-%post -p /sbin/ldconfig
+%post
+rm -f /usr/lib/libcrypto.so.0
+rm -f /usr/lib/libssl.so.0
+ln -s libcrypto.so.0.9.6b /lib/libcrypto.so.0
+ln -s libssl.so.0.9.6b /lib/libssl.so.0
+/sbin/ldconfig

-%postun -p /sbin/ldconfig
+%postun
+/sbin/ldconfig

%changelog
+* Fri Mar 8 2002 James Blanding 0.9.6b-8.1
+- Provide libcrypto.so.0 and libssl.so.0 for backwards compatability
+ with RedHat 6.2 openssl RPMs
+
* Fri Sep 7 2001 Nalin Dahyabhai 0.9.6b-8
- disable the RNG in the ubsec engine driver

source tarball signer's PGP key?

[davie]

I really like to verify signatures on packages and tarballs when available, especially for tools like SSH. I've looked all over the place (including a couple public key servers) and haven't been able to find the signer's public key. Any ideas where it might be hiding?

Re:What people say

[MarkusQ]

dman123: Please stop arguing every one! Its a mute point. ;-)

*laugh* Cute.

"Moot point" is another phrase that often irks me, since so many people use it as if it meant "irrelevant" instead of (correctly) using it to mean "arguable either way."

*sigh*

-- MarkusQ

Re:What people say

[MarkusQ]

But you missed my point. You act as if "off-by-one error" is some part of the english language or some sort of technical description; something to get right or wrong. It is only a figure of speech. Thus, one way of saying it isn't much more valid that any other.

According to my dictionary (Oxford Concise English, 9th edition):

one-off adj & n made or done as the only one; not repeated. n a one-off product, event, etc.

The meaning of the phrase "off by one" follows directly from the meanings of the individual words, as given in the dictionary, but only if they are used in this order. The other five ways of ordering them ("one by off", "off one by", etc.) mean nothing.

The abstract used a compound word as if it meant something that it did not, in a context where the dictionary meaning would have been valid but implausible. I infered that they had intended to use the correct phrase (according to the dictionary) and thus, as you note, had "gotten it wrong." That was my point.

You claim that there is no right or wrong way to use the words, that it is "just a figure of speech".

I understand your point, but I dispute it. Thinking that because something is "only a figure of speech" it doesn't matter how you say it can, in many cases, lead people to miss your point. I can even think of a few figures of speech that, were you to alter them slightly, could get you slapped if you are lucky and kicked in the groin if you are not.

-- MarkusQ

Re:There goes OpenBSDs slogan...

[Wakko Warner]

You must be a troll, but for the benefit of others, OpenBSD doesn't install telnetd, named, or sendmail by default.

Then what the hell good is their claim? Wow, yeah, there's no remote hole because we don't fucking enable anything that accepts remote connections. OpenBSD's claim is as empty as its feature set.

-A.P.

run with libsafe...

[runswithd6s]

Related, but not directly. To protect from "stack smashing" techniques (buffer overflows), run your glibc apps with libsafe. It should detect, stomp out (i.e. abort()) and email you about overflow and out-of-bounds conditions by simply adding its path to the /etc/ld.so.preload file.

Re:ugh qmail

[thing12]

I used qmail for a couple years after prying myself away from sendmail because I wanted maildir. I love maildir - when you have mbox files that are over a gig, you'll love maildir too - but it's the only part of qmail that's worth a damn. Honestly, qmail is the most complicated software product I've ever worked with. There's no centralized configuration, it uses environment variables and 'list files' - meaning that rather than a section in a config file, qmail has a directory with multiple files inside it, each file has an attribute or a list of attributes. Sure it makes writing shell scripts to manage everything a little easier -- but you *have* to write the shell scripts, because there's way too much to remember if you don't. Administering qmail is no better than administering sendmail.

My MTA of choice these days is Courier, it's written by Sam Varshavchik (aka Mr. Sam) who at one point seemed to be a disciple of DJB, having written gobs of other software that goes with qmail maildirs. Courier is a complete mail server, not just a sendmail replacement. Built in POP3/IMAP both supporting SSL/TLS. Web and/or standard config file based administration. Supports LDAP, PgSQL, and MySQL for authentication. Mail Filtering, List management, and even a webmail server. Even group calendaring. Who needs anything else? It's all integrated so there's no obscure set of howto's to search for when you want to get an imap server or an LDAP authentication service running. Oh and it's GPL'd... something you can't even begin to say about DJB's bizzare pseudo-opensource license. It's had a quarter of a million downloads off SourceForge, that's gotta say something.

Re:Full disclosure = annoying.

[SquierStrat]

To be honest,that's a bunch of crap. You should always assume the lowest amount of trust in an application's security, especially applications of this nature. If they didn't tell me what was wrong, I wouldn't believe for a second that they fixed it.

Re:But SSHD *is doing* bounds checking!

[3247]

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

Put ssh in jail?

[Shanep]

Does OpenBSD support FreeBSD's jail feature?

Could ssh be run in jail to minimize an exploit?

Re:There goes OpenBSDs slogan...

[Fjord]

Ok, but that isn't a workstation, obviously.