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."
Shame...
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.
Derek Greene
So when does 3.1p (portable -- for other OS's) become available?
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'
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.
Derek Greene
Most worms scan for nt and ISS. I get like 100 a week trying to load NT files, and I'm running Apache on Linux. The hacker world would rather beat more simple targets like Windows than go for something complicated like SSH on Linux.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
not to people, the debian packages have not yet been updated so your best bet is to download (like a real penguin) and install yourself (but only if you want to be a penguin, they dress well)
internet like monkeys'
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
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.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
For you guys too lazy to read:t xt
http://www.pine.nl/advisories/pine-cert-20020301.
( 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?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It was released today according to the OpenSSH website.go and pound the mirror sites
I can't wait for the Daniel J. Bernstein version of ssh.
-russ
Don't piss off The Angry Economist
The not so Secure Shell.
You are receiving this message because your browser supports Slashdot Sigs and you have Slashdot Sigs enabled.
Nah they don't.;) But I'm working on exploit code as we speak.
2002-03-07 11:39:40 Server version: SSH-2.0-OpenSSH_3.0.2p1
Good night everybody!
Please read the articles before posting.
A remote exploit has not been ruled out.
Chances are, one will be available shortly to the general public and script kiddie scenes.
Vince.
I need a sig.
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.
Derek Greene
Please don't post to bugsmaq when you're done. =p
We really don't need more smart-enough-to-be-dangerous script kiddies armed with other peoples code causing more mayhem.
Vince.
I need a sig.
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.
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.
Script kiddies are the scavengers who feed off of other peoples code.
A great place to get this code is secfocus.
As for what you say about bandwidth being relative to upgrades... Well. Explain the previous worms and DDoS nets? Not everyone gives a fuck. Not everyone will be bothered to upgrade. Some people don't even know how...
Vince.
I need a sig.
Please take a look at http://anti.security.is when you have some spare time.
In particular:
Q: What's wrong with full disclosure?
A: Full disclosure attempts to contradict the saying "two wrongs don't make a right" in the sense that it stimulates criminal activities in order to catalyze security awareness. Take the following example: 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. And who makes these vests? After everybody is protected by vest v1, the public is complacent, and sales of vest v2 must be stimulated by inventing a shotgun which penetrates the first vest. There is competition in the vest manufacturing business, so they all profit from the development of higher powered munitions. Manufacturers get money, and also lobby for pro-homicidal laws in other countries to spread the market, while innocent people suffer at their expense. The cycle still doesn't end with vest v666, because a newer armor-piercing bullet is in the works. How do you end the rat race? Stop full disclosure!
Vince.
I need a sig.
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
Help yourselves:
http://www.geniusweb.com/RPMS/
SSH 3.1p1 RPM's compiled without gnome-askpass, everything else is default vanilla.
My poetry site welcomes the unusual.
Unfortunately, I can't post the advisory here due to the lame lameness filter. But here are the patches:
S A- 02:13/openssh.patche eBSD/CERT/patches/SA- 02:13/openssh.patch.asc
/usr/src /path/to/sshd.patch /usr/src/secure/lib/libssh /usr/src/secure/usr.sbin/sshd /usr/src/secure/usr.bin/ssh
0 +c urrent/freebsd-announce
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.FreeBSD.org/pub/Fr
Execute the following commands as root:
# cd
# patch <
# cd
# make depend && make all
# cd
# make depend && make all install
# cd
# 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+
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?
This sig is false.
Phew! Thought i`d wasted the last 5 years of my professional life using the wrong language!
Has all the features any Modern Programmer could want. And it has the Highly Secure .net framework built in. What more could you want?
Best Slashdot Co
Looks like just adding an equal sign:
/cvs/src/usr.bin/ssh/channels.c,v
RCS file:
retrieving revision 1.170
retrieving revision 1.171
diff -u -r1.170 -r1.171
--- channels.c 27 Feb 2002 21:23:13 -0000 1.170
+++ channels.c 4 Mar 2002 19:37:58 -0000 1.171
@@ -146,7 +146,7 @@
{
Channel *c;
- if (id < 0 || id > channels_alloc) {
+ if (id < 0 || id >= channels_alloc) {
log("channel_lookup: %d: bad id", id);
return NULL;
}
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 realize that correctness comes before performance (except that shipping the product is Job 1), but performance remains an issue on real-world production servers connected to a fat pipe. Does the compiler for your favorite modern language support binary code optimizations that let your ftpd run as quickly as a popular C ftpd? Does it have a GC thread that might kick in and cause delays? Or did you just use bounds-checked C++ arrays and strings?
(Heck, why even use FTP anymore? HTTP/1.1 is lighter weight, doesn't need a separate connection for each file, and doesn't have a built-in way for spammers to build lists.)
Will I retire or break 10K?
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.
Anyone quoted by a reporter knows how little they understand
Don't believe what you read is the truth.
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.
-- http://frobnosticate.com
> 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?
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.
anti.security.is is a place for disinformation. Everybody knows that. Just try to follow their arguments, and you will see that it is not sound. With an incorrect premiss, you can derive whatever you like.
Besides, the cycle that they are describing is exactly how security research works. People who fix, and people who break. Working together to improve your security.
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.
Derek Greene
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".
Integer id
if id is greater than (>) allocated memory on the stack then return null
when it should be Integer id
If id is greater or equal to (>=) allocated memory then return null and log it.
hence the off by one?
If this is incorrect (likely case) then please correct me, and could someone clear up what the channel_lookup function is used for to maybe give a better on this being possibly used as a remote compromise. And would I be correct to assume regardless of local/remote access theat the user would first need a valid account on the system prior to attempting to escalate privileges? This advisory is hardly complete.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
And I thought it was just about time to go home too. Now I'm warming up my compiler... :-(
UNIX? They're not even circumcised! Savages!
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.
From FreeBSD's port archive, this will fix 3.0.2:
- 02:13/openssh.patch
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA
No SIG for you!
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.
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.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
If someone ran the T1 themselves, yes it's likely they would be capable of upgrading.
What about dedicated servers?
99 bucks a month. rackshack.net.
They can put out a couple mbps each. How many vulnerable machines do you think are going to remain on that network alone because of clueless users?
It's not as cut and dry as you might think.
And yes, secfocus does distribute code, when code is available.
Vince.
I need a sig.
Uhm, You're obvously security unclued... this is only exploitable by people with access to your machine. a 'worm' would not work.
Don't get mad at the security community for your lack of understanding on how to admin a machine. Everyone gets hacked sometime, it's your responsability to make sure it's not on your watch.
No SIG for you!
How many clueless users are going to a) have a dedicate server and b) be using ssh in the first place?
Derek Greene
the fact that I have to now upgrade ssh on all my boxes, or the fact that the first I heard of this was on /. instead of oh say, BugTraq.
(Of course, what pops into my inbox as I'm writing this, but the advisory on BugTraq.)
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.)
Okay - Forget the link, and just read the section from the FAQ that I posted.
:)
It makes sense to me, atleast.
Vince.
I need a sig.
A hell of a lot.
(I'm in the webhosting business myself...)
Vince.
I need a sig.
Please read the article.
A remote exploit has not been ruled out.
As of now, a local exploit isn't even confirmed, since there is no concept code.
Vince.
I need a sig.
Thanks for this superb explanation. Moderators, please mod it up so other people can see it - there may be people out there who don't want to upgrade because they're worried about this.
-- http://frobnosticate.com
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.
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.
Derek Greene
I would argue that there *is* a maximum version number-- let's call it v100 to denote 100% security. By "security" I necessarily mean technical security from remote attacks, ignoring various shortcuts using social engineering, physical access, etc. A secure protocol based on public key crypto without bugs would be 99% secure, to account for the remote possibility of finding efficient ways to reconstruct private keys.
Now take an implementation with (presumably) many bugs, such as OpenSSH, that is, say, 50% secure. The sooner the trivial engineering bugs can be fixed, the sooner the implementation will be 99% secure, at which point the only hope of compromising its security is in some unpredictable breakthrough in mathematics. This is why the armor-piercing bullet arms race argument doesn't make sense to me. Sooner or later it is bound to reach a limit which can only be surpassed with revolutionary advances.
I don't think full disclosure is really important in this process; instead, open source is what makes it possible to find bugs early. In fact, open source implies full disclosure-- without bugtraq or whatever, you can imagine downloading each new version of SSH and looking at diffs to deduce what bugs got fixed.
Tsunami -- You can't bring a good wave down!
It's also a real bonehead mistake. Everyone knows that to iterative over an array of n elements, you do this:
for(i = 0; i < n; i++) { ...
}
And everyone should also know that the array indices for an array with n elements range from 0 to n - 1. The actual mistake was something like this:
if(idx < 0 || idx > arraySize) { error(); } else { ... }
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 loop over arrays I always think about it, and I cannot imagine someone not thinking about what they are doing. Especially in a piece of security software. How completely embarrassing.
Well, all of the machines WE run of course will be upgraded. Automatically, since we run an auto-update system...
But rackshack.net (sticking with my example) provide unmanaged services. This means their users are on their own.
Also; once you have a couple hundred clients with a machine each, upgrading for them, or walking them through the process, or even ensuring they all actually do so, becomes very difficult.
And I'm sure they have many more than a couple hundred.
Also - Theres a difference between SSH running, and using SSH. Stupid users may never use SSH, but SSH will likely still be running on the machine. (Depending on distro, etc. But mostly RedHat 7.x's and Cobalt, which both have SSH enabled by default).
Vince.
I need a sig.
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.
Okay, you can have the alternative of not being told immediately and some of your systems being owned. Have fun.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
That is all..
Luck favors the prepared, darling.
The best answer only works if you have more than one box at your colocation facility, and involves buying another box. Buy a terminal server. Connect it to all the serial ports on your other devices. Secure access to it thoroughly. Now, you can telnet to the serial port on a box from another box -- with decent hardware, e.g. Sun Netras, you can even powercycle it if you need to.
I guess I should know better than to let my helpful side show on slashdot.
You may have had the best intentions, but in reality (by uploading untrusted SSH binarys) you are encouraging people to take stupid risks. :-)
Its farily obvious by uploading the binarys that you are not a security expert
Please THINK!!!
Anyone quoted by a reporter knows how little they understand
Don't believe what you read is the truth.
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.
I would prefer knowing there was a new release of SSH. A maintenance release.
10-15 days later, an announcement that this release was due to a vulnerability found should be released.
NO more detail than that.
NO patch. NO post to bugtraq. NO exploit code.
That would provide adequate security with minimum damage.
Vince.
I need a sig.
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?
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
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.
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.
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.
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?
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...
I just got the exact same thing compiling for OpenBSD 2.7. Yes I installed the patch first. Any ideas?
No, Thursday's out. How about never - is never good for you?
In INSTALL it says you need openssl-0.9.5.
That is wrong, you need openssl-0.9.6 or it
won't compile.
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.
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.
The Daily Build
Version 3.1 has as its changelog (READ THIS, there are path changes etc. that you need to know about!):
/etc/ssh/ now default directory for keys and configuration files
Important Changes:
==================
-
- ssh-keygen no longer defaults to a specific key type (rsa1);
use ssh-keygen -t {rsa,dsa,rsa1}
- sshd x11 forwarding listens on localhost by default;
see sshd X11UseLocalhost option to revert to prior behaviour
if your older X11 clients do not function with this configuration
Other Changes:
==============
- ssh ~& escape char functions now for both protocol versions
- sshd ReverseMappingCheck option changed to VerifyReverseMapping
to clarify its function; ReverseMappingCheck can still be used
- public key fingerprint is now logged with LogLevel=VERBOSE
- reason logged for disallowed logins (e.g., no shell, etc.)
- more robust error handling for x11 forwarding
- improved packet/window size handling in ssh2
- use of regex(3) has been removed
- fix SIGCHLD races in sshd (seen on Solaris)
- sshd -o option added
- sftp -B -R -P options added
- ssh-add now adds all 3 default keys
- ssh-keyscan bug fixes
- ssh-askpass for hostkey dialog
- fix fd leak in sshd on SIGHUP
- TCP_NODELAY set on X11 and TCP forwarding endpoints
So it's not just a bugfix release, is it?
Got Wisdom?
I'm trying to compile it on a RH6.2 server and getting nowhere. Grrrr.
-------
"Every artist is a cannibal, every poet is a thief."
Sure, the story was posted here. However, this is a case where the full disclosure argument starts to apply to scientific breakthroughs-- which come from a community fairly disjoint from the community of developers and engineers. Arguing not to disclose scientific achievements is going to be a hard case indeed =)
Tsunami -- You can't bring a good wave down!
Don't be so sure redhat's less buggy. Redhat loves to put beta software on their distros, cares little for testing before implementing, and in conclusion i can only say one thing to prove the lack of care for decent OS on redhat's part: `grep linuxconf /etc/services`
Now after about 20 mins of re-configuratin and turning crap off, redhat MIGHT be secure.
I don't doubt this. Last time I heard, people were still saying "infer" when they meant "imply," they were still using "you're" and "your" as if they were interchangeable, they were still confounding RAM and hard drive space, and so on. People do all kinds of silly things.
But using words as if they mean something that they really don't just makes you hard to understand.
-- MarkusQ
When they said OpenSSH I didn't think they were so serious...
also, to make it harder to find try running ssh on a nonstandard port. look through /etc/services and find a nice one that you arent using and run it there. or make up one. it wont solve these problems, but when there is an exploit and you are not in the position to fix it immediately, it will at least buy you a some time and a drop of protection from the scanners looking at port 22 only.
But they are not listening to an externally accessible port, and thus are not REMOTELY COMPROMISABLE.
GPL'd web-based tradewars themed space game
The OpenSSH Website does not make mention of this exploit and the need for users to upgrade. :)
They do mention the release of 3.1 (3/7/02), but it never says that it addresses security issues.
Although, I am much happier to see a patch than an updated website.
Snowdog
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)
--
"It is now safe to switch off your computer."
This was a very strong distribution; I dislike the current requirement that I build the RPMs myself, especially for a major problem like this.
Free software dosen't usually mean bad software, e.g. QMail
Commercial software often dosen't mean good software, e.g. Windows.
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 said nothing about them being remotely exploitable.
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.)
Why does RH62 improve on all preceeding and following versions? Let me count the ways...
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).
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.
Sometimes it's just not that easy. Somehow I find it hard to believe that a majority of these clueless users is running Debian, probably RH and Cobalt mostly (both based off the same code...). For the rest of us, apt-get is fine if you use Debian, but if you can figure out Debian's horrid package system, I'm sure you can install SSH from source. RH does have up2date (I'm assuming Cobalt does too), but it'll probably be a week or two before any of these package databases are update. Debian may be an exception, I only use it for a workstation running no services at all so I don't know how fast they update it, RH however seems to be quite slow in releasing new binaries/binary patches for distros. In comparison to M$ though it's nothing. This comment also completely ignores the fact that alot of people who are partially clueless may have had their box setup by someone else, or been helped through a source install, regardless of distro. (I've personally helped 4 or 5 people in the office install SSH, of course I'll notify them of this 'sploit however) This is the biggest problem I have with packages and binary distros, whatever package system is implemented becomes useless the moment you install from source, and often will in fact BREAK the php/apache setup you had working so well when it tries to update a package you forgot to exclude.
Well DUH it was a troll. Where's a +1 Ironic when ya need one?
The buildpkg.sh script in contrib/solaris looks for the version number on the last line of that file and cannot find it.
I'd submit a bug but I can't seem to get on bugzilla right now.
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?
Intercarve Networks, LLC
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.)
Apple hasn't responded as of yet (Thursday, early evening, EST), but Stepwise already has step-by-step build instructions for OpenSSH 3.1 for OS X. Pop over to this page on their site, follow the instructions, and you're good to go.
--- Why yes, I am the webmaster of Microsuck.com
Instead, just share it with your buddies so we won't know what hit us.
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
There are exactly 42,935,718 letter sized sheets in a square mile.
You'll probably get faster sftp xfers with 3.1, we do overlapped read/writes now.
I've never heard of PINE-CERT either. I smell something fishy.
Ceci n'est pas un post
http://isp.example.com/~abrown/
This is hard to avoid, as is a dictionary attack against a domain's MX.
However, unlike anonymous FTP, HTTP doesn't require everybody who pulls a file to give a well-formed e-mail address in the password field. (Valid addresses are a proper subset of well-formed addresses.) In the early days of the web, building spam lists of this type was very common: a spammer building a list would put up a web page that contained an IMG tag that linked to a 1x1 pixel clear image on an FTP site, and spammers would just run a noddy awk script on the FTP logs to get candidate addresses that were somewhat likely to be valid. I've set my anonymous FTP password to anonymous_coward@slashdot.org, which I also use when installing RealPlayer.
Will I retire or break 10K?
You should read a letter than Linus wrote a few months ago.
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!
As an OpenBSD serveradmin running a number of co-located webservers, I can offer this advice:
v &m =101473993002531&w=2
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-de
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
Super ninja monkeys will one day rule the world!
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.
Full disclosure is a good thing (from the patch aspect), however, it is the sole reason for the large amount of script kiddies on the internet today.
It also decreases joe computer user X's security. (the one that never patches his system, and believe me there are a lot).
(lines preceeded by ">" are command prompt lines)
;) )
:
/usr/src/redhat/RPMS/i386
: /usr/lib/libcrypto.so.0 /usr/lib/libssl.so.0 /usr/lib/libcrypto.so /usr/lib/libcrypto.so.0 /usr/lib/libssl.so /usr/lib/libssl.so.0
;)
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
> 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
> rm -f
> ln -s
> ln -s
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
-- Martial MICHEL
I don't think full disclosure is really important in this process; instead, open source is what makes it possible to find bugs early. In fact, open source implies full disclosure-- without bugtraq or whatever, you can imagine downloading each new version of SSH and looking at diffs to deduce what bugs got fixed
This only works to a point. If this was a successful approach, a bug in OpenSSH and or PHP would have been found months ago.
It seems to me to takes just as long as proprietary models.
Instead, just share it with your buddies so we won't know what hit us
I think full disclosure of a flaw should only be given to the person that is going to fix it. Why does anyone else really need it (if not for malicious intent).
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?
slashdot broke my sig
http://www.offbyone.com/
Is it just me or is the release of this browser under the name "off by one" with openssh support seem a little fishy to anyone?
So you're just going to trust that they fixed it?
So you're just going to trust that they fixed it?
They wrote it. If im using it, I have already given them a certain amount of trust.
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.
assert(expired(knowledge));
.... with OBSD you get to deal with that donut of delight, Theo. Of course, when I wanted to utilize OBSD in the enterprise, I couldn't - I was asked - "who is the support team" - and I had to post a sample from the obsd-misc mailing list. Ah well, you can't say I didn't try.
Surely, what the source says must be a lot more important than who compiled it?
Installed the Bubblemon yet?
I have plenty more. How about:
Semi Secure Shell
You are receiving this message because your browser supports Slashdot Sigs and you have Slashdot Sigs enabled.
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.
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.
Derek Greene
>I said nothing about them being remotely exploitable.
Then, do you have a point?
Yes, I do.
The point was someone (http://slashdot.org/comments.pl?sid=29123&thresh
Stephen L. Palmer
Does OpenBSD support FreeBSD's jail feature?
Could ssh be run in jail to minimize an exploit?
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?