Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Operating Systems BSD

OpenSSH 3.5 Released 140

Posted by timothy from the vavavoom dept.
Dan writes "Markus Friedl announces that OpenSSH 3.5 has just been released with notable updates since 3.4. It will be available from the mirrors listed at http://www.openssh.com/ shortly. Enhancements include bug fixes, improved support for Privilege Separation (Portability, Kerberos, PermitRootLogin handling), RSA blinding in order to avoid timing attacks against the RSA host key and much more. Congratulations are in order for the OpenSSH team's hard work and efforts."
This discussion has been archived. No new comments can be posted.

OpenSSH 3.5 Released More

OpenSSH 3.5 Released

Comments Filter:

  • sweet (Score:1, Informative)

    by Anonymous Coward
    so when will apple roll it into os x?

    • Re:sweet (Score:2, Informative)

      by Anonymous Coward
      why wait for apple? just compile it yourself....thats the beauty...

  • Check those MD5s! (Score:5, Informative)

    by egg troll ( 515396 ) on Tuesday October 15, 2002 @08:56PM (#4458482) Homepage Journal
    Remember to check the MD5s of those downloads this time around!

    • Re:Check those MD5s! (Score:3, Insightful)

      by MrWa ( 144753 )
      I know this is a good idea, but if someone were to put a trojan in the OpenSSH code...how much harder would it be to put an MD5 that matches the modified code?

      • Re:Check those MD5s! (Score:5, Funny)

        by archen ( 447353 ) on Tuesday October 15, 2002 @10:11PM (#4458939)
        easy, you check the md5 of the md5.
    • If you don't have a copy of md5, you can download it here [i0wnzyou.net].
      ;)
  • ....trojan was discovered in the OpenSSH ftp distribution on August 1st. Anyone who upgraded between July 30 and then is encouraged to read the following advisory to learn how their system may have been compromised.

    At least one major security vulnerability exists in many deployed OpenSSH versions (2.3.1 to 3.3). Please see the ISS advisory, or our own OpenSSH advisory on this topic where simple patches are provided for the pre-authentication problem.

  • Debian (Score:2, Interesting)

    by qortra ( 591818 )
    I'm a dedicated Debian user; does anyone know the usual lag in getting a new version of OpenSSH into the mirrors (I'm guessing it would go into testing or unstable)?

  • Wait a while... (Score:3, Insightful)

    by carlmenezes ( 204187 ) on Tuesday October 15, 2002 @09:02PM (#4458524) Homepage
    Wait a while to see if any errors/security holes pop-up. THEN go out and download it. Chances are you've already patched the version you have. Don't replace it with the new one until you're sure that's a good thing. It'll just save you a lot of extra work.

    • Re:Wait a while... (Score:2, Insightful)

      by zeekiorage ( 545864 )
      With warnings like this, nobody will upgrade and no errors/security holes will come out ;).

      I think if you check the MD5/PGP signatures you should be fine.

    • Re:Wait a while... (Score:4, Insightful)

      by evilviper ( 135110 ) on Wednesday October 16, 2002 @12:25AM (#4459578) Journal
      That is the most ridiculous philosophy...

      The S/Key exploit wasn't discovered until about 4 releases later. If a piece of software is exploitable, there's no magic formula that will result in you getting it after all the bugs have been fixed.

      It makes some sense for Windows, since everything is secret until a release, and is thrown upon the world in an instant, getting spread far and wide to different enwironments. So, bugs are found, but still doesn't help in the security department.
    • Chances are that this release has fewer security problems, rather than more. If it does have security problems, they are highly likely to affect older version as well - the amount of completely new code is not that great.

  • Slow Down (Score:4, Insightful)

    by Anonymous Coward on Tuesday October 15, 2002 @09:02PM (#4458530)
    If you do not have concerns with running the latest 3.4, do yourself a favor and let the 3.5 release wait for a few days. OpenSSH has actually become one of those apps I worry about now, joining the ranks of Sendmail and BIND. What a shame...when software designed solely for the purpose of increasing security cannot be trusted, what is left? Trust nothing I suppose.

    • Re:Slow Down (Score:1)

      by Anonymous Coward
      when software designed solely for the purpose of increasing security cannot be trusted, what is left?

      Not standard telnet. That much is for sure.

    • Re:Slow Down (Score:4, Insightful)

      by erik umenhofer ( 782 ) on Tuesday October 15, 2002 @09:29PM (#4458693) Homepage
      It's not the software that having the security problem, it was a hacked server serving up the software and people not checking thier checksums. Don't blame the software when you didn't check your sum.

      • Re:Slow Down (Score:2, Interesting)

        by Anonymous Coward
        I beg to differ. Read the Security Notices [openssh.com] and weep. I further contend that source of the compromise has nothing to do with the end result. As such, OpenSSH is officially on my "be wary of list" and will remain there. If not for the actual problems in OpenSSH itself, then simply because it is such a high value target.

        • Re:Slow Down (Score:2, Insightful)

          by pope nihil ( 85414 )
          I'd like to point out that the security record of OpenSSH is much better than sendmail or bind. Having a bug like this only once in a while is better than average.

      • Re:Slow Down (Score:1, Insightful)

        by Anonymous Coward
        This isn't true; there were a number of versions of ssh with remote compromises before 3.4.

        On the other hand, its track record is still better than both sendmail and bind. And what else are you going to use? Telnet? VNC? Terminal Server? They all have worse problems.
    • Because Privlidge Seperation is in there, even a serious bug will (now) only result in a compromise of a non-privlidged user account.

      That's enough to negate any concerns.

      • Re:Slow Down (Score:5, Insightful)

        by oh ( 68589 ) on Wednesday October 16, 2002 @01:31AM (#4459767) Journal

        Because Privlidge Seperation is in there, even a serious bug will (now) only result in a compromise of a non-privlidged user account.

        That's enough to negate any concerns.


        I've heard this argument before, and I don't think it holds water.

        Firstly, do you patch all local privilege escalation vulnerabilities as quickly as you patch remote vulnerabilities? I know I don't.

        Even if there are no local vulnerabilities, they can still scan you system for useful information. They can then use you system to attack other systems from behind you firewall. Do you have a local firewall rule that disallows all outbound connections?

        We had a presentation from a (proxy) firewall vendor that used a hardened OS. They were very proud that each proxy ran in its own little sand-box. The mail outside mail daemon could only access port 25 on the outside NIC, and could only pass email to the inside daemon via a shared spool directory. Their OS prevented any other access from that process.

        Whenever we asked about a specific version of a daemon, they would refer to this sand-boxing and tell us that it wouldn't matter if a particular proxy was hacked out, there was no way the hacker could break through the firewall.

        The company I worked for ran one of the largest (top 10, maybe top 5) web sites in our country. There would have been maybe a dozen other websites with similar bandwidth, and maybe the same number of ISPs. We had to sit down an carefully explain to these sales people that even if the hacked proxy could only access one port on the outside NIC of the firewall, it could DOS almost any other site in the country.

        They left that presentation with worried looks on their faces, and promised to get back to us with the version numbers we were asking for.

        Moral of the story: Any malicious use of you systems is a bad thing. "Privilege Separation" may stop them from rooting the box running OpenSSH, but a malicious hacker could still do a lot of damage.

        • Re:Slow Down (Score:5, Informative)

          by dmiller ( 581 ) <djm @ m i n d r o t . o rg> on Wednesday October 16, 2002 @07:25AM (#4460672) Homepage

          Firstly, do you patch all local privilege escalation vulnerabilities as quickly as you patch remote vulnerabilities? I know I don't.

          Please RTFM: An attacker breaking privsep will find themselves in an empty chroot jail with a unique, non-priviliged UID & GID. Leveraging such an attack to even read local files would be very difficult.

          Your points about a broken privsep being used to stage network-based attacks are valid.

          • Your points about a broken privsep being used to stage network-based attacks are valid.

            Don't agree with this point exactly... For one thing, many firewalls (I know PF does) have user/group based filtering... So you could block all outbound traffic from the sshd user. Besides that, a chroot can be created that gives the service NO space on the filesystem, meaning they can't even download an DOS tool if you haven't used the afore mentioned firewalling method. I personally use quota rules to make sure some services don't have the ability to write anywhere, even if they aren't chrooted.

            • Umm, I should also have mentioned... Even if you take NO measures to secure your chroot, since it is not a root account, using it for DoSing wouldn't be (nearly as) useful, since you can not spoof the IP addresses. At that point, it is more useful to break in to Windows machines for the same purpose.

              Besides, what would you use instead? SSH.com's insecure version, which is known to be vulnerable, and doesn't provide priv. sep. at all?
            • A simple ddos tool could even be integrated into the shellcode of the exploit, it wouldn`t be impossible.
            • That assumes the presence of outbound filter rules. (Your idea to filter the privsep user is an excellent one.)

              You wouldn't need filesystem space to launch an attack - you can upload code into the compomised process' address space, though getting this right would be tricky.
              • That assumes the presence of outbound filter rules.

                What does? Spoofing? The privsep user is not root, and therefore does not have the proper permissions needed to stick forged packet directly on the wire.

                You wouldn't need filesystem space to launch an attack - you can upload code into the compomised process' address space, though getting this right would be tricky.

                Not only would it be tricky... It wouldn't allow for long-term situations-it will only be there until the machine is rebooted. That only gives the attacker a very small ammount of space to work with, and can be limited even further with login.conf / ulimit rules, giving the user access to only a very small portion of memory, swap, stack, etc.
        • Also, once soimeone has broken into the sandbox.. they still obviously have access to the daemon they exploited... so they could shut it down, have it serve false content, or log authentication attempts.

    • Re:Slow Down (Score:3, Insightful)

      by EvilAlien ( 133134 )
      The moment you start trusting without question is the moment you should give up paying attention to security. Trust is a vulnerability.
  • Has anyone worked on an embedded port of OpenSSH, specifically the AMD / Alchemy au1500 MIPS core or ARM9?

    • Re:embedded ports for OpenSSH (Score:2, Funny)

      by Anonymous Coward
      yeah, it's called the openssh portable release. to make it run on my arm9 sidewinder (linux), i had to do the following:

      untar it
      type ./configure
      make
      make install

      (remember, the order of the commands is important)

  • My one bugbear (Score:5, Interesting)

    by muzzmac ( 554127 ) on Tuesday October 15, 2002 @09:09PM (#4458576)
    Have they put in provisions to separate the SFTP and interactive shell or command execution protocols?

    Last time I tried to play with SFTP I could not get an external company to have SFTP access without a lot of shell level mucking around to stop them having access to log in via shells or rlogin style features.

    And yes I'm lazy, yes I should ask the question in the correct forum and yes I should probably contribute to the project but I am, I couldn't be bothered finding it again and I would be useless to them.

    Anyway congratulations and thinkyou for what is other than my stupid whinge a great product. (Opensource or otherwise)

    • Re:My one bugbear (Score:3, Informative)

      by Big Jason ( 1556 )
      You might want to check out scponly. [sublimation.org]

      Be aware of the colour scheme on that site though, it's hard on the eyes.

    • Re:My one bugbear (Score:4, Informative)

      by Phibz ( 254992 ) on Wednesday October 16, 2002 @03:58AM (#4460217)
      I've used the scp-wrapper perl script and it works excellently. I add a dsa key for the client and in the key in authorized_keys i add command="/usr/sbin/scp-wrapper" ......

      Basically what the script does is clean the environment. The requested command is stored in SSH_ORIGINAL_COMMAND environmental variable. Its checked to make sure it is in fact the command you intend. The options are then checked. Finally the script exec()'s the hardcoded path to the command with arguments supplied.

      Although it comes written for scp i've used it for securing an account so they can't log in, and they can only execute one or two commands of my choosing.

      from what i understand sftp just exec's /usr/libexec/sftp-server. i don't see why you couldn't alter the script to only allow that command.

      also you'll want to make sure the client's ~/.bash_profile, ~/.profile, etc.--all its login scripts--are empty and owned by root so that they don't upload their own "special" login script and undo all your work.

      scp-wrapper can be found here [snailbook.com]

      Phibz

    • Re:My one bugbear (Score:1, Interesting)

      by Anonymous Coward
      check out RSSH at http://www.pizzashack.org/rssh/. From that page: rssh is a restricted shell for use with OpenSSH, allowing only scp and/or sftp. For example, if you have a server which you only want to allow users to copy files off of via scp, without providing shell access, you can use rssh to do that.
  • That Linux trojan/virus writers have learned to aim at Linux sysadmins by taking control of very recent patches and adding trojan horses. Seems the best way to attack a Linux system is to try to interrupt the many vigilant admins as they faithfully download patches on the same day they're released... Windows trojans survive on the dearth of upgrades, not their spread...
  • What does this have to do with BSD, as opposed to other Unixen?

  • But, but.... (Score:1, Funny)

    by Anonymous Coward
    They told me BSD was dead!!!

  • Where is the public key to check the sig? (Score:1, Insightful)

    by Anonymous Coward
    I can't seem to find a link to openssh.com's public key. I'd like tp putz about with this new version tonight, but I'm not putting it on any server until I can get its contents verified...

    So... any ideas where it might be found?
    • If you are referring to Damien Miller's public key, you can get it off the keyservers. Or, you can get it right here:

      -----BEGIN PGP PUBLIC KEY BLOCK-----
      Version: PGP 8.0 (Build 288) Beta

      mQGiBDqa5pwRBADJSEyXXsgXiyytN93prDPTPmrueRP9lQQf ga QvCvqK0bN0AF1Z
      Vxxk9wlSXQp3+Qw5+qqsN5ovzsn39r9pqG slfCqQn9ACTmsn42 +VCyW4hdwUGSBS
      5myh65ZJTK1ufWCZFssxQ0EiALagu4DlH6 Z2O7tFDnJNagF55v lnK0uMQwCg/8RU
      QYDmisEHjkarAapPaupxjhkD/j9riCVasW PYJwAuhiQWAKxGRw p/ZyTaWCSERUBR
      4Dg9QxpuwHKIT8BeDA3hJa/9Yxu5jec2NV KbtVSZvRkgUfRNOk rcH2eiY8Iz6est
      J64dGWuGMKQW0GEqW+OXpRTTPJZ0mgPmU1 6qDzLPdx6F3BAk2L G+TTwlKUPuGqOt
      6u2EA/4+1CBYZ8mXq9GJnLRBPAoYwSJJzb QnMm9Jat/yg9N6ni gSIiFyG8ixh167
      gGGKfzvpjY7DeJzDI0Cub+tRova8gFg+T1 5AcPMST5v7v6O/ug 9aYWERZ0zjUhRH
      ybtYLYhUUbdYM29PwGBNfZhGIOYwfFE9Up PS5LeXHs28oVLlH7 QuRGFtaWVuIE1p
      bGxlciAoUGVyc29uYWwgS2V5KSA8ZGptQG 1pbmRyb3Qub3JnPo hXBBMRAgAXBQI6
      muacBQsHCgMEAxUDAgMWAgECF4AACgkQzo 7LA4b/nEiDMgCZAU zKq241h5GTJxC0
      guS6ht9i9ZsAoL/oXCmFsofARehZF6AakI dasvS9uQINBDqa5t QQCADz/XnCcyle
      9hmxgyntr35ZQJKx9g6ftBw178JSwM3O7J NOGp398Eh4Q9rkEp 5NH1qVecG953Fu
      edT9IAXqr8pjp5tdqMYCcaKy+aJ0Sw1zVD 2VOY3h7SyfU25pcY iHEa1grfKPVoWm
      53IwWGVVtquF5dimAe75+D0aXyVCOv0Ez9 wgJR6H69lp4/cD2G yNaGarwY9HLvHF
      vXONY2qm/GV5OjyOUO41gmQ4pyXQh+gocF FHrM0AzveIswgNpJ 0xNWXX8iXGsr3Y
      Cvqm7JoIU9JKxDV+96bxDLfTdKpoLYKb68 WdtmAylsio5+iZfW tdOb/Xpk2Yx5Ld
      ady9/+n3m6cvAAURCACrvoVSbd0MR0FWX+ bBZ0NjScNBo3kPSS CnQ6jRHokkz55r
      +MHe7dqxCJ3pmu7aROl2fgug6wob+7+qXf Kke/TdT6wuCb4CdF S6tPgPrfYV+iwq
      2NB/BatePGg7Z6UALaULQ0m83DCEVLJNnj emEdIouShelikAAO 7QDKMr7vAjH8n0
      zwMpwRMXnvCM6zYlS9i1kOm8LVATk0Wyih pQGSaTukdPjKlG7s KwMu20ssK9DGVp
      PgulTZ7rHqXl4juY8LQ2j4dPNaPoKWG8Ju BVCsyf2D6GNW97Pf KQSkzFeZsbVB4S
      RQrVTchgBSYoxRVW3fLk/yc3TC5Abh6Gpj 4izawUiEYEGBECAA YFAjqa5tQACgkQ
      zo7LA4b/nEgftgCdHIZUDVAWDRa5siSi8A os+IiyAgAAn02wGO l1Wo/YJ+RY+c6K
      N58TmAPE
      =rCFY
      -----END PGP PUBLIC KEY BLOCK-----

  • Why I Switched to OpenSSH (Score:5, Funny)

    by Anonymous Coward on Tuesday October 15, 2002 @09:57PM (#4458839)
    OpenSSH gives me the flexibilty and versatility that I demand in mobile computing. As a professional freelance writer, I rely on OpenSSH to customize itself to the way I work to get my job done.

    Before I was using F-Secure SSH, and I always had problems with technical things my poor brain can't comprehend. Now I just tar zxvf openssh.tgz; ./configure; make; sudo make install and generate my public and private keys. It's so easy! OpenSSH gives me more power for less dough -- Girl Scout's honor!

    OpenSSH. It's about more and better.
  • One stumbling block to major acceptance of ssh outside the admin community is the ability to resume downloads. I wish they would add this.

    • Re:Wish list item (Score:2, Interesting)

      by twistedcubic ( 577194 )
      Maybe you could try rsync -e ssh. I've never tried it, but maybe it would just download the diff, which would just be the remainder of the file in this case. Just a random thought, which may not work :)

    • Re:Wish list item (Score:4, Funny)

      by joe_bruin ( 266648 ) on Tuesday October 15, 2002 @11:04PM (#4459207) Homepage Journal
      your wish is granted. say you got the first half of pr0n.tar.bz2:

      $ ssh remotehost -c "tail --bytes=\`ls -l | awk '/pr0n.tar.bz2/ { print $5; }' - `ls -l | awk '/pr0n.tar.bz2/ { print $5; }'` | bc\`" > pr0n.tar.bz2

      now, you're smart enough to turn this into a shell script, right? there's a reason openbsd doesn't ship with a "watch" script.

      note that there is probably an error in that commandline since i never tested it. go ahead, post it.
      • Nope there's an error.

        I tried narrowing it to just the first term where it is getting the remote file's size:

        $ ssh remotehost "ls -l | awk '/pr0n.tar.bz2/ {print $5};' "

        but it returns the whole line:

        -rw-r--r-- 1 user user 10121951 Oct 16 21:40 pr0n.tar.bz2

        Apparently gawk-3.1.0 doesn't work the way one expects when one uses it remotely. Maybe you want to try again, because I'm stumped.

  • Sigh (Score:5, Insightful)

    by starseeker ( 141897 ) on Tuesday October 15, 2002 @11:10PM (#4459253) Homepage
    I see some highly moderated comments that are saying that ssh is no longer to be trusted, and what's left now?

    My contention is that there NEVER WAS any software as secure as these people seem to have though ssh was, and there never will be. It's just too complex a game, and there are people who seem to live on nothing but attacking systems. Given that combination, there will be weaknesses found, as long as humans are a part of the development equation.

    The situation has been improperly defined by the assumptions we've apparently made. Don't expect UNCRACKABLE software - that's just silly. What we have seen with openssh/openssl is exactly what we should be seeing - inevitable problems being openly discussed and fixed quickly. What if someone were to put a trojaned MS update onto one of Microsoft's servers? Would we even know for months? This kind of crap happens. It's part of the cost and reality of using computers.

    Take the rash of reports of vulnerability as a GOOD thing - it's better to know and fix, than wait for a black hat to find it. Of course we try to code and design to avoid weeknesses, but the reality is that life doesn't work like that, and we need to be ready to handle the problems that crop up. Whether or not this is an indication of a design flaw in ssh doesn't really matter either - that can also be fixed. That's what ongoing development is all about.

    So don't diss SSH too much. Constructive discussion only, please. Remember, it's free, it helps, and it's only getting better. If you don't think it's good enough, help them! You can, you know - open source at it's best.
    • "Don't expect UNCRACKABLE software - that's just silly."

      Agreed. Note also the move towards running fewer services and firewalling so that only ports 22 and 80 are open - and wide open, at that. It is my guess that we wouldn't see so many PHP scripting vulnerabilities on bugtraq if people wrote native applications instead of web-apps for e.g. calendaring, groupware, etc, but using their own custom port#s for the purpose instead of flattening everything onto 80.
      I'm not surprised that sort of thing has brought forth a rash of ssh updates.

      I'd also like an alternative to openssl and openssh, other than freessh and lsh which aren't all that well developed yet, but time will tell on that front.
  • Today at work I got a phonecall. The admins portscanned the network, found out I was running OpenSSH, and made me remove it and install a precompiled F-Secure SSH. This bugs me because who knows what they might have implemented my new precompiled ssh?

    Anyways, I think they scanned for OpenSSH because of the recent problems. It seems they release a new version every couple of weeks. There are bound to be bugs. Now, I tend to think that closed-source software probably has more latent bugs and there's just no way to know, but the perception is that constant change means instability and insecurity.

    • Re:Too much change? (Score:2, Insightful)

      by PigleT ( 28894 )
      Your sysadmins are obviously pillocks if they either (a) believe everything in a version banner or (b) don't understand that it's better to have a fixed bug than a multitude of unknown bugs.
      Time to update the CV...
    • Seems fairly easy to avoid: patch OpenSSH to return a header that identifies itself as F-Secure SSH instead. Probably a one-liner.

    • Re:Too much change? (Score:3, Interesting)

      by gol64738 ( 225528 )
      it's likely that the sysadmins had you replace your open source products with a commercial one for blame/fault purposes.
      big corporation sysadmins like to point fingers when something fucks up..otherwise, it's their head.
      by sticking to commercial software, corporate sysadmins can keep that shitball rolling, all the way back to the product company.
      • But commercial software authors also give you "ABSOLOUTELY NO WARRANTEE"
        I really dont expect a warrantee from something i get for free, but if i pay for something i would like it to work, and i would like comeback against the provider of the product if problems with it cause me trouble.
        Example, a few weeks ago a garage fitted a new fanbelt to my car, but it was the wrong type.. it was somewhat too small, it bent the alternator mountings and quite quickly snapped. With no alternator, the battery quickly got discharged as i was finding a safe place to stop, and i was unable to restart the engine.
        The garage replaced towed me for free, replaced the alternator and the belt, and gave me a courtesy car while the work was carried out.. I didn`t try to push it and ask for financial compensation, since i wasnt going anywhere especially important at the time..
  • I would like to see a version that create key files that are compatible with putty and securenetterm. Right now, if I want to use SecNetTerm, I've got to create the key on the Linux box with ssh-keygen, copy it to my pc, load it into putty to convert it, save it out, then move it over to SecNetTerm. Not only that, I couldn't find an easy HowTo that told me how to do this. It took several hours to figure this out.

    I shouldn't have to be a guru just to use SSH.

    • The keys generated by openssh are afaik, compatible with the original ssh. most likely these other programs you mention use their own format for keys, in which case you cant blame openssh.. afterall, how are they supposed to support every nonstandard third party keyfile format?
      • That's true. But consider that what www.OpenSS.org lists on its website at the top of it's page for alternative operating systems Windows & Mac [openssh.org].

        The following "free" clients are recommended for interoperating with OpenSSH from Windows machines:

        * PuTTY is an SSH1+SSH2 implementation. PSCP, an scp-style program for Windows, is also available.

        PuTTY is available under the MIT licence (BSD-like).

        "PuTTY is a free implementation of Telnet and SSH for Win32 platforms, written and maintained primarily by Simon Tatham, who lives in Great Britain."

        If you're going to recommend it, then why not right up front, give some pointers on how to get it up and running.

        Regards.... S
  • I`m sure i will be modded down for daring to flame the openbsd team, but anyway..
    For an os and other tools (openssl, openssh) which is supposedly thoroughly security audited, there have been a lot of vulnerabilities found, some even present in NEW code (as opposed to the original code that openssh for instance was based upon)
    It sure says a lot about the auditing skills of these people if blackhats have been able to find and exploit so many holes, which their supposed auditing missed.

Slashdot Top Deals

I've noticed several design suggestions in your code.

Close