OpenSSH Local Root Hole 554
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."
linux patch available (Score:1, Informative)
Re:There goes OpenBSDs slogan... (Score:3, Informative)
It's a LOCAL exploit. You have to be logged in to exploit it.
Re:linux patch available (Score:4, Informative)
Correction: off-by-one (Score:5, Informative)
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
OpenSSH site already updated? (Score:4, Informative)
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.
smallest possible patch (Score:4, Informative)
For you guys too lazy to read:t xt [www.pine.nl]
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?
Re:linux patch available (Score:3, Informative)
Re:There goes OpenBSDs slogan... (Score:2, Informative)
Re:Full disclosure = annoying. (Score:3, Informative)
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.
Re:OpenSSH site already updated? (Score:2, Informative)
The vulnerability was sent to the OpenSSH team a few days ago. It was not publicized until a fix was in CVS.
OpenBSD upgrade. (Score:4, Informative)
http://www.openssh.com/openbsd.html
Mine's compiling now.
--saint
RPM's Compiled For i386 (Score:2, Informative)
http://www.geniusweb.com/RPMS/ [geniusweb.com]
SSH 3.1p1 RPM's compiled without gnome-askpass, everything else is default vanilla.
FreeBSD affected; patches available (Score:4, Informative)
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+
Re:What are package people supposed to do? (Score:5, Informative)
This SSH hole does not apply to the version of OpenSSH in potato (it's at 1.2.3-9.4; this hole is in 2.0 - 3.0.2); for woody and sid, the SSH maintainer has already uploaded new packages (see the BTS [debian.org]).
Re:What are package people supposed to do? (Score:5, Informative)
Everybody who runs debian (especially stable or older) should have security.debian.org in their apt-get table. Put a line like:
in
Note that as of this writing, no updated SSH package is available.. but if previous behavior is any indication of future performance, it should be there soon.
Re:Please stop writing network apps in C! (Score:5, Informative)
So in fact a stricter language would fix this problem.
FYI: my box may have been exploited by this (Score:4, Informative)
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".
Re:*** Help on upgrading a remote server? (Score:5, Informative)
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:Full disclosure = annoying. (Score:2, Informative)
(I'm in the webhosting business myself...)
Vince.
Re:I'm going back to telnet (Score:2, Informative)
Re:Commercial SSH (Score:3, Informative)
Not nesessarly true: OpenSSH and Commercial SSH have the same roots - http://www.openssh.com/history.html [openssh.com]
Re:3.1 will NOT build on linux (Score:3, Informative)
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 (Score:2, Informative)
Re:*** Help on upgrading a remote server? (Score:2, Informative)
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.
Compiling OpenSSH on Solaris (Score:1, Informative)
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.
Re:OpenSSH site already updated? (Score:4, Informative)
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.
Upgrading your RH 6.2 (Score:2, Informative)
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
Re:Upgrading your RH 6.2 (Score:2, Informative)
> ln -s
and
> rpm -Uvh openssh-*
you have to do
> rpm --rebuild openssh-3.1p1.src.rpm
let it run
> cd
(sorry)