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]
Only one remote hole in the default install, in more than 7 years!
Oops!
Given that the default install has ssh turned on, will they change it to "two remote holes" ?
How much do you want to bet they'll just sweep it under the carpet and hope people forget? If you follow misc@ carefully you have probably seen it done before. Lets make some noise and force Theo to finally update that!
New manifestations of Job Security for us techs!
Shift happens. Fire it up.
C:\>
at least it's out in the open...
-H
--- #@$DF@#2%@^%3^&*$%FRHG%%[NO CARRIER]
"upgrade" to GNU lsh or block SSH from everyone except known hosts (the VPN option does basically the same thing).
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.
At this point basically no one (publically) seems to know what the exploit is. If you want to find out about exploits THIS early, then you should be reading those mailing lists yourself. 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.
What's the next article going to be: "Linus Torvalds is in the MIDDLE OF A SENTENCE describing the future for 2.6! In four seconds, we'll finish hearing what he has to say!"
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?
I mean really - telnet is perfectly secure unless you use a direct connection. Use of a quantum tunnelling encryption layer and probabilistic key generation means you get the maturity of telnet with a greater level of security (I'm talking non-recursive factorial strenth here).
ssh is just for losers who can't set up teransparent network layering.
If linux was installed on 98% of all machines in the world you can bet there would be a worm by now that would have taken advantage of this. Don't throw too many stones linux users.
Is it the same bug that requires me to type the full word "yes" or "no", and not shortcut keys 'y'/'n', when I want to connect to a remote server??
=)
Anybody got a copy on a REAL server?
See my blog at Who's Who
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)!
Nice idea putting it on Slashdot, now it's out of the wild.
I have over 70 freaks, do you?
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.
SSH brings down the house....again
I haven't noticed any scanning or anything going on here at work, but I'm disabling SSH for now...
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.
The lengths some people will goto...
You mean they're doing it in Basic?!!
% apt-get source ssh/ openssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h&f= u' | \ ..
% cd openssh-3.6.1p2 # this in unstable, might be a different version in testing/stable
% wget --user-agent="mozilla" -O - \
'http://www.freebsd.org/cgi/cvsweb.cgi/src/crypto
patch -p3
% fakeroot debian/rules binary
% cd
And you should have new packages ready to be installed..
Just when I spent all day setting up password less authentication I have to revert to ..
You're correct; this is often more noise than signal. But
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
An updated ssh package just hit the Debian security mirrors.
For anyone running debian stable:
apt-get update
apt-get upgrade
Remind me why the most security critical part of ssh is written in C again... shouldn't a supposedly security conscious group be using a more suitable language?
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
"In the last few hours there have been several reports of a M$ bug, with an exploit seemingly in the wild. Oh god not again... The lengths some people will goto to try and damage Billy Gate's pride."
See how easy it is - that should be a -1 flamebait topic on your post.
Now that thats over with I belive (read: may be mistaken) but the latest version from www.openssh.com addresses that issue. But it could just be a similar issue and i'm reading it wrong. If I am enlighten me.
Ave Molech Setting
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......
hi! if your not sure the box you are trying to root was patched, just use the new nmap version detection system! :P
... exploitable
S ep/0127.html
http://lists.suse.com/archive/suse-security/2003-
get your things straighten out first, befor posting bullocks and fud out on such a huge site as slashdot, where all them morons dont think for themselves and are about to start a panic in the sight of a supposedly ssh exploit...
jeeezuz, the nerds and morons used to have way higher IQs in the past than today....
... can be found here http://archives.neohapsis.com/archives/fulldisclo
'least it's already fixed in the newest version. Considering this is the first incident I've seen since SSHv1, that's saying something. If M$ were doing this well, I'd be using it with FAR less cussing.
Oh, the day we finally have a full, well-rounded DirectX-type lib for Linux/Mac/Win32 will be a great day indeed. Then I can totally blow 2k off my box and just be happy and stable. SDL is nice, but I've heard FAR too many poeple complain about it.
Well, let's get SSHd fixes out and move on.
-What have you contributed lately?
Microsoft holes demonstrate the inferiority of closed-source commercial software.
Open source software holes demonstrate the ability of the community to provide superior service by patching holes quicker than Microsoft does.
Now do you understand?
Do you take pleasure in others' suffering?
OpenBSD has one of the best track records out there. Seems to be that they're held to a different standard than other OSes/distributions (which in a way can be considered a compliment).
Yes, Theo is a bit over the top at times, but you have to admit he does a certain right to, given OpenBSD's track record.
Personally, I have upgraded all my systems to lsh. The code looks much more trustworthy, and I'm sick of upgrading every few months.
How did this get modded up? What 'more suitable language'-based operating system do you use?
www.sitetronics.com/wordpress
Some people pointed at this
o /o penssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h
http://www.freebsd.org/cgi/cvsweb.cgi/src/crypt
though I cannot see how it can be a vulnerability.
~velco
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.
Ensure that your benevolent dictator's ego isn't writing checks that you can't cash.
This has little to do with Theo's "pride". If there are exploitable bugs in OpenSSH, they have to be found and fixed, and "pride" has nothing to do with it. I'm sure people would search for bugs in a program as critical as ssh whether or not Theo had any involvement.
What I am most upset about is that Theo has not seen fit to send out any sort of official announcement to the various operating system vendor security teams -- or to anyone else -- even though an apparently simple patch is available and could be distributed.
- 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?
See what ports are open and then research them to see what they are and if they need to be closed and if so, how to close them. You don't need to worry about SSH exploits if it's not running.
Ben
Work Safe Porn
An OpenSSH Security Advisory was just posted about this.
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.
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."
Remember to use long jumps if you want to goto more than 255 bytes of pride-damaging.
In Soviet Rush, today's Tom Sawyer gets high on you.
To be found at:
http://unthought.net/ssh-vuln.html
Well, ok. You made my coffee break...
I just did and "apt-get update" and "apt-get upgrade", and the new patch is there and it appears to at least not fubar the system. Hooray for easy administration! Hooray for distributed fixing! Hooray for debian!
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
I just ran apt-get update myself and apparently 1:3.4p1-1.1 is the latest and includes this patch:
# apt-get update
# apt-get upgrade
# ssh -v
OpenSSH_3.4p1 Debian 1:3.4p1-1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
You try TO do something, you don't try AND do something. Why do geeks get this wrong more often than they get it right? Live and learn, please!
/. news item contributors write like grade-school dropouts, the /. editors should try and [sic] edit their news items.
And when
I know there are a bunch of Ada hackers out there and people with other languages they are advocating and trying to protect, this seems like an ideal task to prove your prowess and the strength of your tool set by building a better SSH server and client. I'd love to see some network infrastructure servers done in Ada.
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.
EVERYTHING COUNTS IN LARGE AMOUNTS!
Like the beaver, it's just Dam one thing after another
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?
If this is Lindows, you are probably not running sshd. Furthermore, you should not do so.
To do damage, you need two things. First, you need to get into the machine, and second, you need to elevate your privilege to root. So to get nasty, you either need an exploit for a service running as root, or you need a second exploit to become root. Especially in recent years, most daemons have tried very hard to avoid running as root, forcing the need to find two bugs instead of one.
Lindows runs the ordinary user as root. I don't know if they have a better policy for running daemons as non-root - I certainly hope so. But running ordinarily as root removes one line of defense against crackers.
Add to that the fact that Lindows is aimed at the inexperienced market, so these systems *may* be less likely to be correctly patched.
The living have better things to do than to continue hating the dead.
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
Didn't solaris 9 ship with an openssh-based implementation? Has anybody seen traces of patches from Sun?
I looked around, but didn't see any indication, nor could I read the mailing list archives that were linked to in the story.
http://bowmore.dcs.st-andrews.ac.uk/rpms/ contains source and binary RPMs. The directory should not be accessible outside the .ac.uk domain, as I don't have the bandwidth to take a /.ing. Even if I've messed up the configuration, please do not try to download the RPMs. PLEASE
Also please note, these are barely tested. I patched, compiled, installed and ran the server/client, but haven't had time to do much more. People may want to wait until the official RedHat RPMs.
If someone wants to set up a mirror, post under here and I'll work something out.
wget http://incoming.debian.org/ssh_3.6.1p2-6.0_i386.de b
dpkg -i ssh_3.6.1p2-6.0_i386.deb
Might only work on sid.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
The short answer is yes. If you're running anything previous to 3.7[p1], your version is affected.
It may not be -vulnerable- at this moment due to the you've got it configured (I don't know if this is the case or not, just an example).
Chew on this, though: do you really want to have to go through all of the old security advisories each time you make a config change to see if what you're doing could open you up to a really old vulnerability?
Patch now so it doesn't come back to bite you later! =)
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
OpenBSD is exploitable too. So much for priv seperation and all the anti-exploit fun.
"disseminated to the bad actors." I fail to see what Burt Reynolds has to do with it.
Last one in jail is a fascist.
"He dips the pen...in the ink, and he's off! It's the first word, but it's not a word - oh, no! - it's a doodle. Way up on the top of the lefthand margin is a piece of meaningless scribble - and he's signed his name underneath it! Oh dear, what a disapointing start. But his off again - and here he goes - the first word of Thomas Hardy's new novel, at ten thirtyfive on this very lovely morning, it's three letters, it's the definite article, and it's "The". Dennis."
"Well, this is true to form, no surprises there. He started five of his eleven novels to date with the definite article. We had two of them with "It", there's been one "But", two "At"s, one "On" and a "Dolores", but that of course was never published."
- Novel Writing (Live from Wessex)
Ignoring the unix updating tools, it's hard to update.
No kidding. Let me guess, ignoring the sun, it's dark?
Slashdot Patriotism: We Support our Dupes!
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
So when an exploit is discovered in Windows, it's the evil Microsoft's pathetic fault. But when it's something in the *BSD/Linux worlds everything is "uh, well, see... um..." not so bad?
Nope. By the time we get close to 98%, we will have SELinux by default.
This bug, like any other non-kernel bug, is useless for an attacker on a system with mandatory access controls and a proper policy configuration.
The worms will need a kernel bug *and* a remotely exploitable bug to propagate.
http://forums.gentoo.org/viewtopic.php?t=84879&hi
There's no ebuild pushed out for it yet, but the second link describes a workaround. (Haven't tried it yet, but will in the near future.)
20 January 2017: the End of an Error.
.. and with the release of a Nmap version that performs version detection on services.. hm.
That's the fundamental problem with tools like, Nmap. While they might be good tools for the good guys, they're also terrible tools in the wrong hands.
Anybody else heard rumours of this exploit a couple of months ago? Seems like somebody have tried to keep the lid on this.
How small a thought it takes to fill a whole life
Does OpenSSH run on Windows?
If so this would be a Windows vulnerability too.
I wonder what they will be using instead...
Does anyone know if this exploit effects Cygwin installations of SSHD? I _really_ need to know.
Need a UNIX/Linux/network guru in the Boulde
Unless I missed it somewhere, it looks like this is not a problem with OpenSSH on Solaris?
Can anyone enlighten me on this?
--Jon
koniosis wrote:
It appears that *nix systems now have an exploit, where are all the people claiming "Linux has no exploits that need patching", showing how insecure Microsoft are?
Where are all the people making such claims, hopefully flipping burgers. Of course Linux has the occasional exploit, which of course requires patching.
There are still differences between a Linux exploit and a Windows one. The Linux one is generally fixed faster, and the fix is more likely to work the first time. A Linux exploit is less likely to give the cracker full root access to your system than a Windows one. Also, most decent Linux systems (eg Debian) are considerably easier to patch than Windows (apt-get update, apt-get install).
Sobig and Blaster came and went and microsoft got bashed so damn much, when something like this happens to linux its like "oh shit happens, nevermind".
That's because Sobig and Blaster were seen everywhere, they did actual damage to actual systems. Blaster might even have exacerbated the recent Northeastern US/Southeastern Canada blackout. Any exploits of this OpenSSH bug, if such exploits exist, are so rare that most people are calling them rumors. Nobody would sanely call Sobig a rumor.
And it's going to be harder to patch *nix systems than windows (don't say Windows update is hard to use and *nix is as easy, its not [most of the time, ignoring redcarpet ect])
I have used apt-get, redcarpet and Windows Update. Apt-get is easier, faster, and more reliable than both redcarpet and Windows Update. Redcarpet is just as easy, and more reliable compared with WU. Windows Update often requires reboots, and occasionally trashes systems altogether.
SSH is probably the most used administration tool for *nix, probably the last thing people want an exploit in. Microsoft don't seem so on their own anymore.
Nope, they're still in a league of their own regarding security problems. Sorry to break it to you.
----
Open mind, insert foot.
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.
Whew. I don't know about the rest of you but knowing that Theo has a new shirt to wear sets my mnd at ease. :-)
Anybody know if the commercial versions of SSH (like the ones from ssh.com or F-secure) are vulnerable to this same exploit?
Is there a temporary workaround for Redhat while I wait for the updated RPM?
eTrade SUCKS
mod parent up!
Is F-Secure SSH 3.2.5 vulnerable?
It appears that *nix systems now have an exploit, where are all the people claiming "Linux has no exploits that need patching", showing how insecure Microsoft are?
You are comparing apples and oranges; OpenSSH is not part of the Linux kernel, it is a commonly-used piece of third-party software. Past criticisms of Microsoft have been directed at vulnerabilities in the core Windows functionality, not at script-kiddie backdoors in IRQ clients.
Tubal-Cain smokes the white owl.
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)
...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)
where are all the people claiming "Linux has no exploits that need patching"
Yes. Where are they? I don't see any around here. Maybe that's because nobody claims this. What people do claim is that Linux is far more secure than Windows. One hole doesn't change this.
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
The upgrade shouldn't touch your key files. Even the IP#/domain-name checksums shouldn't change when you update.
http://tinyurl.com/4ny52
Why the crap do they have to make up their own version numbers?!? Red Hat does this too and it drives me nuts...
What would be so bad about calling it 3.7p1 like the rest of the world?
What? An exploit that only affects Linux? And all this time, I thought Linux was secure. Oh well, time to switch back to Windows Server 2003.
yes it does. but it's not in the default install, and sshd is not on by default even when you install openssh.
US Citizen living abroad? Register to vote!
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
Step 1, get the older 3.6.1p1 src rpm from any of the mirrow sites. and install. rpm -U openssh-3.6.1p1-1.src.rpm
Step 2: untar the the file in the source dir
cd /usr/src/redhat/SOURCES/
tar xzf openssh-3.6.1p1.tar.gz
Step 3: replace the buffer.c file with the one from here here
cd openssh-3.6.1p1/; cp /tmp/buffer.c .; cd ..; tar czf omniORB-4.0.2.tar.gz openssh-3.6.1p1/
Step 4: build the rpm. cd ../SPECS; rpmbuild -bb openssh.spec
Step 5: install, cd ../RPMs/i386; rpm -U --force openssh*; /etc/init.d/sshd restart
Thats 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.
Could somebody explain the problem and patch in english? I see that buffer->alloc could have an invalid value for just a few lines...I can't tell whether this structure is shared by more than one thread, but if not, where is the exposure, since it is just immediately reassigned/reallocated?
It's 10 PM. Do you know if you're un-American?
Hmm....
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
Better keep it firewalled behind my VPN.
http://www.securityfocus.com/archive/1/337662/2003 -09-13/2003-09-19/0
No.
amen!
'Cause Debain dosen't run 3.7 in 'stable'
3.4p1-1.1 is 3.4patch level 1.1, indicating a security fix.
If you are trying to compile on OpenBSD 3.3 or older (e.g just about every OpenBSD box out there), note that before doing the build you need to:
1.) Unpack the OpenSSH 3.7 source
2.) Apply a patch available here
If you don't apply the patch, "make" will fail. See the instructions here.
Anyone have a list of mirrors known to have the patch or 3.7 source? So far the only place I've been able to get 3.7 was at ftp.openbsd.org itself...haven't found a mirror that has replicated already.
Yeah those "NO CARRIER" jokes just aren't fun@~%4!.z^%r#$% NO CARRIER
Life is too short to proofread.
cvsup
make buildworld
make installworld
(went into the wrong thread - ack!)
Hmm....
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f
Better keep it firewalled behind my VPN
maybe it has to do with the release being a fix for a certain exploit????...
Still, you'd say that a "buffer overrun" (?) in a file called "buffer.c" would have been found earlier.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
reading/posting from lynx.. the "2by4" reply is intended for the parent of your post.. :)
Not anymore:
Only two remote holes in the default install, in more than 7 years!
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."
OpenSSH buffer_append_space() Error May Let Remote Users Execute Arbitrary Code and OpenSSH "buffer_append_space()" Vulnerability
1. Make lsh incompatible w SCO UNIX
2. ???
3. WTF?
4. Profit!!!
how long until
If Microsoft made SSH, they'd deny the existence of this bug for 6 months then release a Rumplestiltskin patch that made you agree to waive your rights to your first born child, the fourth amendment, and all your base.
It's not just that people want to make improvements to source code - sometimes we want to FIX the source code before someone else can mess with it. Remember this next time someone reads a MS talking point saying that few users want to edit the source code to applications.
microsoftword.mp3 - it doesn't care that they're not words...
One remote hole in seven years is a statistic. I guess the OS should be trusted as much as statistics can be trusted.
They're not making up their own version numbers.
The actual version being run on a Debian stable system is 3.4p1-1.1.
It's version 3.4 exactly as it was origonally released. Debian stable does not upgrade packages, that's why it's stable. Instead, the fix is backported to the older version so that it is not only stable but secure as well.
I have a colo that only allows ssh access.
How can I safely test, stop, and start sshd?
If I am already connected via openssh, will stopping sshd kill my connection?
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)
thanks
As I'm sure many are in the same boat, I don't care about the version RedHat is responsible for. I want to know whether the vendor source code is/was vunerable.
./ effect to find out myself at this moment.
Pity, I cannot get past the
To-do List: Receive telemarketing call during a tornado warning. Check.
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."
What are the odds that there is a subcontractor for a subcontractor who is working on finding and "documenting" vulnerabilites in linux right now? It's unethical but it would make good business sence. Those two things seem to be required for anything to happen within Microsoft these days so it must be true. (grin)
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Look at this: http://lists.netsys.com/pipermail/full-disclosure/ 2003-September/010146.html
Remember all the hoopla when everyone *had* to upgrade to privsep immediatly? The lack of details? Theo wining about "hours and hours of hard work" but taking his time to write back and shit all over the person who's merely asking if there's a patch.
Deja-vu. I clearly remember that FreeBSD wasn't even exploitable then but we got told afterwards.
Maybe this is Theo's approach to mass marketing but I find his behaviour close to shizophrenic(sp). Theo the saviour against the rest of the world. It's also amusing to see (some) people go out of their way to *defend* this behaviour. What a cult.
Oh well, just observing... (shrugs)
You can restart sshd without killing your connect. When you SSH to a box the sshd process spawns a copy for your connect. You can restart the primary process without it dropping the existing connections.
I have a RedHat 9 box. I have TCP wrappers setup to only allow connections from two ip addresses. Does anyone know if that will prevent this attack?
Right! And where's the rampant, bring-the-net-to-its knees exploit that alerts everyone to the fact?
I've just upgraded my machine using red hat network.
Aw, sweet I'm so there.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
The OpenSSH team created the exploit and released it to help motivate folks to upgrade quickly.
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
No one makes mention but should it be assumed that any os using ssh is vulnerable. ie, freebsd, netbsd, cygwin, mac, as well as the many linux distros.
I just downloaded the patched version for my RH9 box from up2date.
Something goes bad with Unix - Shame on the exploiters. Something goes bad with Windows - Microsoft sucks. I really appreciate the humour :)
Worship the Fish... or DIE!!!
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.
still remains unpatched. . . *shivers*
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
That is why I only use Telnet. Never heard of anyone hacking Telnet.
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)
Does this not defeat the purpose of privilege separation? Or at least show that it is imperfectly implemented? I thought the whole point was to prevent a privilege-separated process, no matter how buggy or what its nature, from gaining general root access...
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)
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
Or are we still using the term "Windows hole" when referring to Outlook?
Well, if you had said Outlook Express, then the answer is YES since MS claims OE is an inseperable component of IE and IE is an inseperable component of Windows itself, then OE == Windows.
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...
Anyone has an idea of where to fetch a 3.6.1p2-6 + fix or something? :)
yhbt !
hth. hand.
-tirel
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.
Obviously, the person contacting the machine has to know the secret password, and also what port the sshd is going to be started on. This seems so simple and stupid that it'd be darn near impossible to have a buffer overflow, and while it could be subject to denial-of-service attacks, few things aren't.
Extensions like a 'kill' password that'd turn off this 'sshd-kicker', and a timer that'd kill the sshd if no one connected within a set period, and a limit to how fast the incoming tries would be allowed, would be easy to add.
This way, you could turn on sshd remotely when you needed to, and leave it off on other times. It's simple enough that I could write it without needing anything more than an MD5 library, and I could run it on my Palm Pilot.
PHEM - party like it's 1997-2003!
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.
Until a certain Hollywood director sends a couple of subs down to make a movie about it...
They haven't said anything about why they're blocking port 22 - I'm with Telus in Alberta, and they're pretty uncomunicative - but they blocked port 22 just about an hour or two ago. I was actually in an ssh session to my home computer, and all of a sudden it dropped. Nmap confirmed the port is now filtered, not that the server died on my machine.
What is the robbing of a bank, compared to the founding of a bank? -- Bertolt Brecht
Do you trust anybody posting something they've heard? 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). And afterwards he says "The systems in question are FreeBSD, RedHat, Gentoo, and Debian all running the latest versions of OpenSSH.". Note he is loosing it, the exploit FUD without base... and all ppl there start to talk about the bug as a fix against an exploit, though *nobody*, not even Theo's nemesis Darren Reed, mentions there is an exploit on the loose.
So FU** YOU. You scare ppl, you hide that and to d o so spread more fud by making wrong paraphrasing of the mailing list, hiding behind the slashdotted main archive.
SO BAD THERE ARE OTHER ARCHIEVES AROUND.
Or are we still using the term "Windows hole" when referring to Outlook?
I prefer the term "Microsoft hole" when referring to any of their rushed-to-market products.
Healthcare article at Kuro5hin
If I'm not terribly mistaken, that patch fixes the hole in question. So if they already have the patched SRPMs posted, why can't they have the patched RPMs there too? (as of this posting, they don't yet.)
Well, looks like it's time to install the -devel packages and get to work with rpmbuild.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
I have the network cable unplugged. HA! Beat _that_, crackers!
☠
...does anybody have it? I need to see if my 2.2.0p1 installations are vulnerable. It appears they are after reviewing the changes made to buffer.c, but I need to verify that. Somebody, please?
FOR CIRCUMVENTION!
1. temporarily wrap and firewall telnet services from your known and good IP.
2. login with telnet, upgrade ssh
3. test sshd and ssh
4. stop telnet from xinetd/inetd
RedHat released their errata about 1.5 hours ago :
l
... NOW !!!
https://rhn.redhat.com/errata/RHSA-2003-279.htm
Patch
:wq
FYI: patched RPMs are available via up2date from RedHat, its patching time again ;)
Somebody needs to work in a "this is Microsoft's Fault!!!" angle. Come on, this is slashdot; you guys are letting me down.
Manipulate the moderator system! Mod someone as "overrated" today.
You have to overflow a 0xa00000 buffer, or a 160 Mb buffer. It would take a lifetime with my poor link!
Thank the lord patching my FreeBSD servers is as easy as patching Windows servers with Windows Update!
'make world' is so quick and easy my grandmother can do it, and I don't have to spend all night waiting for the entire system to recompile.
Oh wait.
Anyone have Redhat 6.2 or Mandrake 8 RPMS? these boxes are so old the compiling of the RPMS isnt working. Thanks in advance.
If I've missed something critical here, please reply, but it looks pretty well documented.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The README in question is indeed gone, so the above seemed to have been Niels. Please mod up somebody!
Posters: whenever you feel the urge to type that phrase, please reconsider.
Mods: whenever you see someone has given in to temptation and used that phrase, please justify it and mod that post down.
[Set Cain on fire and steal his lute.]
ssh -V
My results were
OpenSSH_3.4p1 Debian 1:3.4p1-4, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
This is the version I have after doing an "apt-get update". Is this the version I need? Do I need to re-start the daemon to get the newest version or am I good 2 go?
Namaste
Gardner group advises everybody that, in face of this major security problem, that everybody should move to windows.
how long until
RedHat has already released a patch through up2date for this.
Word from Mandrake is that a patch should be on their mirrors in about an hour.
who are those slashdot people? they swept over like Mongol-Tartars.
I've got a whole bag of Ssh with your name on it!
That was a pre-emptive Ssh!
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
[slackware-security] OpenSSH Security Advisory (SSA:2003-259-01)
w are-8. 1/patches/packages/openssh-3.7p1-i386-1.tgz
w are-9. 0/patches/packages/openssh-3.7p1-i386-1.tgz
s lackware-cu rrent/slackware/n/openssh-3.7p1-i486-1.tgz
/etc/rc.d/rc.sshd restart
Upgraded OpenSSH packages are available for Slackware 8.1, 9.0 and
- -current. These fix a buffer management error found in versions of
OpenSSH earlier than 3.7. The possibility exists that this error
could allow a remote exploit, so we recommend all sites running
OpenSSH upgrade to the new OpenSSH package immediately.
Here are the details from the Slackware 9.0 ChangeLog:
Tue Sep 16 11:13:05 PDT 2003
patches/packages/openssh-3.7p1-i386-1.tgz: Upgraded to openssh-3.7p1.
From the OpenSSH Security Advisory
(http://www.openssh.com/txt/buffer.adv):
"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."
(* Security fix *)
WHERE TO FIND THE NEW PACKAGES:
Updated package for Slackware 8.1:
ftp://ftp.slackware.com/pub/slackware/slack
Updated package for Slackware 9.0:
ftp://ftp.slackware.com/pub/slackware/slack
Updated package for Slackware -current:
ftp://ftp.slackware.com/pub/slackware/
MD5 SIGNATURES:
Slackware 8.1 package:
a86d410e47fe8ab4a8e9f04293a94093 openssh-3.7p1-i386-1.tgz
Slackware 9.0 package:
ca1d0b1e658c5391067f2a9cf11fc239 openssh-3.7p1-i386-1.tgz
Slackware -current package:
c58003eaaf4362c8475f0f5a77f2adbb openssh-3.7p1-i486-1.tgz
INSTALLATION INSTRUCTIONS:
(This procedure is safe to do while logged in through OpenSSH)
Upgrade using upgradepkg (as root):
# upgradepkg openssh-3.7p1-i386-1.tgz
Restart OpenSSH:
.
"The meek shall inherit the earth, the rest of us shall go to the stars." Isaac Asimov
When compiling the source code I get the following error. Anyone have a clue on how to fix this? I'm trying to apply the update on a redhat 6.2 machine (patched and updated):
s sh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-serv er\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keys ign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-he lper\" -DHAVE_CONFIG_H -c cipher.cs sh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-serv er\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keys ign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-he lper\" -DHAVE_CONFIG_H -c cipher-aes.c
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/
cipher.c:68: warning: initialization from incompatible pointer type
cipher.c:69: warning: initialization from incompatible pointer type
cipher.c:73: warning: initialization from incompatible pointer type
cipher.c:74: warning: initialization from incompatible pointer type
cipher.c:75: warning: initialization from incompatible pointer type
cipher.c:76: warning: initialization from incompatible pointer type
cipher.c: In function `cipher_init':
cipher.c:230: warning: assignment discards `const' from pointer target type
cipher.c:209: warning: unused variable `klen'
cipher.c: In function `cipher_get_keycontext':
cipher.c:403: warning: comparison of distinct pointer types lacks a cast
cipher.c: In function `cipher_set_keycontext':
cipher.c:418: warning: comparison of distinct pointer types lacks a cast
gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/
cipher-aes.c: In function `ssh_rijndael_init':
cipher-aes.c:50: warning: assignment from incompatible pointer type
cipher-aes.c: In function `ssh_rijndael_cbc':
cipher-aes.c:78: warning: assignment from incompatible pointer type
cipher-aes.c: In function `ssh_rijndael_cleanup':
cipher-aes.c:116: warning: assignment from incompatible pointer type
cipher-aes.c: In function `ssh_rijndael_iv':
cipher-aes.c:129: warning: assignment from incompatible pointer type
cipher-aes.c: In function `evp_rijndael':
cipher-aes.c:147: warning: assignment from incompatible pointer type
cipher-aes.c:148: warning: assignment from incompatible pointer type
cipher-aes.c:149: warning: assignment from incompatible pointer type
cipher-aes.c:151: structure has no member named `flags'
cipher-aes.c:151: `EVP_CIPH_CBC_MODE' undeclared (first use in this function)
cipher-aes.c:151: (Each undeclared identifier is reported only once
cipher-aes.c:151: for each function it appears in.)
cipher-aes.c:151: `EVP_CIPH_VARIABLE_LENGTH' undeclared (first use in this function)
cipher-aes.c:152: `EVP_CIPH_ALWAYS_CALL_INIT' undeclared (first use in this function)
cipher-aes.c:152: `EVP_CIPH_CUSTOM_IV' undeclared (first use in this function)
make: *** [cipher-aes.o] Error 1
eTrade SUCKS
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
What's the best way for these two old versions? I cannot compile due to CPU stress problem (need to fix it) and kernel panics. Have not figured out why it is crashing. I can do a rpm upgrade without problems. I thought I could use Red Hat's RPMs but theirs are older and I noticed I have newer versions:
. 4p1-1
openssh-askpass-3.4p1-1
openssh-server-3.4p1-1
openssh-clients-3.4p1-1
openssh-askpass-gnome-3
openssh-3.4p1-1
rpmfind.net doesn't seem to have v3.7 yet. Thank you in advance.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
NOOP
You're out of date by nearly a year. 'apt-get update' only updates your local package lists, it does *not* upgrade packages. You need to upgrade to 3.6.1p2-7.
[suse-security-announce] SuSE Security Announcement: openssh (SuSE-SA:2003:038)
just that the time-to-fix is much shorter
Funny, they don't mention when they found the bug. They just mention that they did find the big and figured that they'd fix it for the 3.7 release. This wasn't a patch. Who the fuck knows when they discovered this.
that applying these fixes to running systems is usually much easier (in most distributions) than in a Windows system
Easier? Yeah, apt-get is easy, but not easier than 2 mouse clicks. Oh, that's mouse clicks if I want to update all 250 workstations in this company at once. Fuck, my fingers are tired.
no reboot required
Great, so the exploited version of the daemon is still in memory executing? You only need to reboot Windows for a patch if the files being patched are currently in use. This ensures that the old ones aren't lingering in memory.
one location for all necessary fixes
www.windowsupdate.com
Okay, maybe two, www.officeupdate.com, but to a lesser extent.
I don't think that it is unreasonable for Microsoft's customers to demand better patch/upgrade management
I don't think it's unreasonable to expect administrators to READ THE FUCKING MANUAL and actually learn how to use the products in question. It's funny how I, one person, can keep 250 Windows 2000 and Windows XP boxes up to date (zero viruses/worms in the past year, thank you) and spend maybe 10 minutes a month doing this, yet you seem so flustered. What exactly are you doing wrong?
http://www.mandrakesecure.net/en/advisories/adviso ry.php?name=MDKSA-2003:090
apt-get upgrade ssh
or
apt-get install ssh
or
apt-get upgrade
I'm worried that doing a complete upgrade (apt-get upgrade) will upgrade everything causing my system to freak out like it did the last time I tried to upgrade my version of debian unstable.
Namaste
I'm disabling ssh and using telnet until the patches come out. Just try and crack my box now you stupid ha%$&$#*^%$^&*
NO CARRIER
Did you read the "from" addresses? you are talking about 2 different sources, claiming stuff without *any* precission. (all following is asuming these are truly from more than one guy having fun)
So it isnt a first hand report, and the guy doesn't say the incidents are related to this ISP. And he is *asking* if someone knows if there is an exploit. This initiating mail has as subject "new ssh exploit?", see the punctuation at the end of it? But there is more on the followup from the same guy:
Are you blind? Doesn't that "upgrade to lsh" bullsh** ring a bell on your brain? Or the nonsense of blocking ssh protocol altogether? Or the VPN craze?
*Other* ranter follows up:
Unless they know each other or something, or this guy works at the ISP in question, wich they didn't imply, they are just spreading unbased gossip. On *what* machines were privsep up? Do you think that enumeration of vulnerable OSs is based on attacks?
You claim that the poin of your post is to state that "it looks like" privsep didn't help. Do you base it on *this* unbased, quite suspicious rants?
I am *not* saying there is no exploit, nor privsep does or doesn't help. The point of *my* post was to show other ppl your overrated post is, for me, just plain old FUD. And instead of just claiming it as you do, I give the links so the readers decide themselves.
I am a slashdot freak, since most of /. posts are like yours, just propagation of FUD. I just put my poin of view as challengeable, and *base* my opinion on something.
Okay, Mandrake just released the patches, and all my boxen are upgraded. That rounds out all of the major free software distros. So much for that.
(glances up at the MS vs. Linux scoreboard) How many power grids did we lose on that one?
who are those slashdot people? they swept over like Mongol-Tartars.
I trust that my Linux box with all the security built in and added is safe but until this gets resolved and I can aplly a patch I've turned off ssh just to be safe. Thanks for the warning. My logs look clean.
-Tim Louden
Just curious if anyone here has ACTUALLY managed to exploit it?
Myself and a few others have been working on it for a couple of hours thus far, and the attack vector is not apperent at all. While i would very much appreciate a hint, a simple truthfull confirmation that it indeed IS exploited will suffice. The platform, OS, and version will help as well. Replies either here or
xaiou At Info.ba
As others have pointed out, OS X seems vulnerable. No update is available as on Tuesday evening 7pm EST. To disable remote login via SSH in the meantime, go to System Preferences, Sharing, and unselect Remote Login.
I don't feel like sorting through 783 messages at the time of post, but is this bug x86 specific? Would sshd on 68k or PPC be vulnerable? *worried about his OS X installation*
Just to point it out: Since Remote Login is disabled by default, OSX is _only_ vulnerable if you switched it on.
And since it's PPC it doesn't seem very likely that there will be an exploit available before Apple releases a fix - or did I get something wrong?
So don't panic, just use SoftwareUpdate as soon as the patch is available.
k2r
Security Changes:
=================
All versions of OpenSSH's sshd prior to 3.7.1 contain buffer
management errors. It is uncertain whether these errors are
potentially exploitable, however, we prefer to see bugs
fixed proactively.
OpenSSH 3.7 fixed one of these bugs.
OpenSSH 3.7.1 fixes more similar bugs.
Time to patch & upgrade for the second time today?
Hands in my pocket
3.6.1p2-7 is out ... :)
True, I wish I could mod you up and the fucking funny guy down. First time: hahaha; second time: yeah, what ever; every other time: DIE, YOU STUPID FUCKING CUM GUZZLER!!!
I would never accept software with so many holes as openssh. Rumor says these exploits have circulated for the past 6 months. From now on I will only use GNU lsh! It is SSHv2 only software and have NOT had any remote exploits!
For mandrake users, check out:
http://www.mandrakesecure.net/en/ftp.php
This gets announced so soon after the new nmap, which will make it easier for both white and black hats to find vulnerable hosts. I'm not saying it's good, I'm not saying it's bad - but now's the time to find those hosts, black hat or white hat!
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
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.
If only Dan would write a secure shell package.
... i can't even get sshd running LOL
/etc/sshd_config /etc/ssh_host_rsa_key. /etc/ssh_host_dsa_key. ::. :: port 22. ::1 port 49553
debug2: read_server_config: filename
debug1: sshd version OpenSSH_3.7.1p1
debug1: private host key: #0 type 0 RSA1
debug3: Not a RSA1 key file
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: Not a RSA1 key file
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: setgroups() failed: Invalid argument
debug1: Bind to port 22 on
Server listening on
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from
debug1: Client protocol version 2.0; client software version OpenSSH_3.7.1p1
debug1: match: OpenSSH_3.7.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.7.1p1
debug2: Network child is on pid 11540
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug3: privsep user:group 75:75
debug1: permanently_set_uid: 75/75
setreuid 75: Operation not permitted
debug1: Calling cleanup 0x26e14(0x0)
I noticed the update about the patch was posted just about exactly a day after the original post about the exploit.
Slashdot is usually current enough, though not always.
But fixed in a day! I have NEVER seen Microsoft come close! Most Windows Updates come MONTHS after the security issue was discovered!
I think that's a score for Open Source.
Don't thank God, thank a doctor!
apt-get update
apt-get upgrade
The first updates the package database, the second does the package download & install.
I'm not entirely sure why it's not cron'ed by default. Does anyone know why, or is there any reason why you shouldn't do it?
Take a look at
g =2 11324
http://bugs.debian.org/cgi-bin/bugreport.cgi?bu
Which notes:
the OpenBSD project have released OpenSSH 3.7.1 which contains further updates for similar issues to the one fixed by OpenSSH 3.7. While they do not know if these bugs are exploitable (which they also said about the 3.7 buffer.c update) it may be worth investigating the additional updates in 3.7.1 and seeing if any of them are applicable to the versions in Debian, and if so reissuing the security update. (The diff between 3.7 and 3.7.1 is short and only seems to contain the potential security fixes.)
Which makes me wonder if the patches that are currently being distributed won't need to be updated agian very quickly.
I thought only Microsoft Operating systems had exploitable holes.
I don't understand. ??
Buffer overloads & stuff - isn't that only in Windoze XP ?
Dudes - I'm gonna have to deL33t my Linus OS and reinstall Bill OS...
3.7 is out? oh, err, i'm still running 3.4
:)
No, i'm not leaving any indication of my domain
Shouldn't the kernel be wiping pages when it hands them to new processes?
Hmmm... possibly not. This is a topic of some debate, apparently.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
OpenSSH 3.7 is available from Mandrake Update (via RPMdrake).
LOL! Ok, cool. Let's backport everything from Kernel 2.4 to 2.0 so it's both stable and secure!
I remember for the longest OpenBSD actually shipped with BIND 4, while BIND 9 was out. That's hilarious how long some vendors will keep backporting releases that even the authors have given up on.
Can I get an eye poke?
Dog House Forum
The problem was in buffer.[ch], which contains openssh's buffer structure and related functions. This is used in both the client and server. So, in short it is possible that both the client and server are vulnerable to exploits.
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.
From Debian's
security advisory:
This bug has been fixed in upstream version 3.7. For the Debian stable distribution this bug has been fixed in version 1:3.4p1-1.1.
Telling him to upgrade to 3.7 could easily send him into unstable, which he stated he didn't want.
because everyone runs SSH over UDP...
pf:
;)
pass in quick inet proto tcp from 1.2.3.4 to any port 22 keep state
block in quick inet proto { tcp, udp } from any to any port 22
Oh wait, Linux users like things to be excessively cryptic...
Jim Carrey was in Man on the Moon with Gerry Becker.
Gerry Becker was in Trapped with Kevin Bacon.
Burt Reynolds is easy: Burt and Kevin both starred in Starting Over.
Just a tought :-)
Sometimes the upgrade will require user intervention, so unsupervised is NOT recommended by me - YMMV.
No reason not to add this to your CRONTAB tho, just be aware that there may be problems.
Try that with windows!
I updated them while I was ssh'ed in from remote, wasn't worried about restart, restart, or crashes or screwing up other "patches" like MS products.
Just restarted sshd, and the connection I had was still there! How about that?
You windows people have no clue how cool this is, no crashes for months, this is way cool, you should try it.
Wait! It will warp your mind, so stay ignorant.
One of my servers got hacked by sniffing ssh v1 passwords and/or downgrading v2 connections to v1 if the server version is 1.99 it did the sniffing by first arp poisoning the server collocation switch. The source is something called poison.c if u in the mood for a few google searches. The thing is that v2 connections were downgraded even after upgrading to the latest openssh (if both v1 and v2 negociation is enabled in config) Maybe this is related somehow to the "bug but none known exploits" affirmation ?!
In related news, SCO is claiming the vunerable code in openssl was originally copied from the SCO sources.
An other temporary fix with iptables could be done with the recent module [1] by doing iptables -A FORWARD -p TCP --dport 22 --syn -m recent --name SSHCHECK --set iptables -A FORWARD -p TCP -i eth0 --dport 22 --syn -m recent --hitcount 20 --update --name SSHCHECK --seconds 60 -j DROP This way more than 20 SYN connection attempts per minute per IP will lead to blacklisting for as long as the potential attacker keeps hammering with connections. After 60 seconds of inactivity the IP will be delisted from the backlist. This could be useful as a script kiddie exploit will probably try lots of successive connections to cause the memory corruption [1]: http://snowman.net/projects/ipt_recent/
Sorry, first post to /. , HTML format standard and too used to BBs with auto br
Let's try this again:
An other temporary fix with iptables could be done with the recent module [1] by doing
iptables -A FORWARD -p TCP --dport 22 --syn -m recent --name SSHCHECK --set
iptables -A FORWARD -p TCP -i eth0 --dport 22 --syn -m recent --hitcount 20 --update --name SSHCHECK --seconds 60 -j DROP
This way more than 20 SYN connection attempts per minute per IP will lead to blacklisting for as long as the potential attacker keeps hammering with connections. After 60 seconds of inactivity the IP will be delisted from the backlist. This could be useful as a script kiddie exploit will probably try lots of successive connections to cause the memory corruption
[1]: http://snowman.net/ projects/ipt_recent/
I'm available to help people upgrade.
Todd Fries
en tea
Not really, since you (obviously) can't connect to the client from the outside -- thus you can't attack it.
The only way i can think of in which the client could be attacked is if the server was rooted or it's DNS/IP was hijacked, which is possible but rather unlikely. You rather see a lot of "scan and exploit" type of attacks, these days.
I have discovered a truly remarkable sig which this 120 chars is too small to contain.
I thought OBSD would keep me same fram them!
(good job theo; great OS/distro)
You can't judge a book by the way it wears its hair.