OpenSSH Local Root Hole 554
maelstrom writes: "Looks like someone's found a local root exploit for OpenSSH versions between 2.0 and 3.0.2. Seems as though its a one-off error, there is no public exploit, but there is sure to be one shortly. They aren't ruling out remote exploit. Recommending patching and upgrading ASAP."
More Proof (Score:3, Interesting)
Regardless of that though, I get on my knees and thank God everyday for SSH. It's saved me many many many hassles from simply forgetting to turn it off on computers on my home's network.
Re:More Proof (Score:2, Interesting)
Re:More Proof (Score:4, Insightful)
Commercial SSH (Score:3, Insightful)
I assume it wouldn't be as it's on a different code base, then again 'assume means making an ASS out of U and ME'
Re:Commercial SSH (Score:3, Insightful)
If the same error existed in Commercial SSH, someone stole some code.
Re:Commercial SSH (Score:3, Informative)
Not nesessarly true: OpenSSH and Commercial SSH have the same roots - http://www.openssh.com/history.html [openssh.com]
Correction: off-by-one (Score:5, Informative)
One-off: Something done intentionally but with no intention of repeating; a custom product, sample, or prototype.
Off-by-one error: An error in enumeration, such as starting or ending a count at the wrong value (e.g. 0 vs. 1), counting the starting/ending value in a cycle twice or not at all (e.g. in counting a group of people which includes yourself), counting delimiters as opposed to the items delimited (e.g. the "fence post" problem), or any analogous error.
These are rather different! When I read the abstract my first thought was "how can they determine that?"
-- MarkusQ
CERT Advisory (Score:4, Funny)
IBM AIX versions 4.3 and 5.1
Hewlett-Packard's HP-UX
SCO OpenServer 5.0.6 and earlier
SGI IRIX 3.x
Sun Solaris 8 and earlier
I. DESCRIPTION
Several implementations of direct serial connect console may have a serious security hole. In more than several cases, a guy (SA) sitting on a folding chair in a data center, directly logged in to the system via serial connection and dumb terminal, was hit over the head with a stick by another guy. The second guy was then able to gain access to the system by forcefully taking away the dumb terminal from the guy that was hit over the head, and use his login to do bad stuff on the system.
II. IMPACT
The guy that was hit over the head with the stick suffered a bump on the head, and bad stuff was done on the system.
III. SOLUTION
We recommend disabling ALL systems in your data center. Issue the following command on Solaris: init 5, then turn it off by toggling the on/off switch. This method will prevent any attack outside your network, from within your network, and by god, from within your data center. The is the best known method of stopping ALL security holes, including the "stick on the head" issue. As vendors report new information to the CERT/CC, we will update this section.
http://www.paulandangelle.com/cert_advisory.html [paulandangelle.com]
SGI IRIX 3.x? (Score:3, Funny)
Where's the PGP signature? (Score:2, Funny)
Doing an init 5 on a Solaris box will gracefully shutdown the box, and power it off. If you toggle the power switch after that you're just turning the box back on.
OpenSSH site already updated? (Score:4, Informative)
Here is what can be found on their web site:
"OpenSSH 3.1 released March 7, 2002."
Hmmm... That was quick! Especially since the advisory reads:
Pine Internet Security Advisory
Advisory ID : PINE-CERT-20020301
Authors : Joost Pol
Issue date : 2002-03-07
Application : OpenSSH
Version(s) : All versions between 2.0 and 3.0.2
Pretty good job.
Re:OpenSSH site already updated? (Score:2, Informative)
The vulnerability was sent to the OpenSSH team a few days ago. It was not publicized until a fix was in CVS.
Re:OpenSSH site already updated? (Score:5, Funny)
Four days without a remote hole in the default install!
Not sure if OpenSSH is enabled by default though.
Re:OpenSSH site already updated? (Score:4, Informative)
The OpenSSH people corrected the bug in their own source, which they would have had access to even if it was closed.
Sure, if they found out about it before a blackhat did. There's a good chance they wouldn't have. And anyone could've corrected the issue and submitted a patch; in OSS there may be a patch before the public even knows there was a vulnerability.
The vendor was notified ahead of time, which is one of the things that MS has been campaigning for. Why aren't we beating up on the guy who released this to the vendor first and not to the community immediately?
There's a policy among bug reporters to give the author a reasonable period of time to fix a bug before releasing it. MS gets that grace period about as often as everyone else, but they're so slow at getting out patches that the vulnerability runs rampant. If an OSS project is slow at getting patches out, someone else takes it upon his or herself to write a patch. Its sort of a self-correcting system.
smallest possible patch (Score:4, Informative)
For you guys too lazy to read:t xt [www.pine.nl]
http://www.pine.nl/advisories/pine-cert-20020301.
( I was going to post the patch here, it's really small, but apparently slashcode doesn't know what the blockquote tag is for, despite claiming it's supported)
But this isn't just an attempt at karma whoring, there is a point. When a single missing '=' can cause a root exploit in code that's generally considered well-written, who are these people that actually entertain the idea that Microsoft secured their software over the last month?
Re:smallest possible patch (Score:3, Funny)
I can't wait for djbssh (Score:5, Funny)
-russ
Re:I can't wait for djbssh (Score:5, Funny)
Re:I can't wait for djbssh (Score:2)
you mean the one that requires you to set up 3 accounts for the client, 3 accounts for the server, and comes with its own inetd replacement?
You forgot the part about the code being totally undocumented (including no descriptive variable names whatsoever) and that it will only securely talk to djbssh clients since ssh is a useless tool of a protocol that should have never been passed as in RFC. :-)
qmail is an awesome program. Too bad it's almost impossible to understand the code. :-(
Re:I can't wait for djbssh (Score:2)
Most of the global names are quite descriptive, e.g. byte_copy(). What does it do? Copy bytes. case_lowers()? Lowercases strings.
It's really not that bad once you spend a bit of time on it.
-russ
Ha ha, ignorance is funny. (Score:3, Interesting)
Also, qmail's division of the jobs into multiple independant modules makes security analysis and improvement of the whole package much easier. Every module is completely and explicitly documented in man pages and numerous web pages, so even a less advanced programmer like me can write a wrapper for a module to add funcionality to. The risk of unexpected consequences is FAR lower because modules have their own UIDs.
If there's a good reason for it, why not do it?
Re:I can't wait for djbssh (Score:4, Funny)
Re:I can't wait for djbssh (Score:2)
-russ
Please stop writing network apps in C! (Score:5, Interesting)
If the canonical secure software from the canonical secure software people has bugs like this, I don't see how anyone can argue that it's possible to write secure code in C. C makes it easy to make this kind of bug, and the bugs are often exploitable.
Check out my previous post and ensuing discussion on this http://slashdot.org/comments.pl?sid=24271&cid=262
I'm trying to raise awareness about this because I think it's a real obstacle to us having secure software.
Re:Please stop writing network apps in C! (Score:5, Insightful)
BTW, 24,000 lines is a hell of a lot. If you want to compare like for like, have a look at vsftpd by Chris Evans. It's written entirely in c. Have a read of the source - it's quite interesting how it has been done. I would be surprised if you could find a buffer overflow.
I actually do agree with your points mostly, but I would say "Don't use c for network apps unless you have a good reason to" and also "don't use c for network apps unless you _really_ know the hazards"
In some ways SSH is a special case anyway. It has all the intensive maths stuff to do for the session key generation etc. Not a good idea to code that in (eg.) perl imo.
BTW, out of interest, what is your "favorite modern language" ??
Visual Basic (Score:5, Funny)
Re:Please stop writing network apps in C! (Score:4, Interesting)
> connections? Did you use mmap(), sendfile() and
> friends on linux to get the best performance
> possible? How did the xfer rates compare?
I can't handle 18,000 simultaneous connections, but I don't think that 99% of people actually care about that. In fact, I don't think linux even supports 18,000 open file descriptors at the same time. My ftpd is intended for the home user who cares more about getting rooted than the low-level performance of his servers.
Yes, it uses sendfile to transfer files when it doesn't need to do EOL conversion. I'm easily able to fill my 100Mbps connection without breaking a sweat either way. (In my informal benchmarks, my server got exactly the same transfer rates as wu_ftpd).
> I actually do agree with your points mostly, but
> I would say "Don't use c for network apps unless
> you have a good reason to"
Well, ok, but what would be a good reason to?
One might be that you need to write a server that can really handle 18,000 connections. (Then, I hope that the users of your server have enough cash to pay someone to maintain them, apply security patches, etc.)
> In some ways SSH is a special case anyway. It
> has all the intensive maths stuff to do for the
> session key generation etc. Not a good idea to
> code that in (eg.) perl imo.
Yes, that's true. SSHD probably uses much more CPU than a typical network app. Yet (see my other posts), it really doesn't use that much anyway.
I wouldn't suggest writing it in perl, since perl has its own kinds of easily exploitable bugs. Also, the performance of perl is not in the 20%-100% category that I mentioned.
> BTW, out of interest, what is your "favorite
> modern language" ??
Standard ML. It's got loads of cool features like higher-order functions, polymorphism, datatypes, parameterized modules, and static typing (which also really helps to catch bugs). It's natively compiled and quite fast. You can learn about it at standardml.org. Hacker types might like O'Caml better, that's at caml.inria.fr.
Re:Please stop writing network apps in C! (Score:5, Insightful)
--- channels_old.c Mon Mar 4 02:07:06 2002
+++ channels.c Mon Mar 4 02:07:16 2002
@@ -151,7 +151,7 @@
channel_lookup(int id)
{
Channel *c;
- if (id < 0 || id > channels_alloc) {
+ if (id < 0 || id >= channels_alloc) {
log("channel_lookup: %d: bad id", id);
return NULL;
}
You want to explain to me how any "modern safe language" is going to stop me from saying 'greater-than', when I really mean 'greater-than-or-equal-to'?
Re:Please stop writing network apps in C! (Score:5, Informative)
So in fact a stricter language would fix this problem.
Re:Please stop writing network apps in C! (Score:2)
Re:Please stop writing network apps in C! (Score:2)
Has anyone been able to catch this error with a tool like Purify? Language arguments aside, the reality is that the program is already written. In my experience, debugging a complex existing program with good tools is easier than writing the same program from scratch.
Re:Please stop writing network apps in C! (Score:3, Insightful)
It's *much harder* to make a mistake in a compiler that causes an exploitable hole in software compiled with it than it is to make the same errors over and over in the applications themselves. (Just compare the number of compiler/library-caused exploits to the number of application exploits!)
Yes, of course I read the patch. (Score:4, Insightful)
Yes, I read it. The bug is that they write outside the end of an array.
A modern language would not catch this bug (unless you were using a data structure like a search tree instead of an array). However, it would make it NON-EXPLOITABLE, because a safe language would cause an error (ie, exception) on an out-of-bounds write, not corrupt the heap or stack and allow for an exploit.
Re:Yes, of course I read the patch. (Score:2)
1) Getting a root exploit and not knowing about it.
2) Getting a DOS attack, and having a log file say exactly how the attack was occuring (because SSH was logging all the errors into a file).
Hmm... maybe number 2 isn't a panacea or placebo, but maybe it is better than you're making it out
Denial of Service vs. Root Exploit (Score:3, Insightful)
Actually, I don't care much about DOS "exploits", especially ones that require the attacker to expend resources to keep the attack up. It's pretty simple to flood my connection and make my computer unusable anyway.
In the case of SSHD, the situation you described wouldn't happen -- it spawns a new process for each connection, so an exception thrown in one wouldn't cause the others to be dropped. The attacker would merely be using up your resources.
A programmer in a modern language has plenty of choices, too. He can catch exceptions and restart the server. He can log them. And of course, the users are safe from being rooted until a patch is out.
There are some reasons to use C for a project (Score:2, Funny)
Re:Please stop writing network apps in C! (Score:3, Insightful)
Should be rewritten to say:
This kind of bug would NOT BE EXPLOITABLE if programmers were taught to write provably correct code.
In The Art of Computer Programming Donald Knuth discusses algorithm analysis, which I believe should be required reading before anyone is allowed to write code professionally. His techniques transcend the language in which the program is written - they are universally applicable. I doubt this exploit would exist had the programmer done a thorough review of his code. Unfortunately, algorithm analysis is becoming less and less in vogue as new HLL's make braindead coding easier - so expect to see many more of these types of errors in the future. The problem is not the language, but the programmer. The fact of the matter is that if the language is powerful enough to get real work done, it has enough power to introduce security holes into the system.* It's not a failure of the language; it's a failure of the programmer.
Seriously, folks, when are programmers going to learn that there's more to the art than just cobbling together statements until they compile? How many exploits will it take?
* Sure, you can't write unsafe code in java, but then again, you can't write anything useful with it either - without disk access, I doubt you'll be able to check passwords....
Re:Please stop writing network apps in C! (Score:4, Interesting)
In C? Please show me an example of this done.
Even in Ada, a programming language designed to possible to prove formally correct, most people don't use tools like SPARC (the formally provable Ada subset) because it takes too long and it's too much work.
In The Art of Computer Programming Donald Knuth discusses algorithm analysis,
There's a big difference between algorithm analysis and formal proving, and the first is much easier. And you'll note that Donald Knuth has had bugs found in the code in his book.
It's not a failure of the language; it's a failure of the programmer.
And most accidents are the fault of the driver, and not the car, but we still install airbags and seat belts. Changing the language will fix some errors; given that programmers will fail, it seems wiser to prevent those errors rather than berate programmers more.
Performance of network software (Score:5, Interesting)
> performance was not a reason and yet I don't
> believe you. Wake up and stop acting as the HW
> vendors lobbyist.
Actually, I am a "modern languages" lobbyist, not hardware. =) But that's because I study and believe in programming languages, not because I have some kind of financial interest.
I'd love to respond to your post but I don't know what your point is. I guess all I can do is reiterate my point on performance:
1. sshd, running on my machine for about 8 months, has accumulated a mere 2 minutes and 30 seconds of CPU time. Of course, sshd forks off a new process for each connection, but all of the ones on my machine (some of which are at least a week old) have used 0:00. If someone knows a way I can measure the actual time spent by the daemon, I'd like to hear it, but I assume for now that it is *very small*.
2. I can easily fill my 100Mbps connection without breaking 2% CPU usage. (In other words, sshd is bandwidth limited, not CPU limited.)
3. Most home / small business users do not have 100Mbps connections, and could care less about the difference between 2% or 5% CPU usage.
4. However, most home / small business users DO care about having to download patches when their C programs contain buffer overflows.
5. Modern languages are not actually much slower than C. (I estimate worst case 2x slower, typically more like 20% for SML, which is what I wrote my FTPD in.) Being easier to write in, they also give more opportunity for high-level optimizations.
Therefore, I conclude that for almost every user, security is a more important concern than speed, at least as far as network daemons go. How can you argue the opposite?
About the server (Score:2)
> Does the compiler for your favorite modern
> language support binary code optimizations that
> let your ftpd run as quickly as a popular C ftpd
Yes, mlton (for my favorite modern language, SML) produces nice native code. I would guess that my server is no more than 20% slower than a C server implemented the same way.
> Does it have a GC thread that might kick in and
> cause delays?
There is no GC thread in typical SML implementations. GC happens when an allocation fails because the heap limit is reached. GC times are typically very small (especially when amortized against essentially free allocation compared to malloc()), and in fact the compiler I'm working on at school has a real-time GC. But do you really need real-time guarantees for an FTP server? The actual transfer portion doesn't even do any allocation.
My ftpd can easily fill my 100Mbps connection at school without breaking a sweat. I don't know how many users it can handle, though.
> Or did you just use bounds-checked C++ arrays
> and strings?
C++ wouldn't guarantee safety, even if using bounds-checked arrays and strings, since you can still do things like a double free of memory. Also, I find that C++ lacks many features that make writing software much nicer in SML, but that is of course a subjective thing.
That said, my ftpd would probably need more enhancements to support a *really* popular ftp site. But I think that would not be so hard; in fact, easier than C. My server is intended for the 95% of users who run a home machine and need to transfer files from time to time, but DON'T want to get rooted because they aren't up-to-date on patches. I would be VERY surprised if there is any exploitable bug in my daemon.
(Also, I think FTP sucks too. I just did it because it's a relatively simple protocol, and at the time (summer 2001) ftp servers seemed to have the highest profile security holes.)
Re:Please stop writing network apps in C! (Score:2)
On a related side note:
I can't actually propose that people use this, because the technology is not that mature, but we are working on something called "typed assembly language" that would at least guarantee type safety of even the compiled code. (So that bugs in the compiler can't introduce certain kinds of security holes.) Check out http://www.cs.cornell.edu/talc/ for more info if you're interested.
No, you're wrong... (Score:2)
Read my post again: I said that this error would NOT BE EXPLOITABLE in a modern safe language. You can still make the error, but the array write would be checked and would result in some kind of defined behavior (ie, an exception). This is true of buffer overflows as well.
Re:Please stop writing network apps in C! (Score:2)
In languages with array bounds checking, assuming there are no compiler bugs, there will be no undetected buffer overflows.
The original poster was saying, with a good enough language, there are certain classes of bugs you don't have to worry about.
Re:Please stop writing network apps in C! (Score:2)
Both. C isn't typesafe. Hence, there are places where C will lose information about arrays. Thus, there will be places where C can't do bounds checking correctly against an array, because it doesn't know the size of the array.
Re:Please stop writing network apps in Java! (Score:3, Insightful)
You do realize that OpenSSH is maintained by the OpenBSD project, renown for their emphasis on security?
This kind of bug would NOT BE EXPLOITABLE if sshd was written by better programmers.
There are zero perfect programmers in the world. There are many lousy programmers in the world. I don't know any way to fix that. Education can only go so far against human nature; hence we should find solutions that don't depend on human infailability.
What are package people supposed to do? (Score:3, Interesting)
What am I supposed to do? Break the package dependancies on the five machines I administrate and recompile new software? Or, is Debian going to support this old, clunky distro (there is no stable replacement quite yet).
Re:What are package people supposed to do? (Score:5, Informative)
This SSH hole does not apply to the version of OpenSSH in potato (it's at 1.2.3-9.4; this hole is in 2.0 - 3.0.2); for woody and sid, the SSH maintainer has already uploaded new packages (see the BTS [debian.org]).
Re:What are package people supposed to do? (Score:5, Informative)
Everybody who runs debian (especially stable or older) should have security.debian.org in their apt-get table. Put a line like:
in
Note that as of this writing, no updated SSH package is available.. but if previous behavior is any indication of future performance, it should be there soon.
Re:What are package people supposed to do? (Score:2)
I don't think I'm the only one who has a test only system, to me, installing new stuff on a box that I try to keep usefully running is crazy.. of course, unstable has made me careful
Re:What are package people supposed to do? (Score:2)
Yup; welcome to the world of binary packages where it takes a lot more than running merge and a cvs commit to fix anything.
This is where having the base OS checked out of cvs(up) helps, cos you just get a few k of delta not an entire new binary that has to be compiled and tested heavily lest it break a dependency
> What am I supposed to do?
Assuming it's not yet on security.debian.org (someone else mentioned this solution) do:
apt-get source ssh
apt-get build-dep ssh
Patch the source as normal, then:
dpkg-buildpackage <source dir>
Note: it's been a while since I used Debian, so these may not all be the exact commands, but the basics should be the same; use apt to grab the source (you need deb-src lines in your sources.list; just repeat your normal deb lines if they're not there), then the source dependencies, patch the source then rebuild the deb.
Once you've got the new deb, put it on your shared package repository and apt-get update && apt-get upgrade all your machines, or copy them around manually and dpkg -i it.
Re:What are package people supposed to do? (Score:2)
It's much easier for me to maintain the 2 Debian boxes I admin at work (I'm too busy with other stuff, sysadmin is <5% of my job) using apt-get, but I know they're not going to be quite as secure as if I had time to watch the security lists and compile software as soon as it's patched.
Same reason users have dumb passwords. It's too hard to remember / type a random block of characters. Most users need/want the convenience. We can be as anal about passwords as we want, but eventually, someone will use their cat's name as a password.
OpenBSD upgrade. (Score:4, Informative)
http://www.openssh.com/openbsd.html
Mine's compiling now.
--saint
RPM's Compiled For i386 (Score:2, Informative)
http://www.geniusweb.com/RPMS/ [geniusweb.com]
SSH 3.1p1 RPM's compiled without gnome-askpass, everything else is default vanilla.
Isn't this a bit dodgey? (Score:5, Insightful)
Errrrrm
Isn't it a bit dogey just grabbing and installing a binary (rpm) from an untrusted source (ie you) for security software like SSH ?
I'll get my source code from a reputable mirror and compile it myself thanks.
Re:Isn't this a bit dodgey? (Score:2)
If you're concerned, just don't download em.
Re:Isn't this a bit dodgey? (Score:2)
Re:Being helpful and encouraging security risks (Score:2)
They're very trusted. I downloaded them from the vendor's site and built them myself. Anyone who trusts me (note the link to my homepage if you care to do research on myself or my company) can go download them. Anyone who has doubts can wait a week for their distro to put out updated RPMS.
I think anyone like yourself can be an armchair "security expert." Come up with something USEFUL [slashdot.org] yourself instead of whining at those of us who are trying to make life easier for others.
Re:RPM's Compiled For i386 (Score:2)
rpm -ivh openssh-3.1p1-1.src.rpm
then edit
and set the options as you like, in my case I changed the 0 to a 1 where the gnome-askpass bit is.
Then use rpm to build it, cd to the SPECS directory on your system (may also be
rpm -bb openssh.spec
Then watch the messages at the end which tell you where the finished RPM's are. Usually
For those who want the gnome-askpass, just do
rpm --rebuild openssh-3.1p1-1.src.rpm
Re:RPM's Compiled For i386 (Score:2)
Did a md5sum that anyone's free to check against the original also for the paranoid among you.
Re:RPM's Compiled For i386 (Score:2)
After executing the command "tar xvfz openssh-3.1p1.tar.gz", you must then type "cd openssh-3.1p1" (without quotations).
FreeBSD affected; patches available (Score:4, Informative)
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.FreeBSD.org/pub/Fr
Execute the following commands as root:
# cd
# patch <
# cd
# make depend && make all
# cd
# make depend && make all install
# cd
# make depend && make all install
If you've got the ssh port installed, check out the advisory for details on what to do:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+
Does this affect non-suid root clients? (Score:2)
*** Help on upgrading a remote server? (Score:2)
My server runs 2.2.0p1. I've got the 3.1p1 source and I'm ready to go. I'm always afraid that a glitch in the build procedure - or even a success - could replace the existing 2.2.0p1 sshd binary while it's talking to me and cut me off, and if something goes wrong in the process, leave the server unreachable, which means a long drive to the colo facility to sit down with a keyboard and monitor.
Can anybody help? I've never been able to find a clear answer for this question.
TIA.
Re:*** Help on upgrading a remote server? (Score:5, Informative)
1) Use SSH to log into your server.
2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.
3) Run 'ps -ef | grep sshd' or 'ps auxw | grep sshd' (depending on your UNIX flavor)
4) find the sshd instance with a parent process ID of '1' -- this will be the actual daemon spawend by init. The other process will be the one spawned by sshd itself to handle your connection.
5) kill
6) the parent sshd process will terminate, but yours will stay running
7) start up the new sshd
8) from another workstation or window telnet to port 22 on your server and verify that the version number reflects the new version.
9) from another workstatino or window, ssh into your server to make sure you still have access.
10) close your original ssh session
I've used this exact process to upgrade many machines at remote locations. As long as you verify that the new sshd is running before you close your existing connection, you should have no problems.
Re:*** Help on upgrading a remote server? (Score:2)
./configure --with-md5-passwords --etc etc etc, configure options here
make
cat
kill <pid from above command>
This kills off the master ssh process, you will still stay connected, just don't kill off any other ssh processes.
Now:
make install
/usr/local/sbin/sshd (or wherever you installed it to start it up)
Don't dissconnect yet! Try sshing in again and see if the machine is accepting connections, if not, you might have to try giving it different
If it's your first time try it remotely, you might not want to do this on a server that's a 3 hour drive away.
Re:*** Help on upgrading a remote server? (Score:2)
Am I hosed if I start sshd with inetd? In the display below, which is the parent process? Or do I have to kill them all?
(stripped of nearly all useful information to get around the useless, brainless lameness filter: hopefully good enough. The "|" and "`" are supposed to line up under the "+" so that all of the sshds are in the same column, but we can't use <pre> tags so we can't do that.)
inetd(408)-+-sshd(5980)
|-sshd(9627)
`-sshd(23148)
FYI: my box may have been exploited by this (Score:4, Informative)
I haven't been able to verify openssh-3.0.2p1 was truly the cause, but it seems likely. This may have been the remote root exploit which the advisory "does not rule out".
Couple things (Score:3, Insightful)
Also of note is that this particular advisory is known only to affect local users. I don't think this particular bug is the cause. It may have just been a friend shoulder-surfing.
If you want to do analysis on a cracked machine, you should place the hard disk into a different machine and examine the contents.
Should be "between vers. 2.0 & 3.02 **INCLUSIV (Score:2)
And I thought it was just about time to go home too. Now I'm warming up my compiler... :-(
No need to give up (Score:2, Insightful)
I'm going back to telnet (Score:2, Troll)
Information like this makes me
A. Consider purchasing SSH from a commercial source because the AMOUNT of problems with it is less
B. Going back to telnet!
Not many people out there with sniffers between my box and my connection. Lots of l33t haX0rS with worms probing port 22.
Re:I'm going back to telnet (Score:2, Informative)
Or use Kerberos (Score:2, Interesting)
Kerberos has been around since '88, opensource (MIT license). It is not developed at the breakneck pace of the more modern SSH and to my knowlege has had fewer exploit bugs in 14 years than the assembled flavors of (commercial *&* open) SSH have exhibited in the last 2 years.
Krb5 is not slick as SSH, you can't use it for a poor-man's VPN; it uses a more expensive cypher (3DES) for both auth and fully encyphered network connections. Rsh, rlogin rcp all available with strong encryption. It's not as easy to setup, nor well suited to very small networks but for my money where applicable it's a far more solid solution.
And yeah OpenSSH's seriously checkered security record has done very little to make me think of applying OpenBSD .. thoughts?
Exploiting scenario (Score:5, Insightful)
MacOS X (Score:2, Interesting)
ignorance and self deceit (Score:2, Insightful)
MS exploits often announced on here (yes i like to know about them) and in this case open's dev team mistakes are also what I consider news, however I cannot remember the last time anybody pointed out the dangers of RedHat. While every new version of a linux distro is waved about with great expectations and cheer, other OS's are actually being analyzed for the bad as well as the good. I won't say that nobody posts unbiased articles, and I will even admit that if every stupid needless redhat exploit were listed on slashdot, RedHat would look as bad as Windows. Almost every OS and piece of network software has exploits, and very VERY few developers ever get it right the first time. I just wonder why it's so easy to see all of the mistakes for software that we may not (choose/want to) use while pretending all those dozens of RedHat exploits we had to patch never really were a problem.
Those who even bothered to reply to this newsworthy post with openbsd-bashing, are the ignorant monkeys of the open source community and have obviously never really compared UNIX's in the server world.
Those who bothered to reply to this stating that C is the wrong language to code in bring up minor points and expect the code that drives the internet to change. C is small cpu load and if it turns out buggy, it is the developers fault. But to expect software developers who write based upon existing libraries and code concepts they have developed over decades of work to stop and try writing their apps in an experimental (and YES, pretty damn potentially exploitable itself being so new) language is just silly. PHP is "a modern language" and was just recently found exploitable despite years of development in the PHP arena. IMAGINE the chaos if the development language that your OS/net apps were written in was found to be buggy? To date I have not had to download a new version of gcc and recompile my OS/kern/3rd party apps due to a "C vulnerability". Using experimental non-prooven ( 10 years?) languages for OS/kern/apps is a pretty stupid risk.
OpenSSH? (Score:2, Funny)
Re:There goes OpenBSDs slogan... (Score:3, Informative)
It's a LOCAL exploit. You have to be logged in to exploit it.
Re:There goes OpenBSDs slogan... (Score:4, Funny)
They aren't ruling out the possibility of a remote exploit.
Re:There goes OpenBSDs slogan... (Score:2)
Re:There goes OpenBSDs slogan... (Score:2, Interesting)
Re:There goes OpenBSDs slogan... (Score:2, Insightful)
Is ssh server enabled in the default install? I would think (hope) not - You don't want to run services that you do not need, and does a workstation need sshd?
Re:There goes OpenBSDs slogan... (Score:2)
How else are you going to do remote maintenance on it? What are you going to use for remote access to your stuff? You sure as hell don't want to use telnet.
(If you think you'll never need remote access, though, you can leave it out. As for me, I like the ability to tap into my home machines anywhere I can run SSH and VNC. I even have Win32 SSH and VNC clients on my webserver that I can download on a random Win32 box (even many public systems) to access my systems (both Linux and Win32) at home.)
Re:There goes OpenBSDs slogan... (Score:2, Informative)
Re:Full disclosure = annoying. (Score:4, Insightful)
Full disclosure has its downsides,but the upsides pretty much cancel them out.
Re:Full disclosure = annoying. (Score:5, Funny)
Re:Full disclosure = annoying. (Score:2)
Re:Full disclosure = annoying. (Score:2)
Re:Full disclosure = annoying. (Score:2)
Re:Full disclosure = annoying. (Score:2, Informative)
(I'm in the webhosting business myself...)
Vince.
Re:Full disclosure = annoying. (Score:2)
Re:Full disclosure = annoying. (Score:3, Informative)
Now this is public knowledge, an exploit will be available within hours.
You do not know what you are talking about. Full disclosure has greatly improved security awareness and turn around time for fixes. If you want to turn your back on full disclosure, you are heading back into the middle-ages of computer security.
This should have been fixed before it was announced, and a period of time waited for people to upgrade.
The information was leaked by someone who jumped the gun. That is the reason why the relase and advisory happened today instead of Monday. Nothing to be done about it. Instead of bitching, fix a bug in your operating system and send a patch to the developers. Much more useful behaviour for all of us.
Of course, you should be running with ln -s AJ /etc/malloc.conf
anyway. It will fill freed memory with junk,
and quite often finds conditions where memory
is referenced after it has been freed.
In that case, there is no problem anyway. If your operating system of choice has not support for malloc debugging, looby
your developers, it is a very useful feature.
Re:Full disclosure = annoying. (Score:2)
If it's fixed, then that in itself announces what the fix is. Just do a diff between vN and vN+1 and see what changed. "Hey, look, it's a buffer overrun they fixed."
Security through obscurity is no security.
Re:Full disclosure = annoying. (Score:2)
Alternatives to wearing bullet-proof vests:
1. Get your own fucking gun and shoot the SOB.
2. Armored vehicle.
3. Stay home.
Your analogy doesn't make sense. Finding a root-exploitable weakness in v1 isn't the same as developing an armor-piercing bullet.
Re:I don't think so. (Score:3, Interesting)
Don't bet on it. A while back, for kicks, I checked to see who was bombarding what ports on my box with attempted hacks. A large portion of them came from 0wn3d Linux systems. I'm just glad that (a) I kept things patched (b) didn't have a default RedHat install and (c) had a MIPS processor that obfuscated any hole I didn't yet know about.
If you don't patch a potentially remote-root hole, it's not a case of "if". It's a case of "when" you'll be 0wn3d.
Re:linux patch available (Score:4, Informative)
Re:linux patch available (Score:3, Informative)
Re:Workaround? (Score:2)
SSH into your box remotly, then add a filter to your box's packet filtering software to block out OpenSSH's port.
Perhaps thers a more elegent solution:
I also croned a small script that will activate tomorrow for an hour that opens the SSH port back up, and will allow me to do a remote patch once I get everyhting in order and I know what's going on.
How is this offtopic? (Score:2)
Re:3.1 will NOT build on linux (Score:3, Informative)
The portable version built cleanly and ran on both my Intel-based Linux system and my ancient MIPS-based Linux system. The *BSD version will not compile on Linux. Make sure you have the right version!