Slashdot Mirror
New ssh Exploit in the Wild
veg writes "In the last few hours there have been several reports of a new ssh bug, with an exploit seemingly in the wild. Oh god not again... The lengths some people will goto to try and damage Theo's pride." Update: 09/17 00:24 GMT by T : friscolr writes "Hot on the heels of rev 1 of the buffer.adv advisory, here is revision 2, which fixes more than revision 1 did. Also see the 3.7.1 release notes."
Best patch and upgr..&*[NO CARRIER]
C:\>
I have to wonder if UsePrivilegeSeparation was enabled. (see the manpage)
One message in the thread indicates it is but this isn't first-hand knowledge. If PrivSep was enabled then is OpenBSD immune to this attack due to other parts of the OS being hardened (much like the zlib hole a few months back)? Also are these default installations or are they "tweaked"? As an aside, PermitRootLogin defaults to enabled, something I always disable as I have no need for it.
Even if this does count as a new remote hole in OpenBSD, it's still a phenomenal track record they can be proud of.
Trolling is a art,
Looks like its time to turn the port forwarding on my router off, and wait for apple to provide a patch.
The advisory itself says The systems in question are FreeBSD, RedHat, Gentoo, and Debian all running the latest versions of OpenSSH. So i'm going to assume that OS X is affected as well.
Look out honey cause I'm usin' technology
Ain't got time to make no apologies
Posting this to slashdot is actually a public service, as the exploit description will be /.'d and unable to effectively be disseminated to the bad actors.
Link to a patch.
[Full-Disclosure] new ssh exploit?
christopher neitzert chris@neitzert.com
Mon, 15 Sep 2003 13:48:34 -0400
More on this;
The systems in question are FreeBSD, RedHat, Gentoo, and Debian all
running the latest versions of OpenSSH.
The attack makes an enormous amount of ssh connections and attempts
various offsets until it finds one that works permitting root login.
I have received numerous messages from folks requesting anonymity or
direct-off-list-reply confirming this exploit;
The suggestions I have heard are:
Turn off SSH and
1. upgrade to lsh
2. add explicit rules to your edge devices allowing ssh from only-known
hosts.
3. put ssh behind a VPN on RFC-1918 space.
On Mon, 2003-09-15 at 12:02, christopher neitzert wrote:
> Does anyone know of or have source related to a new, and unpublished ssh
> exploit? An ISP I work with has filtered all SSH connections due to
> several root level incidents involving ssh. Any information is
> appreciated.
Thank god I'm using something secure like Telnet instead.
Reading the mailing list, it appears that there's nothing confirmed so far. Let's hope its just a false rumour.
There's only one guy that says it its ISP has blocked all incoming SSH connection due to "several root level incidents".
One guy did say that there was a bug somewhere and that a patch existed...No one knows what patch or where it is though.
Let's hope to publish this one quickly before there's any ral damage done.
IP Therefore I am.
Won't having the sshd wrapped (/etc/hosts.allow, /etc/hosts.deny) help offset the damage somewhat?
No sig
I just saw the comment in the nmap article and got worried. A friend online showed me this post..
"I wonder if this is in any way related to an incident I heard about on efnet's #openbsd where someone at a european con (hack the planet?) mentioned that details of a new openssh exploit had been taped to the openbsd tent (on the outside) whilst all the openbsd ppl were inside, drunk? I suppose if there is any merit to that story (and I'd rank it as no more than heresay myself, but it does paint a good picture of college level kids :) and it was details of some new vulnerability for which there is an exploit then it has been around for a while...assuming,of course, it is the same "bug"."
I haven't seen anywhere else online go nuts, which is usually how people react to SSH exploits. What's going on?
Yes, there is a vuln. in 3.6. You need to upgrade to 3.7 which was released today, to be safe (well, 'safer' anyway).
It will be 3.7p1 for us non-OpenBSD people.
It is a patch to one file, buffer.c, which fixes some allocation/offset stuff.
It seems that privilege separation does *not* help here - so get them systems patched (and firewalled)!
Damn trinity and her sshnuke...
How worried should I really be about this? And what steps should I be taking (or ask dad to take)? Since I gather Lindows is similar to Debian, should I just look for a Debian tutorial?
Thanks in advance.
This has already been posted and a fix (upgrade to 3.7) has been posted to www.deadly.org
This guy is way out there
Great, now maybe Redhat will fix their damn openssh RPMs that they fubarred with their last patch!
Anything is possible given time and money.
There is a patch, but the server that the advisory referenced on the SANS posting is on went down hard while I was in the middle of getting the page, so I only managed to get part of it (thanks, slashdot!) The advisory also indicated that openSSH 3.7 isn't affected.
If I have been able to see further than others, it is because I bought a pair of binoculars.
On the other hand, it's good to have the heads up if something might not be as secure as we think it is. This warning gives those who turn it on occasionally the knowledge they need to turn it off if not needed, and not just leave it on.
It also may give those who need it on something to watch for until a patch does come out.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
Patches are already available, for example from the FreeBSD CVS web. Personally, I'd rather apply it now than waiting for a detailed analysis of the exploit...
Programming can be fun again. Film at 11.
A librarian peeked around the corner to see where the noise was coming from, then put her finger to her lips and said, "Ssh!"
The kids ignored her and kept talking, completely and utterly exploiting the hole, and circumventing the 'Ssh'!
Never was I so frightened.
I appreciate it when Slashdot informs me of a patch I need to apply, but really, I'd rather hear about it once the exploit is actually understood and the patch is available.
Really?
How about hearing about it when you find your machines rooted?
Even though there is no patch available (yet), this heads-up is extremely valuable, as it allows people who cannot afford to be compromised to shut down or appropriately filter SSH on their systems.
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
An updated ssh package just hit the Debian security mirrors.
For anyone running debian stable:
apt-get update
apt-get upgrade
A patch for Debian stable is available already. If you're running Debian on a server and have ssh installed, "apt-get update; apt-get upgrade" should pick it up. The new package version is 1:3.4p1-1.1.
-Stephen
I'm installing it as we speak on all my Woody machines.
apt-get update
apt-get upgrade
"City hall" in German is "Rathaus" Kinda explains a few things......
... can be found here http://archives.neohapsis.com/archives/fulldisclo
Personally, I have upgraded all my systems to lsh. The code looks much more trustworthy, and I'm sick of upgrading every few months.
OpenSSH has grown fat over the years, while more and more functionality was integrated, but existing features were kept - for compatibility reasons, and for convenience.
Now we have a big and fat tool that can do nearly everything, but you can go out for bug hunting; there are probably many of them in there.
It would have been a better idea to do a small diet and dis-integrate functions into different tools - like the classic *nix philosophy would suggest.
- cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
- emerge --update openssh
The emerge will fetch the file and complain that there is no digest.- ebuild openssh-3.7_p1.ebuild digest
- emerge --update openssh
Just tested it here, worked fine.Pat
Rather than subject someone's server (like mine!) to a slashdotting, here's the full text of the announcement (slightly mangled to sneak past the lameness filter).
Subject: OpenSSH 3.7 released
Date: Tue, 16 Sep 2003 14:07:00 +0200
From: Markus Friedl
To: openssh-unix-dev _at_ mindrot.org
OpenSSH 3.7 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support.
We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters.
We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18
For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu
Security Changes:
All versions of OpenSSH's sshd prior to 3.7 contain a buffer management error. It is uncertain whether this error is potentially exploitable, however, we prefer to see bugs fixed proactively.
OpenSSH 3.7 fixes this bug.
Changes since OpenSSH 3.6.1:
* The entire OpenSSH code-base has undergone a license review. As a result, all non-ssh1.x code is under a BSD-style license with no advertising requirement. Please refer to README in the source distribution for the exact license terms.
* Rhosts authentication has been removed in ssh(1) and sshd(8).
* Changes in Kerberos support:
- KerberosV password support now uses a file cache instead of a memory cache.
- KerberosIV and AFS support has been removed.
- KerberosV support has been removed from SSH protocol 1.
- KerberosV password authentication support remains for SSH protocols 1 and 2.
- This release contains some GSSAPI user authentication support to replace legacy KerberosV authentication support. At present this code is still considered experimental and SHOULD NOT BE USED.
* Changed order that keys are tried in public key authentication. The ssh(1) client tries the keys in the following order:
1. ssh-agent(1) keys that are found in the ssh_config(5) file
2. remaining ssh-agent(1) keys
3. keys that are only listed in the ssh_config(5) file
This helps when an ssh-agent(1) has many keys, where the sshd(8) server might close the connection before the correct key is tried.
* SOCKS5 support has been added to the dynamic forwarding mode in ssh(1).
* Removed implementation barriers to operation of SSH over SCTP.
* sftp(1) client can now transfer files with quote characters in their filenames.
* Replaced sshd(8)'s VerifyReverseMapping with UseDNS option. When UseDNS option is on, reverse hostname lookups are always performed.
* Fix a number of memory leaks.
* Support for sending tty BREAK over SSH protocol 2.
* Workaround for other vendor bugs in KEX guess handling.
* Support for generating KEX-GEX groups (/etc/moduli) in ssh-keygen(1).
* Automatic re-keying based on amount of data sent over connection.
* New AddressFamily option on client to select protocol to use (IPv4 or IPv6).
* Experimental support for the "aes128-ctr", "aes192-ctr", and "aes256-ctr" ciphers for SSH protocol 2.
* Experimental support for host keys in DNS (draft-ietf-secsh-dns-xx.txt). Please see README.dns in the source distribution for details.
* Portable OpenSSH:
- Replace PAM password authentication kludge with a more correct PAM challenge-response module from FreeBSD.
- PAM support may now be enabled/disabled at runtime using the UsePAM directive.
- Many improvements to the OpenSC smartcard support.
- Regression tests now work with portable OpenSSH. Please refer to regress/README.regress in t
$ find
As opposed to the lengths people will go to to damage Microsoft? But that's ok, right?
An OpenSSH Security Advisory was just posted about this.
So I hear about this ssh exploit the exact same day that my inbox has Markus Friedl's announcement of the release of OpenSSH 3.7.
Either someone on the ssh team is making money from new releases or some black hat, upon downloading 3.7 and seeing the exploit fixed, decided to strike while the iron was still hot (machines weren't yet upgraded).
"Provided by the management for your protection."
Is it? I've successfully exploited my sshd (thank God for easy filtering with PF!)
o mpile/GENERIC
# dmesg | head -n2
OpenBSD 3.4-current (GENERIC) #62: Tue Sep 12 22:49:18 MDT 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/c
To be found at:
http://unthought.net/ssh-vuln.html
If you don't want to wait for the official ebuild:
/usr/portage/net-misc/openssh/
cd
cp openssh-3.6.1_p2.ebuild openssh-3.7_p1.ebuild
emerge -f openssh-3.7_p1.ebuild
ebuild openssh-3.7_p1.ebuild digest
emerge openssh-3.7_p1.ebuild
Even though there is no patch available (yet)
There is a patch available, as well as it being fixed in 3.7, which was just released this morning. That's the point of all of this. The mention of the bug was in the 3.7 release notes, i believe.
wget from: http://security.debian.org/pool/updates/main/o/ope nssh/ssh_3.4p1-1.1_i386.deb
then dpkg -i the resulting file.
It seems to me that a package that goes through code security audits regularly and is actually finished is infinitely more secure than an incomplete package?
Why are there people suggesting to go from a secure package to an insecure one?
I've released the SOURCE RPM...
you can always grab it and see for yourself..
I only changed buffer.c
Feel free to see for yourself..
I had to make all of these this morning to patch our systems..
ChiefArcher
This is the README from 1998, talking about a beta version of lsh. Don't let age-old doumentation fool you.
lsh has grown mature since then, and has an excellent code quality. I recommend it. Any day over OpenSSH, after having looked at the code of both projects. Up-to-date documentation, as on the web page, or the README inside the tarball, doesn't contain the warning.
you have an email address to...
and a resume www.briangannon.com
and the Source RPMS.
http://stradlin.com/ssh
if you do a diff on the sources, you will see I only edited buffer.c
my intentions are completely noble.
How can you really trust Redhat? One of the disgruntled developers could put a backdoor in a patch?
ChiefArcher
What a troll. Aiming to trick mods into "Informative", I suppose.
Any "linux user" who has openssh open to the world is a huge dumbass. What part of "firewall rules" don't you understand?
How would you suggest it be configured then? Just turn off remote login entirely? Or what other "firewall rule" could help in this situation?
I assume you are suggesting that people only allow ssh access from a specific, previously-known host. That removes much of ssh's utility (no more checking your system from a laptop in the hotel room), and even that sacrifice is not enough to be protective!
An attacker sniffing packets at your ISP can learn exactly which addresses you accept ssh connections over. Then he can spoof from that same address, and go right through the firewall.
The only way to protect yourself from unwanted outside connections is with correct crypto code.
Obviously the *NIX side of the world isn't bulletproof either. Now perhaps we might be spared (at least for a day or two) about the anti-M$ rants about insecure M$ code. It can happen, and it can happen regardless of OS platform.
Fair enough, but this goes for any OS: no ports should be open by default!!!
--Drunk as in Beer
I just read all these replies (about 15 right now) and all of them are nice and respectfull of the fact that this guy is a newbie!
I must be on the wrong site.
NarratorDan
"If you're not confused by quantum mechanics, you really don't understand it." - Niels Bohr
http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto/o penssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h
... The code is practically identical, or am I missing something? What's the big deal in calculating the new size in a separate variable? Maybe this is sime kind of DOS attack, not a remote exploit....
I don't see how this fixes any problem
They changed it from 0 to 1 when the last SSH vuln was disclosed. I see no reason that thye wouldn't do it this time. However, it's not afflicting OperBSD anyways...
And as comparison, how many patches do windows users normally need to install over the 'default install' to get it secure and close every hole in the default setup? Methinks slightly more than 1 or 2...
I'd love to see some network infrastructure servers done in Ada.
That's a good idea. Time for the Ada-zealots to "put up or shut up". Those guys never seem to put out much code... and of course they become rarer every day. If their language was really more secure, correct, and easy (yes, they claim that!), then an sshd reimplementation would be a fine demonstration to prove it.
Even though there is no patch available (yet), this heads-up is extremely valuable, as it allows people who cannot afford to be compromised to shut down or appropriately filter SSH on their systems.
Anyone who is relying on slashdot for critical security updates is being extremely irresponsible. If your site is so sensitive, you should have blocked/filtered/whatever ssh last night when it first came out on Full Disclosure or whatever list/service you subscribe to for critical security updates..
There are two kinds of sysadmins: paranoids and losers. I'm both kinds.
Ssh, don't tell anyone.
Omnis amans amens
The vulnerability is fully exploitable under OpenBSD. I've just rooted my own OBSD firewall, and it actually hit the proper register faster than it did on my Gentoo desktop (not that that means anything).
:) But if only one does, then the damaga is done.
A post like this given a +5 is dangerous. I wonder how many OpenBSD users will read that, take his word for it, and not patch their systems. Probably not many
Everyone is entitled to their own opinion. It's just that yours is stupid.
When did they start putting mySQL in the Linux kernel?
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
None of the rants assumed it couldn't happen.
The nature of _my_ rants at least, include the following:
* UNIX does better at risk minimization (i.e. - chroot jails, more services running as unprivileged users, using processes rather than threads, etc)
* UNIX vulnerabilities are published quickly, and hotfixes are available quickly. In this case, we have a _potential_ vulnerability patched before anyone knows of any way to exploit it. In addition, it made frontpage Slashdot - everyone agrees it's a big deal. This is different from the MS attitude of "sweep it into the next service pack and noone will know".
* I have the source code to the patches, so I can validate whether or not the fix does indeed fix the problem it proposes to, and whether there will be any other impact caused by the patch.
* The patch doesn't require me to reboot anything - I can patch a running system and keep on trucking. Kernel patches should be the only thing that needs a reboot (and, when HURD gets mainstream, we won't even need to then).
* The source code is open to allow more scrutiny. Having the source code available still gives Linux users fewer security-incidents-per-feature than Microsoft while keeping their source closed. Ballmer, I believe, said under oath that giving out the source code to Windows publicly would be a threat to national security.
Nothing about the release of an exploit for Linux changes any of these issues.
Engineering and the Ultimate
If you're running a webserver with ssh installed, then it's your responsibility to keep up with the latest patches, upgrades, etc. Of course with a 0-day exploit like this, it's going to be hard to fix quickly. I'd give the linux/bsd distro's a day to come up with a fix.
What you can do in the meantime, is set PermitRootLogin to No and firewall off ssh cept for a few hosts you login from.
"I keep looking in the want-ads under 'revolutionary' but there don't seem to be any listings.. "
It appears that the OpenSSH people found this bug first, and released a fix in version 3.7. People who studied this fix then found the exploit. So it's stupid for this guy to tell people "upgrade to lsh", since the whole reason his buds know about this bug is because 3.7 fixes it.
That's right! It can form remote connections, and generate random keys, and... and... uh, well, that's about it, actually. Form connections, generate session keys.
Public/private key generation? Different program. Managing keys on a local machine? Different program. Transferring files securely? Different (wrapper) program.
Got any concrete suggestions there? Exactly how would you divide the existing tools up? Precisely which tools would you create? In what ways -- details, now -- would they be different from the half-dozen programs that come with ssh now?
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
You are already running windows. You have more serious problems.
...why I always go back and add security holes to all of my programs. If some future (or current) anti-regime hacker needs to be able to break into a local power plant, I want to make sure my code can help!
[I considered signing this post "love, Theo" but then thought better of it.]
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
I think that some people chose to bash Windows while others bash Microsoft as whole. For example, slammer is not a Windows vulnerability but it is a Microsoft product vulnerability. So while it is not fair to bash Windows for slammer, it is fair to bash Microsoft for slammer (esp. for their patch that negated the earlier patch). I guess it is all about how you word it.
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d
It appears that *nix systems now have an exploit
Yep, *nix systems have exploits, and an hour or two turnaround between discovery and a fix. I'd like to see Microsoft match that.
"Linux has no exploits that need patching"
People who actually know Linux would never claim that there are no known exploits, just that the time-to-fix is much shorter and that applying these fixes to running systems is usually much easier (in most distributions) than in a Windows system (ie no reboot required, one location for all necessary fixes, better software package management, etc)
I use Linux and BSD at home, but manage Windows machines at work (I have no decision making power, I'm just a grunt) and I must say that Windows management is a royal pain in the ass. We've had no problems with the recent Windows viruses and worms, but I do spend an inordinate amount of time applying patches, rebooting machines, and checking that the new patches did not wipe out the old ones. I don't think that it is unreasonable for Microsoft's customers to demand better patch/upgrade management, a single location for updates to both applications, servers, and the OS, and a better method for confirming that the files included in a patch contain the all of the required fixes (for that file) even if they came from different departments at microsoft.
Read, L
Don't forget that compiling your own OpenSSH eeds the updated OpenSSL
Nope. You only need openssl-0.9.6 or later. See the INSTALL doc in the openssh 3.7p1 source.
you can restrict access in your /etc/sshd_config (wherever you have it) like so until you can get the patched version, if you allow access from anywhere:
DenyUsers *
AllowUsers you@your_ip_address
(and restart sshd)
You can also firewall the port off. I've done a hodge-podge of these solutions on different systems I admin until I can actually get the 3.7p1 source from the mirrors (they dont' seem to have it yet).
-- http://frobnosticate.com
The only really secure server is buried in concrete, unlugged and at the bottom of the deepest trench in the ocean. It's *probably* secure there, but I wouldn't bet my life on it.
That's okay, I will.
I bet this guy's life that a server on the bottom of the ocean is secure.
Obviously the *NIX side of the world isn't bulletproof either. Now perhaps we might be spared (at least for a day or two) about the anti-M$ rants about insecure M$ code. It can happen, and it can happen regardless of OS platform.
The MS rants are well deserved.
While your statement about security bugs can happen on any platform is technically correct, unintended bugs are not the only thing that causes security problems. Both MS and *NIX can have unintentional bugs, which lead to security problems. In this case, MS should not be blamed for "insecure" code.
Where the MS rants are well deserved is when a system is insecure by design. It may not have been a design goal, but the design can still be insecure. Just one past example: IIS runs under the SYSTEM account. It is installed by default and turned on by default. These kinds of problems deserve to be ranted about, and MS deserves the resulting reputation. Apache may or may not be installed and/or turned on by default, depending on distribution, but even if it could be compromised, it runs as "nobody" or "wwwrun" or some other unprivileged account.
Those who would give up liberty in exchange for security and DRM should switch to Microsoft Palladium!
I'm on a couple of the lists that should have been informed. As one example, NetBSD's security officer has received no information from the openssh team at all. I'm unaware of other groups having received official word.
If you are aware of a security team that was informed officially, I'd be interested to hear about it.
The systems in question are FreeBSD, RedHat, Gentoo, and Debian all
running the latest versions of OpenSSH.
The attack makes an enormous amount of ssh connections and attempts
various offsets until it finds one that works permitting root login.
Odd. I run Debian on all of my systems and PermitRootLogin is set to no on all of them. Sarge and Sid also have UsePrivilegeSeparation set to yes by default.
http://www.securityfocus.com/archive/1/337662/2003 -09-13/2003-09-19/0
No.
Besides, what have they "swept under the carpet"? What do you mean "you have probably"?Just because you seem to have something personal with Theo going on, we're supposed to take your word for this "deceit"?
Unlimited growth == Cancer.
I recall back when IIS 4.0 first came out. You could just Google part of the default IIS home page in quotes as the search string. You'd get results pages with hundreds of new IIS boxes on the 'Net likely with nothing locked down.
I think that the design portion of M$ software is starting to get there (note that Windoze 2003 Server is at least a little more locked down by default). Of course the RPC flaws are still in the code, going from NT 4.0 all the way to include Win2K3.
I will admit that the *NIX platform and apps are inherently more secure since a lot of the code is open source, has lots of reviewing eyes, and patches come about quickly. But nevertheless it's not as secure as folks crow about.
Amazing how a newsworthy point about a ssh bug becomes an attack on an entire operating system and/or person.
"Given that the default install has ssh turned on, will they change it to "two remote holes" ?"
Yes, if they confirm the exploit. They've changed this notice in the past. It went from 0 to 1.
"Lets make some noise and force Theo to finally update that!"
Why? Just to piss off the developers? The openssh code is open and subject to review by anyone.
I think since you didn't catch this bug, we should all be asses and target you for harrassment.
"If you follow misc@ carefully you have probably seen it done before."
Bullshit. If you follow misc@, most of the exploits discussed hit previous unpatched versions of OpenBSD. The point of OBSD is to catch bugs and bad code ahead of time; it undergoes near constant review.
A lot of folks want OBSD to add to this count stuff OBSD noticed may have been exploitable, then patched it anyways, frequently weeks or months or years ahead of a known exploit. When the known exploit comes out, they point to the OBSD version 6 months ago.
Exploits are counted that can violate current, stable systems, not OBSD 2.8.
This is like blaming MS for the exploit that allowed slammer to spread; if people patched their systems when they were supposed to, they wouldn't have been inconvenienced. OTOH, MS should have caught the bug ahead of time.
I feel OBSD falls into the latter category, not the former. They are more than likely ahead of the game. Given what I've seen of security reports on Linux and FreeBSD over the past 2 years, OBSD tends to play catchup in coming up with fixes. Rather, they tend to fight the tide that their "policy" in reporting exploits is wrong.
Oddly, I think that is more a testament to them doing things right as opposed to your attitude that they are being purposefully deceitful.
Yeah those "NO CARRIER" jokes just aren't fun@~%4!.z^%r#$% NO CARRIER
Life is too short to proofread.
It all depends on whats going on. If it's just random messing around and automated scans and whatnot, of course it won't matter that much. But if you're in charge of something important, and someone is specifically targetting you, then you have to be aware of indirect attacks as well as direct ones. Maybe you're locked down as much as you can and you've got your hosts.allow set up correctly, but who knows if your immediate upstream router has unpatched Cisco firmware?
also are quick fixed and is *generally* harder to exploit. And the patches are stable. not as the first slammer patch that wasn't fixing the M$ problem @ 100%, thus requiring a second patch for the same problem....
I was there.
No, it would still be an ssh vulnerability.
Remember, we're supposed to seperate the OS and the apps that have the holes...remember?
Or are we still using the term "Windows hole" when referring to Outlook?
"Sufferin' succotash."
1. Make lsh incompatible w SCO UNIX
2. ???
3. WTF?
4. Profit!!!
how long until
But it is common for irresponsible vendors *cough*redhat*cough*debian*cough to fsck everyone else when they are invited to this groups.
Remember some vendors have multiple versions to update, and a lot of testing before releasing. At least a whole day of work.
Sure, full disclosure ppl would argue that, but maybe there's a middle chance... for example telling ppl some workarounds (if there are) just after knowing the patch, but way before releasing the advisories/patches.
Anyway, I hate here on /. ppl claim stuff like crazy. And instead of blaming the vendor arseholes who shoot others in the back for nothing, blame responsible and respected agents (be it a vendor or someone like Theo)
Just checked up2date and saw the RPMs there. Not sure if they fix the bug you mention, but at least they've patched the gaping security hole now.
-------
"Every artist is a cannibal, every poet is a thief."
I'm on a couple of the lists that should have been informed. As one example, NetBSD's security officer has received no information from the openssh team at all. I'm unaware of other groups having received official word.
In your netbsd prompt type ssh -V. It's probably using ssh 3.4, not 3.6, assuming you're using the core system's ssh (Not the pkgsrc one). You should be unaffected by this hole.
Redhat has finally posted patched RPMS on their errata pages. Scroll down and select your release.
Redhat just released an advisory with links to updated RPMS: RHSA-2003-279
RedHat has fixes (source and binaries) on their FTP site and docs in the erratta pages.
l
https://rhn.redhat.com/errata/RHSA-2003-279.htm
For RedHat 7.1: openssh-3.1p1-9
For RedHat 7.2: openssh-3.1p1-10
For RedHat 7.3: openssh-3.1p1-10
For RedHat 8.0: openssh-3.4p1-5
For REdHat 9 : openssh-3.5p1-9
Good luck at getting to their FTP servers. Hopefully, the mirrors will get them soon.
The FreeBSD team has released a related Security Advisory and issued patches for affected FreeBSD versions as well as OpenSSH in the ports tree.
Corrected:
2003-09-16 16:24:02 UTC (RELENG_4)
2003-09-16 16:27:57 UTC (RELENG_5_1)
2003-09-16 17:34:32 UTC (RELENG_5_0)
2003-09-16 16:24:02 UTC (RELENG_4_8)
2003-09-16 16:45:16 UTC (RELENG_4_7)
2003-09-16 17:44:15 UTC (RELENG_4_6)
2003-09-16 17:45:23 UTC (RELENG_4_5)
2003-09-16 17:46:02 UTC (RELENG_4_4)
2003-09-16 17:46:37 UTC (RELENG_4_3)
2003-09-16 12:43:09 UTC (ports/security/openssh)
2003-09-16 12:43:10 UTC (ports/security/openssh-portable)
Ooops, I had totally forgotten about that old copy of the README file in the ftp archive. After it was pointed out to me in private mail, I've replaced it with the current README. /Niels (LSH author)
So you want us to trust a tool when the
developers don't bother to update the
WRONG and outdated documentation?
This isn't some cute gnome utility that
makes penguins dance on your X11 client.
This is a security program. How much
confidence do you have in a tool where the
docs are allowed to slide?
I've read the patch on SecurityFocus. It's very simple. It looks like there is a buffer that at some point needs to be reallocated to fit more data. However, if that reallocation would put the buffer over 32KB, then the reallocation is not performed. The bug was that the recorded size of the buffer would be increased, even if the allocation was not performed, but not reset back to the original size. The patch only increases the recorded buffer size if the buffer really is grown.
An exploit of this hole would have to find a way to trigger this buffer allocation, and get it to overflow 32KB. Since the allocation would not take place, but the recorded buffer size is still large, there would be an unallocated memory area that could be referenced by code that uses that buffer. One would need to use that to overwrite program code with exploit code.
A solution to the problem with music today
missing000's comment is quite correct, there's a mistake in my original post. Omit the DenyUsers line, it will override the AllowUsers line. Just use the AllowUsers line by itself.
Sorry.
AllowUsers you@your_ip_address
Remember, always test making a new ssh connection before logging out of your existing one, after restarting sshd.
-- http://frobnosticate.com
actually it's patched, and has been since ~ 11:00 EST. you're supposed to have security.d.o in your sources.list if you want security fixes.
-- bartman
http://readme.gzipped.org/~max/debian.html
Choose one of the sources.list lines depending on your CPU, insert it into your sources.list, update, upgrade, and you're safe.
I applied the patch from http://www.openssh.com/txt/buffer.adv to the original 3.6 Debian package from testing.
Sorry for the German text, I shared this repository of Debian Packages (unstable packages ported to Woody, compiled with gcc-3.2 and CPU optimizations) only with my German friends till now...
The bug involves an inconsistency with
the recorded and actual buffer size.
The buffer is allocated off the heap,
but an exploitable overflow really only
works for buffers allocated off of
the stack (where you can overwrite
a subroutine's return address and redirect
program flow). I guess if there are subroutine
addresses in struct's dynamically allocated
off of the heap, then you could redirect
program flow, but I am suspicious of this.
If using binaries/source from non-vendors weirds you out, you can also grab the RPMs for RH9, or the SRPMs for other releases (and presumeably other distros like SuSE, Mandrake, et al. as well) directly from the OpenBSD guys. The only US mirror which had them (as of this morning when I heard about the announcement) was ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/por table/rpm/. I didn't look through the international mirrors, but I got pretty good speeds from across the country.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
This bug is only public knowledge because the OpenSSH people have already fixed it.
And it's only a problem because they didn't tell anyone else. There are too many people looking at SSH for holes to try and slip a security fix into a new version without mentioning it and backporting the fix. Maybee they didn't appreciate that it was an exploitable bug. Maybee this whole topic is hype and there is no exploit. Assuming they new it was an exploitable bug, they should have coordinated a fix before releasing a patched version. A local root exploit in Galeon, Grip, etc...upsetting but no use losing sleep over it. A remote root exploit in SSH, Apache, xinetd, etc...get is fixed ASAP and don't hide the problem.
Of course, do this at your own risk, but it worked for me on RH8, before the RPMs were realeased, so I did it the old fashioned way.
r .g z
m l
First you need the latest version of OpenSSL:
http://www.openssl.org/source/openssl-0.9.7b.ta
$tar -zxvf openssl-0.9.7b.tar.gz
$cd openssl-0.9.7b.tar.gz
$make
$make test
$make install
If you haven't stopped sshd yet, then do this:
$/etc/rc.d/init.d/sshd stop
Then you need to get the latest version of OpenSSH:
Go to one of the mirrors listed at:
http://openbsd.groupbsd.org/openssh/portable.ht
I've found this one to be realiable:
ftp://rt.fm/pub/OpenBSD/OpenSSH/portable/
And download this file:
openssh-3.7p1.tar.gz
Then do the usual:
$tar -zxvf openssh-3.7p1.tar.gz
$cd openssh-3.7p1
$./configure
$make
$make install
And that should fix it. Just restart sshd:
$/etc/rc.d/init.d/sshd start
Then confirm that you're running the latest:
$ssh localhost -V
SSH should be 3.7p1 and SSL should be 0.9.7b
--tcpiplab
iptables:
#!/bin/sh
insmod iptables
iptables -F INPUT
iptables -P INPUT ACCEPT
iptables -A INPUT -j ACCEPT -p tcp --destination-port 22 -s 1.2.3.4
iptables -A INPUT -j DROP -p tcp --destination-port 22
iptables -A INPUT -j DROP -p udp --destination-port 22
ipchains:
#!/bin/sh
insmod ipchains
ipchains -F input
ipchains -P input ACCEPT
ipchains -A input -j ACCEPT -p tcp --destination-port 22 -s 1.2.3.4
ipchains -A input -j DENY -p tcp --destination-port 22
ipchains -A input -j DENY -p udp --destination-port 22
Can't see anything at the full disclosure mailing list poiting anything serious. Only a priv mail from theo stating the bug doesn't look exploitable for now.
So that must mean that what I read did not exist?
Try here
That is the message that describes that privsep was enabled - a few messages before, the ISP incidents are described.
Do you trust anybody posting something they've heard?
No, and neither should you.
But tell me, why would I deliberately lie?
The guy that started the "new ssh exploit?" thread stated first he knew of an ISP *blocking* sshd traffic (this is far from an exploit).
Yes, that mail states that they are blocking *because* they had several boxes rooted from what *seemed* to be an sshd exploit.
Can you read at all?
So FU** YOU.
Charming.
I am sure that if you could count, you would tell me in how many ways as well.
SO BAD THERE ARE OTHER ARCHIEVES AROUND.
*plonk*
I don't know what you are smoking, but I will try to avoid your dealer.
I see *nothing* in what you wrote above, that casts any doubt on the correctness of what I posted. It was doubtful whether privsep would prevent the bug, and I stated that in the post to keep it correct.
What's your point? So far you've called me a liar, become my first slashdot "freak", and blurted all sorts of things about how unfair the world is to you. Why is it that we need to care about your oppinions? Do you have an oppinion at all? What are you trying to tell us here?
120 character sigs suck. Make it 250.
No, we're talking about the lsh that does do X forwarding. And port forwarding. You can even tell it to just open a connection and not spawn a shell, in case you need just the port forwarding.
SECURITY 101: The only way to really protect yourself from unwanted connections from the outside world is to unplug from the network. Of course, that's hard if you're trying to build a Web Service. Even that isn't a guarantee if you can't provide physical security to prevent access to the system console. There's a handy little floppy boot disk I've seen that will break into any Windows box made, though it won't help you if the file system is encrypted. I have a feeling there are similar exploits possible on Linux or other UNIX systems if you can get to the physical box.
Point being, security is a question of choices and compromises. What series of choices (such as leaving a ssl port open or closed) gives you an acceptable risk, and still allows you to do what you need to do?
Your Servant, B. Baggins
OpenSSH refuses to allocate a buffer over a certain size, but doesn't set the buffer size value back to its previous value. When this occurs, OpenSSH immediately calls fatal() to clean up and exit. The connection is closed, and the buffer is not reused.
The problem is that the cleanup code will, in some cases, attempt to zero the block at the larger size, resulting in OpenSSH crashing.
Because no data other than zeroes is every written to this buffer after the failed allocation (unless the FreeBSD folks missed something), this bug cannot be exploited except as a denial-of-service attack unless combined with some other exploit that allowed you to overwrite the exception handling vectors and add arbitrary code (in which case, there are probably much easier ways to perform the exploit).
120 character sigs suck. Make it 250.
Get the new ones off Red Hat's site. They will say 3.1p1 (see here for why) instead of 3.7, but they do contain all current security fixes.
What a stupid comment. Totally and utterly stupid.
OpenSSH is considered by many to be a core service, right up there with the kernel. If there is an exploitable bug in OpenSSH, there is a bug in OpenSSH. Plain and simple. It becomes important that we know about the potential bugs.
It's not an attempt to discredit Theo, or is it nitpicking at the OpenSSH service. I'd prefer these were found and fixed, rather than them being left unknown in order to keep Theo's ego inflated.
I read your post and thought to myself, "this was fixed before the exploit? I upgraded my system a few weeks ago, I wonder if I got 3.7?"
Instead of going to figure out when 3.7 was released (could have been today for all I know, I didn't read everything this article linked to), I went looking for how to track my emerges and I found:
this.
Hope this informs someone else.
Cheers
~Dalcius
Rome wasn't burnt in a day.