Forgot your password?
typodupeerror
The Internet

SSH Secure Shell 3.0.0 Remote Hole 77

Posted by jamie
from the come-on-in dept.
SSH Communications Security Corp (ssh.com/ssh.fi) announced on bugtraq last night that their commercial product SSH Secure Shell 3.0.0 is a gaping remote hole on various unixes. Technically it's not a root hole, but remote access to users like "adm," "bin," "daemon," and "sys" is not good. Strangely, I don't see an announcement on their homepage. If you're running the $99 workstation version or the $475 server version, go upgrade to 3.0.1 now because it's an amazingly trivial exploit (especially on Solaris, but also on other unixes, excluding NetBSD and OpenBSD which are not affected at all). If you're using OpenSSH, or some other program you didn't pay for, no worries.
This discussion has been archived. No new comments can be posted.

SSH Secure Shell 3.0.0 Remote Hole

Comments Filter:
  • by Anonymous Coward on Saturday July 21, 2001 @11:19AM (#70297)
    IIRC the OpenBSD crew got a hold of some old crufty "free" (as in license) ssh/sshd program, cleaned it up, added a ton of feartures, cleaned it up more, audited the source, released it and currently is maintaining it. IMHO the OpenBSD/OpenSSH team is doing a hell of a good job with this.

    The orignal source was IIRC written from the ground up, but was in pretty bad shaped before the OpenBSD/SSH crew got a hold of it.

    At last that is how my Papa tells the story.

    Every "fearture" check I have compared between OpenSSH and SSH, they both keep up with each others in the buzzword complaint list. As far as price, OpenSSH wins hands (even can change/redistrub full source!). OpenSSH wins hands down also on the number of exploits found (ie. OpenSSH has less).

    Personally I think OpenSSH(d) is easier to admin then SSH(d), but maybe that is just because I am more famlair with it?

    Oh the OpenBSD/SSH crew is A LOT nicer than those jerks that support SSH. About 1-2 years ago I had to admin a bunch of old Solaris 2.3 boxen (yuck!). Both SSH and OpenSSH would not work correctly on 2.3 I emailed them both, the OpenSSH team sent me a diff and it worked prefectly. SSH team said that solaris 2.3 was unsupported and that they could not refund my $ (techinally my bosses cash). Theo may have a attitude problem, but atleast his has never riped me off! (in fact I think I have probably riped him off, downloading OpenBSD without giving donations!)

  • by Anonymous Coward on Saturday July 21, 2001 @01:14PM (#70298)
    Don't use password authentication with SSH / OpenSSH

    *sigh*

    I'm too lazy to look up the exact quote or the correct attribution, but "For every complicated question, there is an answer which is simple, elegant, and wrong."

    That's not necessarily the answer, for a variety of reasons:
    (1) The use of RSA/DSA keys without a passphrase is reckless. Situations far less severe than having your box completely rooted (including numerous forms of pilot error) can allow people to read your files. In particular (and at the risk of sounding inflamatory), consider that such keys can be generated on and used from a windows box. Do you trust win98, with (for instance) no concept of file ownership, to keep some luser's private key safe?
    (2) The use of RSA/DSA keys (even with a good passphrase) makes your machine a single point of failure, from a security standpoint, for all the machines to which you have access. Basically, the only thing that publickey authentication proves is knowledge of the contents of id_dsa. Ignoring the fact that several implicit assumptions lie between that and the "fact" that it's actually you trying to log in is of an order of stupidity similar to the mistake the ssh.com folks made.
    (3) More broadly, anything which automates authentication subverts that authentication.
    (4) The 'password' authentication in sshd_config need not use a static password. It is fairly straight-forward to write a PAM backend for (for instance) SecurID, while using the basic "ask user for magical identification string" semantics of password authentication provide the front end.

    All that said, if they are used correctly, DSA keys can be significantly more secure than static passwords. However, there is no practical way to confirm on the server whether or not the keys are being used incorrectly. And, used incorrectly (e.g. w/ a null passphrase as you seem to suggest), they are much worse than static passwords with reasonable restrictions (complexity, length, expiration) placed upon them.

    With that in mind, all of my really critical machines use SecurID authentication. Best-case is somewhere between password and public key authentication, but, and, when dealing with users in the real world, this is key, its worst-case security is _far_ better than the worst-case of either password or RSA/DSA keys.

  • You're probably right. There is certainly no (that I know of) reason to fork out any dough to the SSH guys currently.

    But who is going to pay for serious support for OpenSSH? For the most part you just rpm -i it and it works. Sure, there are a few configuration details. Maybe support in getting client programs to tunnel over SSH, but that wouldn't likely rake in a killing for anyone.

    ---
  • by jbuhler (489) on Saturday July 21, 2001 @01:20PM (#70300) Homepage
    > But, this product appears to only make its
    > source available if you buy the $475
    > server version. The cheaper workstation
    > version does not come with source.

    Bollocks. SSH 3.0.1 still comes with source in a non-commercial (though not libre) version. Excerpted from the license:

    "To qualify for a Non-Commercial Version License, You must: (1) use the Software solely on a system under the Linux, FreeBSD, NetBSD, or OpenBSD operating system(whether for commercial or non-commercial use), or (2) use the Software for non-commercial purposes as defined herein and be a Non-Commercial Entity as defined herein, or (3) be an University User as defined herein, or (4) be an Excluded Contractor as defined herein."

    You can download the SSH 3.0.1 sources from the usual place: ftp.ssh.com/pub/ssh.

    I prefer free software as a rule, but OpenSSH's connection tunneling didn't work properly last time I tried it (around 2.4), and it still appears to lack MIT Kerberos 5 support as of 2.9p2. That said, it appears that ssh.com's v3.0 client won't authenticate via Kerb5 with a v2.x server.
  • Wrong. Of course Mandrake has a telnet client. It isn't installed in the default installation but just bring up the software manager and install the telnet package.
  • >Oh the OpenBSD/SSH crew is A LOT nice


    Of all the good things I've heard about OpenBSD, I've never seen *this* one before :)

  • No, the libs were only half the frustrating part.

    I was able to build OpenSSL and such that OpenSSH would compile.

    I had it compiled and installed. Appeared to be configured correctly, but ssh clients would not authenticate with it.

    I read in another post that OpenSSH has problems with Kerberos. That might be it, because I use Krb5 on my Solaris box to authenticate users.
  • I wasn't able to reproduce it either.

    At least it's not as simple as just trying to connect and type in a short password.
  • by sheldon (2322) on Saturday July 21, 2001 @05:34PM (#70305)
    I think it's kind of interesting how everybody is reacting to this with the "OpenSSH REWLS! SSH SUCKS!" attitude.

    Reinforcing their own notions that open source software is somehow superior. I'm not certain how defensible this position is considering OpenSSH has also had quite a number of vulnerabilities of it's own.

    For my purposes. I use SSH at home on my Sparc running Solaris 8. I do so because I tried OpenSSH and for whatever reason found it very difficult to configure, install and get working.

    In fact I couldn't get it working. After spending a frustrating hour on it I decided to try the non-commercial version of SSH.

    Compile, install... up in running with no problems.

    The difference between these two products from an ease of installation was like night and day. OpenSSH suffers from the old "good enough" attitude exhibited by most open source software. SSH on the other hand you can tell they put some time into polishing which is typical of commercial software.

    Is the code better? I don't know. Perhaps. But the chief difference is simply one of polish, something OpenSSH clearly does not have.

  • The right solution, of course, is to make
    ssh more *ahem* configurable, like sendmail is,
    so that people write incredibly huge books
    detailing how it can be configured, and then sell
    an 'enchanced' version that has a nice GUI to the
    configfile :)
  • by VAXGeek (3443) on Saturday July 21, 2001 @11:00AM (#70307) Homepage
    Yet another SSH hole. This is why all of the security minded admins stick to telnet.
    ------------
    a funny comment: 1 karma
    an insightful comment: 1 karma
    a good old-fashioned flame: priceless
  • IIRC the OpenBSD crew got a hold of some old crufty "free" (as in license) ssh/sshd program, cleaned it up, added a ton of feartures, cleaned it up more, audited the source, released it and currently is maintaining it. IMHO the OpenBSD/OpenSSH team is doing a hell of a good job with this.
    That "old crufty 'free'" SSH-1 implementation you mention is none other than Tatu Ylonen's (aka SSH.com's) SSH-1 implementation. And it was only any kind of crufty because the last version that had a forkable license was about 1.2.12 (I could be off by a minor version or two). OpenSSH set about reimplementing (on their own) the same features that were in the present release of SSH.com's ssh.

    OpenSSH is not perfect. It has had interoperability problems with SSH.com's ssh (arguably because SSH.com had strayed from the SECSH reference design, but strict standards adherence does not always useabilty make). It also still supports the SSH-1 protocol, which is inherently flawed. While this is nice for sites transitioning to SSH-2 (or for people concientiously using SSH-2 but having to deal with admins elsewhere who are less on the ball), it's allowed the SSH-1 protocol to linger in the community longer than Tatu would have liked. And he's been very noisy about that fact. Even though there have been pretty much no reports of anyone actually exploiting SSH-1 just yet.

    Point is, OpenSSH comes straight out of SSH.com's source, though its been much-updated, as opposed to other SSH (-1 and -2) implementations like FreSSH [fressh.org] and ossh [appwatch.com], which were reimplemented from the ground up.

    --
  • by jamiemccarthy (4847) on Saturday July 21, 2001 @11:05AM (#70309) Homepage Journal
    "But seriously, folks, this just goes to show mistakes can happen to anybody. Open source may be your best protection, but even it's not perfect..."

    Unquestionably true. But, this product appears to only make its source available if you buy the $475 server version [ssh.com]. The cheaper workstation version does not come with source. I'm sure too that the licensing terms prohibit free redistribution of the server source, so (unless I'm mistaken) this is not an open source product. It looks like it's closer to what Microsoft calls "Shared Source."

    Jamie McCarthy

  • by jamiemccarthy (4847) on Saturday July 21, 2001 @11:50AM (#70310) Homepage Journal
    "So let me get this straight. . . this bug only occurs if someone uses a TWO CHARACTER password (or shorter)?!? I almost think anyone that dumb deserves to be hacked."

    (sigh) No.

    I didn't go into technical detail in the story because space was limited. But it's interesting how the exploit works, and I figured maybe some enlightened Slashdot reader would write up an insightful comment about it. Never mind, here's what I would have put in the story...

    The vulnerability is so serious because most unix operating systems use a special code in their /etc/shadow file to signify "no password should ever match on this account." On my Debian installation, it's an asterisk:

    daemon:*:...
    bin:*:...
    sys:*:...

    The problem is that this product actually reads that as if the "*" were the crypt()ed password -- that's its first mistake. Then when it compares the crypt()ed attempt against that field in /etc/shadow, it only compares up to the length of the /etc/shadow field -- that's its second mistake.

    Both are colossal errors.

    The result is that any password will suffice to log into such accounts, because any password, when crypt()ed with the one- or two-character salt ("*"), will have its first one or two characters match -- and that's as far as the algorithm checks.

    The result is that a code intended to mean "no password can ever succeed" ends up meaning "all passwords will always succeed." Truly an amazing oversight.

    Jamie McCarthy

  • I believe the expression is "Root hog, or die". As in when times are hard a hog has to dig up roots to eat to avoid starvation. Also written with a comma after the word "root".

    Perhaps you already knew this, and were punning, but Slashdot draws a world-wide audience and as Tony Joe White said in Polk Salad Annie, "Some of y'all ain't never been down South might not know what I'm talkin' about..."

  • It's to give the w4r3z k1ddi3s a better chance.

    So you don't need to get it at your local warez dealer.

    You get cuffed anyway if you (even not) try to distribute it ...

    if you don't believe this I'll find another reason



    Freaker / TuC
  • So we have to purchase security vulnerabilities now, eh?

    Not really. Microsoft gives these out for free.

    They're called "Service Packs"

    -- Give him Head? Be a Beacon?

  • 1. You can download the source of any version of ssh. 2. You only have to pay if you use ssh in a commercial way
    Start documenting before bashing any product that doesn't have 'Open' before its name. It's a good product, you have access to the source and it's free for non-commercial use (it works great in my home server). Most of the people saying that ssh sucks, doesn't even know how to setup their ssh/openssh server to use public key authentication, and not the password authentication used by default. Real security is in public key.
  • Open source commodity software is devoid of bugs.

    Riiiiight.
  • Sure, they were the original makers of ssh, but ever since they moved it away from GPL it has just gone downhill. And now they are where most commodity commercial software is: bugs bugs bugs.

    What is so bad about openssh that it is a wise decision to move to a commercial version with security leaks? It is fairly new and only the $475 server version includes source code, so it hasn't seen much review. Surely everybody realizes that when it comes to encryption, security through obscurity works against you. This is just the kind of place where full openness increases the quality of the product.

  • Another one...

    After the story about the shower curtains last week, I did try mine with cold water, and guess what: It hangs perfectly straight with cold water, and bulges with hot water. The article claimed to the contrary...

    I guess it was all just a trick to let me take a cold shower ;-))
  • You found one in openssh? Why didn't you fix it?

    Use the source luke.
  • " and having the latest version of a security software is important"

    I disagree unless there are security issues for the older versions. Just this incident with SSH version 3.0.0 shows again that you shouldn't go with a x.0 version, neither should have upgraded to it just because it was new.

  • All right, if you want others to do the coding for you, then you shouldn't rely upon the open source community. Then, choosing a commercial tool or choosing a company that provides support for an open source tool are your only options.

    Might I ask what it is that you use ssh for that makes ssh such an important program for you that you need support, features, and easy compilaton?

    SSH looks like a sufficiently functional secure telnet with port forwarding and secure file transfer to me. I've never found any additional features that I was missing in ssh, no need to touch it. Touching it will only add risk of new security problems.

    I just do an easy apt-get for the linuxes, and compile once for each of the (very limited) Unix platforms that I need ssh on, then just distribute binaries. Re-installation is only necessary if there are security fixes.

  • by warpeightbot (19472) on Saturday July 21, 2001 @12:24PM (#70321) Homepage
    Well if I shut down telnetd how am I going to telnet to my router-box-in-the-closet to upgrade?!
    1) Get libsafe. The telnetd exploit is a buffer overflow (like so many bugs these days); if someone tries to hack your system this way, libsafe will trap it, kill telnetd (which is fine since telnetd should be running from (x)inetd and can respawn), and mail root.

    2) Surely the router is firewalling port 23 on the outbound side, or at least tcpwrappered (or blocked in xinetd.conf), right? In the extreme case you can hardwire it to come from only your personal machine...

    3) Hardwire it. Use a null modem cable, serial port to serial port; you could even set the headless box to boot to the serial port (yeah, this takes a kernel recompile, but you would've wanted to do that anyway). Use getty on the router, and minicom on your side (don't forget to configure it to not send "ATZ" for the "modem" init string....).

    Frankly, I just use OpenSSH and be done with it... no reason to send bucks to Finland when the Canadians will do it better for free... and if it weren't for the fact that my housemate has Windows machines that occasionally need to PPTP to her work, I'd be using OpenBSD as the firewall.... when they get around to making pf tunnel alternate protocols, I'll likely be switching.

    --
    Linux for the stable desktop
    Mac for publishing and pretty pictures
    OpenBSD for secure servers
    Windows for games
    Use the right tool for the job.

  • > What is so bad about openssh that it is a wise decision to move to a commercial version with security leaks?

    OSS deprives users of the opportunity to pay for their software.

    --
  • This is a bad blow for SSH the company. Didn't someone there quit a while ago since he disagreed about the decision to not provide source code to customers?
  • OSS deprives users of the opportunity to pay for their software.

    Send a cheque to the author(s).

    Problem solved.
  • 1) Get libsafe. The telnetd exploit is a buffer overflow (like so many bugs these days); if someone tries to hack your system this way, libsafe will trap it, kill telnetd (which is fine since telnetd should be running from (x)inetd and can respawn), and mail root.


    Bullshit. The only thing libsafe has ever done on my system is cause my fsck's and fdisk's not to run. It's a great idea but obviously implementation is lacking egregiously.

  • It's official -- humor is dead.

    Seriously, though, not being too well acquanited with Unix systems, I didn't know this. Still, though, it was a joke -- I didn't mean to get you so worked up! =(

  • SSH Secure Shell 3.0 isn't made by Microsoft, and yet it has a super-trivial remote security hole. Guys, it's not April 1, knock it off.

    But seriously, folks, this just goes to show mistakes can happen to anybody. Open source may be your best protection, but even it's not perfect (remember that recent OpenBSD local root hole?).
  • This has happened before and programs that didn't come from the OS vendor may not know that NP means no password.

    Back in the days when Sun and AT&T got into bed on SysVR4, someone decided to change the '*' that was commonly used to a 'NP' since '*' had a wildcard meaning. The problem is that NP is a vaild (and sometimes even used) seed so now programs much check for the two letter 'NP' and treat is special, while the old programs used to take the password string, pass that as one arg to crypt and the plain text as a second and if the result mached you let them in. This is about the same time that people started looking at buffer overflows and the result was people would go clean up code and make bad assumptions about how long the bits that came back from crypt were and tried to fix it but got it wrong.

    I guess it was just time for history to repeat its self again.
  • The man-in-the-middle attack only works in some very carefuly crafted situations. The script kiddie must be in control of something on the transmission line so they have to control a router, or another host on a non-switched lan. The tools will help in some switching situations but this messes up the switches so bad (as well as solaris boxes) that by the time the guy has the password, you can't log in since they can no longer forward the connections properly.
    If the script kiddie has control of the router, its all over.

    I think ssh 3.0 was to version 1.5 out of existance. Many places can be convinced to go with a prior version but most won't go with a very old version.
  • "For every complex problem, there is a solution that is simple, neat, and wrong."
    - H. L. Mencken
  • by chrysalis (50680) on Saturday July 21, 2001 @12:15PM (#70331) Homepage
    Don't use password authentication with SSH / OpenSSH .
    The beauty of *SSH is that you can use crypto keys for authentication. With ssh-keygen -tdsa , you create a pair of keys. id_dsa is the private one (keep it on your computer), and id_dsa.pub is the public one. You can copy the public one in ~/.ssh/authorized_keys2 on every server you are willing to access. The public key can be given to everyone, you can even put it in your signature so that people can grant you access to their machines if they want to.
    When the public/private keys matches, you can log in. No need to enter any password. Simple. Fast. Easy. Really handy (especially with scp). And it's secure. Don't tell me "yeah but if your client computer gets rooted, the bad guy can grab your private key". First, LIDS [lids.org] can hide the private key. Then, you can add a passphrase if you want. Next, if your computer gets rooted, the bad guy can always install a keyboard sniffer.
    Try DSA authentication. It rules. And it solves the problem of people chosing trivial passwords. Once you only use DSA authentication, you can disable password authentication in your sshd_config file.

    -- Pure FTP server [pureftpd.org] - Upgrade your FTP server to something simple and secure.
  • If you have to pay to get the source code, then what is the ssh-3.0.1.tar.gz file on their FTP server:

    ftp://ftp.ssh.com/pub/ssh/

    ???
  • SSH began with a bsd-ish license, NOT a gpl license. It was then forked when they decided to get draconian with their licensing, and prices.

    Thus was born OpenSSH, a truly bsd-licensed piece of code that rocks.

  • I have the supposedly vulnerable versions of ssh running on two systems, a Solaris 8 box and an AlphaLinux system running RedHat 6.4. On both, I am unable to login to usernames with encrypted passwords of 2 or 1 characters. I tried this with /etc/shadow passwords and non-/etc/shadow.

    In short, the trivial vulnerability doesn't seem to exist on these systems. Of course, I'll upgrade (or sidegrade?) to OpenSSH, which I already have on most of my other systems.

    Has anyone actually had the trivial case of logging into lp or adm or some other username with an arbitrary password? I'm not doubting the vulnerability exists, but it seems that on systems withOUT any of the recommended workarounds, I'm still not vulnerable.

    • Greg
  • buzzword complaint list

    Pure guinness! (er, genius)

  • Well, not exactly. Maybe if it had commercial SSH. I'm running SuSE 7.1 Pro, and it came with OpenSSH 2.9, which would be in the safe catagory.
  • So let me get this straight. . . this bug only occurs if someone uses a TWO CHARACTER password (or shorter)?!?

    You obviously don't know much about how UNIX works. Excerpting from my /etc/shadow:

    daemon:*:11447:0:99999:7:::
    adm:*:11447:0:99999:7:::
    lp:*:11447:0:99999:7:::
    sync:*:11447:0:99999:7:::


    Yep, that's right. Common UNIX system accounts (that run daemons and system services) don't even have a password set. This, of cousre, means that they have a password that's shorted than two characters, making them vulnerable to the SSH hole. Once access to these accounts has been gained, using a local root hole is trivial. Seriously, I don't see why anyone should still be running the commercial SSH client when a great and audited alternative like OpenBSD exists and is available freely.
  • by FattMattP (86246) on Saturday July 21, 2001 @12:04PM (#70338) Homepage
    If you're using OpenSSH, or some other program you didn't pay for, no worries.
    So we have to purchase security vulnerabilities now, eh? And I remember the days when we got 'em for free.
  • One way to prevent this problem is to use AllowUsers, AllowGroups, DenyUsers, and DenyGroups to selectively allow access to real users or to deny access to users such as lp, adm, and bin. In my opinion this should be done anyway on all boxes, not just those with this version of SSH, to prevent future problems.
  • First, NetBSD and OpenBSD are not affected. Secondly, this is a commercial software package, so I don't think its fair to say "BSD has a remote exploit" anyway. Its not only not part of the default install, but you have to go out and buy it!
  • by SBChoDogg (93091) on Saturday July 21, 2001 @11:01AM (#70341)
    The problem is with accounts that have !! in the password field in /etc/passwd or /etc/shadow. This includes lp, adm, etc. Anyone can access those accounts (or any account with a two character entry in the password field) with any password. However, this is not a problem if you have disabled password authentication. Most people using SSH who really need security should be using some other type of authentication, including "public key, SecurID, Kerberos, certificates, Smart Cards, or hostbased." Those people running (non-Open)SSH daemons on Internet-accessible boxes with password authentication should definately upgrade though.
  • It was forked off SSH 1.2.12 and apparently was under GPL then.
  • If you're using OpenSSH, or some other program you didn't pay for, no worries.

    So copies obtained from #warez aren't vulnerable ?

    Nice to know that n4u9h7y w4r3z is useful for summat :)

  • PLATFORMS NOT IMPACTED: Tru64 4.0.G, NetBSD, and OpenBSD are not vulnerable
  • My God. It boggles the mind to think that a "professional" software company like SSH Communications would make such an insanely stupid oversight....
  • What's wrong with 1.x?

    Because it's no more secure than telnet if your local script kiddies have the right tools.

    Don't believe me? Take a look at Ettercap> [sourceforge.net]. Does a great Man-in-the-middle attack and is so trivial to use the most brain-dead script kiddy could master it in 10 minutes.


  • OpenBSD uses OpenSSH not SSH. OpenSSH does not have any current holes. SSH does. SSH is commerical software. OpenSSH is free open source software. SSH does include source, but you have to fork out money.

    FreeBSD IIRC also uses OpenSSH, not SSH.

    Not sure what NetBSD uses, but betting it uses OpenSSH over SSH.

    This is *NOT* a remote hole in OpenBSD, SSH is *NOT* even installed in the default installation. OpenSSH is. OpenSSH is secure, read above. SSH is not.


  • If your router is not running a vulnerable telnetd then that's not the problem.

    If your router is running a vulnerable telnetd then maybe you could run stunnel and telnet via SSL to it. www.stunnel.org

    Set the stunnel to -v3 so that only clients with recognised certificates can actually connect.

    So even if the telnetd is vulnerable, attackers don't get a chance to talk to it unless they have the right cert, or stunnel has a problem.

    Stunnel has had some problems, but since the code is a lot smaller than SSH and the feature set is a lot more limited, I bet it's still more secure than SSH. I took that bet 2 years ago, and so far SSH has had tons more problems compared to Stunnel.

  • ...an impression? You bet. I can probably scope out and/or access more of your hosts/networks than you thought.

    Ok - here's a little nugget of potentially useful info you.

    If you have a valid shell, but one that is for all intents and purposes useless (like /usr/bin/yes), attackers can still wield that against a host/network.

    What can be done is to setup port-forwarding. Sure the victim user cannot login, but we can still forward ports on their behalf. Such access could be used to circumvent many TCP connections that use host-based authentication.

    Used to target 'sync' accounts like that waaaaaay back in the day.

    Just an FYI. Give em a shell that doesn't exist. Or, get rid of them altogether, and for God's sake, CHOWN ROOT ANY BIN OWNED FILES!!!!

    sedawkgrep
  • There's plenty of other stack overflow protections in which libsafe is only one of. First, libsafe is a replacement shared library for a limited subset of functions, albeit some very common ones that are suceptible to stack based offerflows. Other alternatives include StackGuard, a special C compiler and Solar Designer's OpenWall patch which is a kernel patch. For the even more paranoid, the LIDS system is a very configuration intensive system of POSIX style capabilities (this is in kernel 2.4 too but slightly different). This system will lock down your computer very very well though if your interested.
  • This is a bad blow for SSH the company. Didn't someone there quit a while ago since he disagreed about the decision to not provide source code to customers?

    That was Phil Zimmermann [mit.edu], author of PGP [pgp.com], who quit working for Network Associates [nai.com].

  • Well, also for every complicated question there are many answers which are complicated, inelegant and still wrong.

    I'd never heard of SecureID, so I decided to look it up. My analysis: a time-based one-time password generator in lots of different packages. I'd use the PIN to protect the one-time password, but this is probably a useability decision since it's hard to make a keychain thingy that you can enter a PIN into.

    Also, this "Two-Factor" hype is stupid. SSH with RSA/DSA without an agent is exactly like this, but better as you say yourself. One *must* have a "two-factor" method in the network world because anything that can be remembered by a human can be guessed by a computer in a reasonable amount of time. (Of course I assume that only someone with very low security concerns would use an RSA/DSA key with no passphrase.)

    My main dissagreement with you is this: If someone were to write an "agent" for SecureID it would be just as much a "single point of failure" as SSH with RSA/DSA. And a pickpocket shoulder-surfer could rip your network wide open. There is *no way* for a server to confirm if the tools on the other end of the channel being authenticated are being used correctly. This is impossible, and can only be solved by educating the user or descriminating against careless users.

    Any security solution must be chosen based on the needs at hand and the likelyhood of the people to actually follow the guidelines. SSH generally provides what is called for -- Flexibility. Unfortunately, depending on how it is used, this can introduce insecurity. Like most unix stuff it is perfectly happy giving you enough rope to hang yourself.

    I believe there is no substitute for people having a firm understanding of security, only supplements and tools. Of course I don't work in security and I'm an idealist. Unless educated, people will always do something stupid that you would have never forseen that completely compromises security.

    So you don't think I'm being hostile: Your last paragraph is probably right, I would say SecureID is probably the best security option for clueless users. But since I'm sure it's incredibly expensive, it seems like any place that could afford it should have more clueful users! Also you are absolutely correct that convenience is the enemy of security.

  • A potential remote root exploit has been discovered in SSH Secure Shell 3.0.0, for Unix only, concerning accounts with password fields consisting of two or fewer characters. Unauthorized users could potentially log in to these accounts using any password, including an empty password. This affects SSH Secure Shell 3.0.0 for Unix only. This is a problem with password authentication to the sshd2 daemon. The SSH Secure Shell client binaries (located by default in /usr/local/bin) are not affected.

    What the historical relationship bewteen OpenSSH and the SSH company? just the name? Or was there shared source at some point? -M

  • Oh, well.... There's always one...
  • by dj28 (212815) on Saturday July 21, 2001 @11:27AM (#70355)
    Actually, a telnetd security hole affecting just about every OS on the face of the earth was found. It's a remote hole than can be used to gain root access (or whatever user telnetd is running under) and run arbitrary code. The URL is http://www.securityfocus.com/archive/1/197804 It's a major exploit. I suggest everyone shut down telnetd until a patch comes out.
  • Because I remember seeing some security flaws in the 1x versions not so long ago.

    Plus more eyes are on the 2x sources than the 1x.

    Have not even gone into a feature list, you can do that yourself mon ami :-).

    This is a problem with 3x, which is pretty darn new. Who trusts .0 releases anyway?

    StarTux
  • I feel some subtle hostility and contempt towareds SSH Communications Security Corp in your post. How unfortunate. SSH Secure Shell is a good idea and a great product. Without the graciousness of SSHCSC there would be no free alternative, and many more people may have suffered because of this particular vulnerability. Are you advocating open-source solutions or spreading propoganda? Its a tough call - you choose your words almost too well.

    Its great to see helpful notices like this on Slashdot, but if you could just check your hostility at the door...

    Nick
  • Got to love it when I make a joke and it is modded as insightful. Please DO NOT follow my advice above (you can use /bin/false if you need to have user accounts without the ability to log in interactively).

    Sig: Tell all your friends NOT to download the Advanced Ebook Processor:
  • /usr/bin/yes was a joke...

    I would actually use /bin/false because it immediately terminates the session returning an error.

    I don't use host based (at least name or address based) authentication either, except as one layer in VPN setups. No credentials, no access. Certificates are fine, as are Kerberos tickets. But host-based authentication is only one layer and is in no way trusted on my network with the security.

    Sig: Tell all your friends NOT to download the Advanced Ebook Processor:

  • Or set default shell to /bin/false (though for an attacker, /usr/bin/yes could be amusing...)

    Definitely make an impression on those folks...

    Sig: Tell all your friends NOT to download the Advanced Ebook Processor:

  • Not two-char passes; two char entries in /etc/passwd. Solaris uses the keyword "NP" in records in /etc/passwd when there is "no password" -- when no one is supposed to be able to log in as that user.
  • OpenSSH on Solaris 8 was easy... You probally didn't RTFM. Were you running EGD? Did you use the correct make and C compiler?
  • I take a SuSE machine, then login as eg 'bin' over SSH and enter any old password and I'm let in?

    OK, I swear I am NEVER going to rip on Microsoft for crap security again.
  • I would think the two organizations are pretty hostile at this point, considering this [slashdot.org].

    As far as I know, OpenSSH is not a fork of "SSH."

  • Why is the the price of the software listed whenever this product is mentioned?

    SSH is a great product and well worth it's price. The company has been very response to bugs in the past, this one being no exception. I've been using the commercial SSH for years now. It has a very liberal educational license and the ALL the source for the unix version is available. In fact I usually compile from source. Plus I seem to remember just as much OpenSSH holes in the past as ssh.com ones.

    From the article I pickup the old 'all commercial software is bad and opensource rules' attitude, and for a journalist that's just frickin' sad.

  • Is there _ANY_ reason to use the commercial ssh?
    I'm doing very fine with openssh.
    Can someone tell the difference?
  • Well if I shut down telnetd how am I going to telnet to my router-box-in-the-closet to upgrade?!
  • Without the graciousness of SSHCSC there would be no free alternative

    Yes, there would. Witness GPG and all the alternatives that sprang up to RSA encryption when it was patented. Witness gzip, a better compression scheme that arose in response to the LZW compression patent.

  • As stated in the advisory, the two-character limit applies to the encrypted password field in /etc/passwd. So, if you have an entry that reads something like:

    bin:NP:1:1:bin:/bin:/dev/null

    you are vulnerable. (Obviously, telnetd, popd, and others will read this as "no password" and unconditionally deny logins.)

    --The Shortcut

  • by Shortcut to CmdrTaco (460807) on Saturday July 21, 2001 @11:40AM (#70370)
    Time and again, ssh.com's product has exhibited embarrassing [securityfocus.com] security [securityfocus.com] flaws [securityfocus.com]. It's about time for the company to re-evaluate their strategy. Since OpenSSH has outclassed the ssh.com software in every way ever since the release of OpenSSH 2.0, ssh.com needs to just bite the bullet, make peace with the OpenSSH folks, and sell support for the superior product. There was a time when they could have made a good business out of developing SSH, but that time is passed and all that they are managing to do nowadays is sell snake oil. And the last thing that the internet needs nowadays is another pathetic "security company" that sells insecure products. It's good for script kiddies, bad for admins, bad for the net, and bad for the reputation of UNIX-like systems.

    --The Shortcut

  • "Root, hole, or die?"

  • Yeah, I was punning. But you're right, not everyone would have caught it. I'll use a smiley face after it next time. ;)

  • This is not too far off what MS have done with SMB
    authentification (Network neighbourhood)
    When you send the password, they only check up to the size of the password you send..
    e.g. The password is "Password" but it will allow "P", "Pa" etc..
    Linux smbclient can be hacked in a few hours to simply try every single letter, and with a another half hours work, then expand it so once it knows one letter, it gets the next etc., hence finding the full password.

    I have used this hacked version with much success, and this works in 95 and 98 :)
    (Not later tho.. they fixed it heh)

    But even MS do dumb things like this.. ;)

Time to take stock. Go home with some office supplies.

Working...