Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Slashback

Slashback: OpenSSH, Bio, Timeliness 382

Posted by timothy from the fireworks-approach dept.
Welcome to Slashback, with updates (below) on a handful of recent Slashdot posts. Most importantly, a message regarding OpenSSH 3.3 could save your system from attack -- read it; you might need to pass the word on to your vendor, too.

Things that make you want to bring back thumbscrews. A few days ago, we mentioned the release of OpenSSH 3.3; compared to previous versions, the biggest change in 3.3 is increased emphasis on privilege separation. Today, Theo de Raadt sent word of an OpenSSH vulnerability being worked on by ISS and the OpenBSD team, details of which are expected to be published early next week.

In an announcement sent to bugtraq, he wrote: "However, I can say that when OpenSSH's sshd(8) is running with priv separation, the bug cannot be exploited.

OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.

However, everyone should update to OpenSSH 3.3 immediately, and enable priv separation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file:

UsePrivilegeSeparation yes

Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?

3.3 does not contain a fix for this upcoming bug.

If priv separation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us."

Theo emphasizes the role of vendor cooperation in making privilege separation work on the full range of systems on which OpenSSH runs. "If the vendors don't start pulling their part," he says in an email, "by the time the bug is posted their customers will be left unprotected. These vendors who do not do the right job and instead just 'sell sell sell' are starting to become annoying. On a lot of systems today, privsep does NOT work well at all. The vendors have not been helping!"

A patched version of OpenSSH could be released as soon as Friday, incorporating vendor patches received by this Thursday.

Read More on Stallman. Vamphyri writes: "Sam Williams, author of 'Free as in Freedom', biography of GNU/Linux founder Richard M. Stallman has gone live with the online free version 1.0 of FAIFzilla.org. The paper pulp version publishers O'Reilly & Associates agreed under the terms of the GNU Free Document License and have their own version up at their site. Williams' site allows for content and corrections to be submitted by readers. He hopes for contributions to be included in later editions of the O'Reilly bio. Also: CGI coders wanted for site enhancement, paragraph and line numbering, searches etc. Maybe a CVS Tree is in order? :)"

"Urpmi Norton" doesn't work for some reason. MrResistor writes "Upon logging in to my computer at work this morning, I was greeted by a virus update notice from McAfee SecurityCenter. The update for today includes W97M/Melissa@MM, and of course McAfees newly manuf^H^H^H^H^Hdiscovered threat, the W32/Perrun JPEG virus (which was also highlighted in yesterdays update). All of the updates in the last week or so have been rated Low or No Threat (except for Perrun, which is "Low On Watch". It seems that in addition to manufacturing new threats, they're also rehashing old threats to keep subscription renewals up. Perhaps it's time for Slashdot to add an Ethics topic?"
This discussion has been archived. No new comments can be posted.

Slashback: OpenSSH, Bio, Timeliness More

Slashback: OpenSSH, Bio, Timeliness

Comments Filter:

  • Ethics Topic? (Score:5, Funny)

    by einstein ( 10761 ) on Monday June 24, 2002 @08:05PM (#3760046) Homepage Journal
    Ethics topic? I thought we had "The Almighty Buck" topic to take care of those pesky ethics...
    ---

  • OpenBSD remote hole? (Score:5, Interesting)

    by armie ( 32968 ) on Monday June 24, 2002 @08:07PM (#3760053)
    Since sshd is enabled by default in OpenBSD 3.1 (OpenSSH 3.1), and privilege separation isn't enabled by default, doesn't that mean OpenBSD 3.1 has a remote root hole?
    • I have no idea how OpenSSH is configured out of the box on OpenBSD, or where the (potential) hole is for that matter, but I doubt it.

      Since its recomended as the right way of doing it, RootLogins are probly set to off. The hole might only allow access to the user account your trying to login as, and with RootLogins to off, it probabaly trumps any user hole.

      • Exploiting a daemon running as root is going to yield root privileges, it doesn't matter if root is allowed to log in through that daemon or not. You're talking about two different concepts here.

        • Re:OpenBSD remote hole? (Score:3, Informative)

          by ChadN ( 21033 )
          Yeah, but it depends if the nature of the exploit is one that yields execution privileges (such as corrupting the user stack and running your own code before sshd drops down from root), or is a protocol weakness which then allows you to (for example) bypass authentication and log in, which would give you user privileges (assuming root logins are disabled).
          • Based on the fact that privilege separation fixes this, it's reasonable to suppose that the flaw is in the authentication code, and allows users to execute arbitrary code.
        • If you run chroot, a root exploit will have limited impact. In this case, I bet running sshd chroot is not very useful. It sure helps with other applications, though.

    • Re:OpenBSD remote hole? (Score:5, Insightful)

      by evilviper ( 135110 ) on Monday June 24, 2002 @09:51PM (#3760430) Journal
      I don't have an OpenBSD 3.1 box handy to check to see if priv seperation is enabled by default. However, I know it wasn't on 3.0.

      But, we need not jump to conclusions. Theo was saying quite a bit about vendor support, which means he was strugling with the PORTABLE version, he made no mention of the native OpenBSD version, and we have yet to even hear the implications of this bug (hell, maybe it's not exploitable on OpenBSD, just OTHER platoforms running OpenSSH).

      Again, don't jump to conclusions.
    • doesn't that mean OpenBSD 3.1 has a remote root hole?

      In common with every single other network OS out there, it has several remote root holes. We just haven't figured out what they are yet.

  • OpenSSH Support (Score:2, Redundant)

    by mastersage ( 83040 )
    With the recient Interview with the CEO of UnitedLinux and the following discussion of giving back to the community you can see how important this is. How many systems use SSH? Every single one of mine. This is where a UL can really shine, but helping OpenSSH in the shape of work towards a patch. This helps provide security to the distos and gives back the community for people who run smiliar setups.

    This really shouldn't stop with SSH though. Distros in general should be helping out large development projects like this.

  • For FreeBSD users: (Score:3, Informative)

    by Anonymous Coward on Monday June 24, 2002 @08:25PM (#3760137)
    To fix your freebsd boxen:
    1. cvsup your ports. Need help? Read the handbook at www.freebsd.org [freebsd.org]. READ IT, DAMMIT
    2. Install the portable openssh port at /usr/ports/security/openssh-portable. Read the pkg-descr about why it's called portable. READ, DAMMIT. It should link against openssl 0.9.6d, so that's why you needed to cvsup your ports.
    3. Enable privsep in the config file:
      UsePrivilegeSeparation yes
      Read the rest of the config. READ, DAMMIT.
    4. Since the port requires privsep, add a user and group for sshd. Just: man adduser(8). Read this man page. READ, DAMMIT.
    5. Since privsep requires a chroot, make a directory in /var/empty for it to chroot to.


    For linux users, you guys are outta luck. Contact your vendor for an rpm. Or, install the source to openssh by hand, and solve all the damn pam errors. We can cover you guys for a few days, so firewall behind a buddy with freebsd until you get this all rpm-happy. :)
    Good luck.

  • Theo D. (Score:5, Funny)

    by The Visiting Priest ( 21903 ) on Monday June 24, 2002 @08:48PM (#3760217)
    After reading that post about OpenSSH, I
    really do not understand how anyone could find
    this guy difficult to work with.

    • Re:Theo D. (Score:2, Insightful)

      by elmegil ( 12001 )
      'Cos God Knows those Evil Vendors have nothing in mind but SELL SELL SELL. No way that they have quality control/assurance processes that, while bureaucratic, make a good faith attempt to keep from introducing NEW problems with fast fixes.

      I guess Theo is just offended that he's not offered more trust for quality software than the vendors' own employees.

  • To all the OpenBSD lost its claim posters.. (Score:5, Insightful)

    by antis0c ( 133550 ) on Monday June 24, 2002 @08:52PM (#3760233)
    This could be flamebait, but it should be said.

    Consider this, would you rather use an Operating System, where the community just shrugs off the frequently once a week remote holes with simply, "go grab the updates" ..

    .. or an Operating System where the community is surprised and in disbelief that a remote hole was found after 5 years which causes entire community to start bitch fights over the right to claim its the most secure Operating System still, despite the fact the remote hole was found by the Operating System developers, and fixed before it has actually been exploited.

    You don't have to be Stephen Wolfram to figure this one out.

    • Fixed before it has actually been exploited? I think not. The real danger of NOT doing security audits is the fact that there are real hackers out there who might know about this hole and are more interested in hacking than getting their names on the big screen as the "l33t d00d" who found the hole.

      Just like the crypto people assume the NSA is 10+ years ahead of them in codebreaking, you should assume that EVERY remote hole has been known to somone within the hacking community prior to its "announcement".

  • Linux BIAS (Score:4, Interesting)

    by jolan ( 187075 ) on Monday June 24, 2002 @09:18PM (#3760325)
    funny how this didn't make it into the main article:

    We've been trying to warn vendors about 3.3 and the need for privsep,
    but they really have not heeded our call for assistance. They have
    basically ignored us. Some, like Alan Cox, even went further stating
    that privsep was not being worked on because "Nobody provided any info
    which proves the problem, and many people dont trust you theo" and
    suggested I "might be feeding everyone a trojan" (I think I'll publish
    that letter -- it is just so funny). HP's representative was
    downright rude, but that is OK because Compaq is retiring him. Except
    for Solar Designer, I think none of them has helped the OpenSSH
    portable developers make privsep work better on their systems.
    Apparently Solar Designer is the only person who understands the need
    for this stuff.

  • Theo de Raadt's message in full (Score:5, Informative)

    by joe_bruin ( 266648 ) on Monday June 24, 2002 @09:25PM (#3760350) Homepage Journal
    From: Theo de Raadt [deraadt@cvs.openbsd.org]
    Subject: Upcoming OpenSSH vulnerability

    There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week.

    However, I can say that when OpenSSH's sshd(8) is running with priv seperation, the bug cannot be exploited.

    OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.

    However, everyone should update to OpenSSH 3.3 immediately, and enable priv seperation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file:

    UsePrivilegeSeparation yes

    Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?

    3.3 does not contain a fix for this upcoming bug.

    If priv seperation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us.

    Basically, OpenSSH sshd(8) is something like 27000 lines of code. A lot of that runs as root. But when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privs. This makes the daemon less vulnerable to attack.

    We've been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because "Nobody provided any info which proves the problem, and many people dont trust you theo" and suggested I "might be feeding everyone a trojan" (I think I'll publish that letter -- it is just so funny). HP's representative was downright rude, but that is OK because Compaq is retiring him. Except for Solar Designer, I think none of them has helped the OpenSSH portable developers make privsep work better on their systems. Apparently Solar Designer is the only person who understands the need for this stuff.

    So, if vendors would JUMP and get it working better, and send us patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday which supports these systems better. So send patches by Thursday night please. Then on Tuesday or Wednesday the complete bug report with patches (and exploits soon after I am sure) will hit BUGTRAQ.

    Let me repeat: even if the bug exists in a privsep'd sshd, it is not exploitable. Clearly we cannot yet publish what the bug is, or provide anyone with the real patch, but we can try to get maximum deployement of privsep, and therefore make it hurt less when the problem is published.

    So please push your vendor to get us maximally working privsep patches as soon as possible!

    We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published).

    Customers can judge their vendors by how they respond to this issue.

    OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away. On OpenBSD privsep works flawlessly, and I have reports that is also true on NetBSD. All other systems appear to have minor or major weaknesses when this code is running.

    (securityfocus postmaster; please post this through immediately, since i have bcc'd over 30 other places..)

    • ...and my analysis (Score:5, Insightful)

      by joe_bruin ( 266648 ) on Monday June 24, 2002 @09:32PM (#3760377) Homepage Journal
      replying to yourself is always a bad thing, but here goes...

      if you cut through the bullshit (theo certainly has an interesting way of putting things), what he's saying is this:

      there's a hole in sshd. we are working on a patch. if we release it now, you are all f'd, because all your systems will be compromised before you have time to patch them. we are giving you the next week to update your sshd, so that you are no longer vulnerable when we publish the bug+patch. yes, the new sshd has the bug, but is not vulnerable to it. if we fixed it now, the black hats will diff the results and be able to develop a compromise, and you still won't have a patch. oh yeah, we need your vendors' help so that you're all safe by next week.

      make sense?

  • The Alternative to OpenSSH or SSH (commerical) (Score:5, Insightful)

    by Tadghe ( 18215 ) on Monday June 24, 2002 @09:28PM (#3760363) Homepage
    LSH (http://www.net.lut.ac.uk/psst/)

    I love SSH. It's been installed on my boxen (regardless of OS) since it was stable enough to kill off telnet.
    My problem with both the announcement as well as the patch is thus.

    1. Theo nor any of the posters I've seen are willing to tell us what the hell is broken. Only that we must upgrade. That just don't cut it, I won't blindly patch without an idea of what is broken. The Debian security release summed it up best.

    "Theo de Raadt announced that the OpenBSD team is working with ISS
    on a remote exploit for OpenSSH (a free implementation of the
    Secure SHell protocol). They are refusing to provide any details on
    the vulnerability but instead are advising everyone to upgrade to
    the latest release, version 3.3.

    This version was released 3 days ago and introduced a new feature
    to reduce the effect of exploits in the network handling code
    called privilege separation. Unfortunately this release has a few
    known problems: compression does not work on all operating systems
    since the code relies on specific mmap features, and the PAM
    support has not been completed. There may be other problems as
    well."

    2. Sudden, lack of belief in Full disclosure. Am I the only guy who remembers the days before full disclosure? The OpenBSD Security policy ( http://www.openbsd.org/security.html ) is pretty point blank (to quote)
    "we believe in full disclosure of security problems. In the operating system arena, we were probably the first to embrace the concept. Many vendors, even of free software, still try to hide issues from their users"
    I think posting a "fix" (ok, workaround) and not telling anyone *why* they should use it is "try[ing] to hide issues from their users"

    I'll be firing up R.A.T.S and checking out LSH ( http://www.net.lut.ac.uk/psst/ ) (GNU'd SSH2ish) for my needs from here own out.

    and yes, this needs a rant tag and yes I know the OSSH and OBSD teams are seperate, but they share enough philosophy and team members that I gather they have the same opinion on security.

    • Re:The Alternative to OpenSSH or SSH (commerical) (Score:5, Interesting)

      by Virtex ( 2914 ) on Monday June 24, 2002 @10:48PM (#3760623)
      1. Theo nor any of the posters I've seen are willing to tell us what the hell is broken. Only that we must upgrade. That just don't cut it, I won't blindly patch without an idea of what is broken. The Debian security release summed it up best.

      In the world of full disclosure, it's generally considered polite to initially only notify the vendor of a product and allow them a grace period to fix the security hole. This way, when the security hole is publicized, users will (hopefully) have a patch or upgrade to secure their systems. The question here isn't whether Theo is correct in holding back the details of the exploit (which I believe he is correct in doing), but whether he should have said anything about the problem at all before releasing the full details. I think his goal was to pressure the OS vendors into helping him fix the problems in his code.

      I won't say whether his choice is right or wrong, but I won't chastise him for protecting my security, either.
      • My point there being that we (in this case Debian users) are pretty much being forced for either jump ship or *trust* a fix that neither we the users, nor the Debian team can verify does what is intended. I'm pretty sure that Theo knows what he's doing, but, I'll not upgrade at "gunpoint" because a vendor won't give me any idea as to what's up. I'm not asking for exploit code, but a decent "this is what's wrong and here's what we are doing to fix it" would go a long way...
        • No, there's a third way, and that's the way Theo proposes: make sshd's privsep work with your system (maybe it already works), then the bug is still there but harmless (since it is in the part of code that doesn't have root-privileges when running with privsep enabled), and will only get the attacker in a sandbox with no privileges. After doing that, everyone (including the Debian folks) has all the time in the world to apply the patch.

          Note that privsep is simply a mechanism to reduce the parts of code that run under root-privileges to about 10% of the total lines sshd(8) consists of. That means, any attack which affects the other 90% will not give the attacker root access on a machine running sshd with privsep. This is a great mechanism to reduce the risk of being exploited. So this means, that the "critical" part of code (where a bug might give root access) is greatly reduced, which also makes it easier for developpers, since they can give the critical part more attention, it's obviously easier to keep 2,500 lines of code (mostly) bugfree, than 27,000, and it makes sense to review those 2,500 lines with greater scrunity.

          The problem with enabling privsep for sshd(8) is, that this only works if some devices/executables/directories have the correct permissions set (my assumption), so it depends on the configuration of other parts of the system that isn't provided/controled by the OpenSSH developpers. This is clearly a packaging issue, and lies in the responsibility of the vendors/distributors.

          So the OpenSSH developpers need the cooperation of the vendors to pull the teeth of at least one known bug (and maybe some yet unknowns) before the patch (and thus the specifics of the security-hole) is released, to ensure a safe period between the release of the patch and its propagation to servers administrated by concerned sysadmins. Also it is generally a good idea to run only that parts of code under root privileges, that is absolutely necessary, so making sshd(8) work with privsep shouldn't have the lowest priority with vendors anyway.

      • In the world of full disclosure, it's generally considered polite to initially only notify the vendor of a product and allow them a grace period to fix the security hole. This way, when the security hole is publicized, users will (hopefully) have a patch or upgrade to secure their systems.

        Well, by releasing the info, the hole HAS been publicized. If you're a black-hat poking around in Apache or Cisco routers or whatever looking for rootable holes, wouldn't you instantly drop what you're doing and start looking for this hole? And if it's possible some already have an exploit, what's Theo waiting for? Give us more details.

        I think full disclosure means "full disclosure", not just partial disclosure, not just, hey, there's a show-stopper bug in the code, but I promise if you upgrade it won't affect you. No workarounds, no details, not even if an exploit has been found in the wild or not.

        Maybe if we knew the details of the bug we could fix it WITHOUT upgrading to the separated privs code. Maybe he wants us to upgrade to this new code because he thinks it's really cool and it strokes his ego, not because it's the only way to solve the hole.

        <theory type="conspiracy">Hell, maybe the OpenSSH server has been hacked by Microsoft and a backdoor added to the new code; this message is a fake to get us to upgrade; and all non-Windows users are doomed.... :-o </theory>

        • Maybe it's just a teaser to see if anyone finds a hole without having to give a prize :-) The will search for exploits for free, but this "mistery" call for much more attention (and rooting a BSD is actually more like a contest)

          (disclaimer: this post is supposed to be mosly humorous...)
        • When you are finished fixing up your tinfoil hat, you can read the diffs to see exactly what has changed.

          • The patch adds privsep which means the exploit is somewhere inside 24000+ lines of code. The diff probably doesn't even fix the exploit: it just avoids using that code as root. Your advice is less than useful.

            • No, the diff from 3.2.3p1 to 3.3p1 does:

              77 files changed, 2172 insertions(+), 1291 deletions(-)

              Most of which are straight moves of code from one file into several. Your comment is less than factual.

              • Did you bother reading the article? OpenSSH is 27000 lines of code and the workaround is "privsep" which makes only 3000 odd lines run with root privs. That means 24000 lines of code might have contained the exploit.

                Looking at the diff file is a damn useless way of figuring out what the exploit is.

                • Looking at the diff file is a damn useless way of figuring out what the exploit is.

                  Did you bother reading my original message? I was responding to the assertion that there may be a backdoor in openssh-3.3. If this was the case (which it is not) then reading the diff would be the best way to detect this.

                  Please read the diff! It is because people prefer to complain more than look at code that we are in this situation.

    • Re:The Alternative to OpenSSH or SSH (commerical) (Score:5, Insightful)

      by Eil ( 82413 ) on Tuesday June 25, 2002 @02:19AM (#3761125) Homepage Journal

      You misinterpreted the entirety what he was trying to say. If I were in a crankier mood I'd ask you if you even read the post.

      In a nutshell, he said this:

      1. There is an exploitable bug in all current versions of OpenSSH.
      2. We're working on a patch, but it's not done yet.
      3. When it is, we'll tell you all exactly what was wrong and how we fixed it.
      4. In the mean time, you can download the latest 3.3 patch and enable privilege separation to completely protect yourself from the vulnerability.

      That just don't cut it, I won't blindly patch without an idea of what is broken.

      There isn't a patch yet. Theo clearly stated that a patch and an explanation will be forthcoming at the same time. The whole reason he announced it early is to get admins to fix thier systems before the nefarious hackers could develop an exploit for it. (As another poster noted, it's incredibly easy for a nefarious hacker to develop an exploit if you have the source code to versions of the program with the bug and a version without. That is perhaps one of the few downfalls to open-source.)

      You'll save yourself a lot of typing and needless jumping (to conclusions) if you read a bit more carefully next time.

  • ISS? (Score:3, Funny)

    by sharkey ( 16670 ) on Monday June 24, 2002 @09:57PM (#3760448)
    So, is this another incompletely researched, uniformative exploit report? Where's the "patch that fixes nothing" for the exploit? Isn't that how ISS does business?

  • They Had _Better_ Already Know (Score:5, Insightful)

    by John Hasler ( 414242 ) on Monday June 24, 2002 @10:07PM (#3760477) Homepage
    "Read it; you might need to pass the word on to your vendor, too."

    If you need to pass the word on to your vendor you need a new vendor.
    • Please, don't bug your vendor about this unless they don't provide a fix in a reasonable time. Any decent vendor is *already* working on a fix for this, and "passing the word on" a million times is just going to be annoying to their poor support folks.

  • Well I just spent a few hours upgrading a handful of openssh installs and firewalling about a dozen others. This is weird though, is there NO other information about this hole except that it's "fixed" by 3.3?

    If I have ssh blocked in /etc/hosts.allow, does that stop the bug? If I have AllowRootLogin off, does that stop the bug? Is it SSH protocol 1 or 2? Can this affect existing SSH connections? Is there any other work-around?????

    I think we just saw TWO irresponsible announcements in the Open Source world, and I hope it's not a trend.

    (SSH is one piece of software I do not like upgrading remotely..)

    PS: I haven't gotten his message from Bugtraq yet. In fact I've only gotten 2 messages from Bugtraq today...weird...

    • Be absolutely certain (*especially* when installing 3.3 remotely) that you have created an sshd user, sshd group, and /var/empty directory prior to invoking OpenSSH 3.3. These requirements must be satisfied even if you do not intend to utilize the privilege separation feature. The daemon fails to start without them.

      (Disclaimer: This may be blatantly obvious to you, but I'm only attempting to help. :))

      • I used the FreeBSD port.. it did it all automatically it seems (and it used /usr/empty). It upgraded openssl as well, hopefully that didn't break anything.

        Sure enough, now when I connect, there are 2 daemons, one running as root and the other not.

        Does anybody know if there are any problems with FreeBSD (the letter just mentioned OpenBSD and NetBSD)...?

    • How is this an irresponsible announcement? This is about as responsible as you can get. "There's an exploit in our code. We can't tell you exactly what it is yet, because we don't have a full patch yet, and we don't want exploits flying around until we do, but if you do [insert procedure here] (which is a good idea anyways) the vulnerability is not exploitable. The patch will be available next Monday." Would you rather they announce it next week, after they have the full patch, so that we can have a race between script kiddies and admins again? Or would you rather know that your machine is safe from the kiddies, before they have the exploit?
      • How is this an irresponsible announcement? This is about as responsible as you can get. "There's an exploit in our code.We can't tell you exactly what it is yet,

        That's why it's irresponsible. If we were told what the problem was then we could make informed decisions about how to deal with it. Some of us might upgrade to 3.3. Some of us might turn openssh off. Some of us might use a different workaround.

        And it wouldn't even be necessary for Theo to personally tell every admin what the problem is. It would be enough (for me) if the Debian packagers were told. But Theo won't even do that! Theo won't even tell Alan Cox! If we can't trust Alan Cox then who can we trust?

        because we don't have a full patch yet, and we don't want exploits flying around until we do, but if you do [insert procedure here] (which is a good idea anyways) the vulnerability is not exploitable.

        Because there are 3 obvious problems here.

        1. Black hats probably already know the exploit. Theo is keeping the information away from the white hats and the users. This is irresponsible.
        2. It's not a simple procedure. It's a complete software upgrade to a known buggy version with missing functionality. And because Theo won't disclose the exploit there's no real certainty that the new version isn't also broken.
        3. It's not about having a full patch. It's about trusting other people to make intelligent decisions when given all the information. Theo never allows this level of trust, and that says worlds about Theo.

        Honestly if Theo had said "we have an exploit, here it is, we won't have a fix for 3 months" then I'd be LESS angry than with his non-disclosure and his "YOU DO THIS NOW" demands.

    • is there NO other information about this hole except that it's "fixed" by 3.3?

      Um, it's not fixed by 3.3!

      What he said was that the bug exists in 3.3, as in other versions (which other versions, he did not spell out)... however, if you use the new "privsep" feature of 3.3, the bug is blocked.

      His stated goal is to get everyone running with "privsep" before the full details of the bug come to light. Even if that means you lose functionality... he feels it is more important to be immune to the possible remote root exploit than to be able to use all the features of ssh.

      If I have ssh blocked in /etc/hosts.allow, does that stop the bug?

      That ought to work: a bug in sshd shouldn't be a problem if crackers can't access sshd. If you have a firewall, and block the ssh port on the firewall, that should be good too.

      steveha

  • An important skill for anyone who uses UNIX, *BSD, or Linux is being able to build and install software from source. If you haven't done it before, take some time to learn how to do it properly. It's easier than you might think, just download the source and read the README and INSTALL files.

    That's kind of why all the source is released -- you really don't have to wait for packages from your vendor. The packages make future uninstall simpler, true, but sometimes you don't have the luxury of time.

    • Even better is to learn to build this stuff on a system like HPUX or Solaris or AIX.

      A lot of open source stuff makes the assumption that you are on Linux or a fully gnuized system.

      It's fun doing the little bits here and there to get it all running on something that doesn't have all the needed stuff out of the box, or that doesn't compile smoothly because of bad assumptions.

      Builds character and grey hair :)

  • OpenSSH patches (Score:3, Funny)

    by FattMattP ( 86246 ) on Tuesday June 25, 2002 @12:04AM (#3760837) Homepage
    I hope you don't let ISS write the patch! ;-)

  • How far BACK? (Score:4, Insightful)

    by evilpenguin ( 18720 ) on Tuesday June 25, 2002 @12:08AM (#3760844)
    Leaving the OS Wars aside (I run Linux, yes, but I also run FreeBSD, and I would run OpenBSD if they would just get unanal about bootable iso's): Okay, swell. 3.3 has a hole.

    How far BACK does this hole extend? Does my 3.1 have it? Does EVERY copy of OpenSSH since the dawn of time have it? Can someone make this clear to me? Is it only versions that have privledge separation? Where is the boundary of this bug?
    • It's in all versions of OpenSSH. And 3.3 with privileges separation prevents the bug from being exploited (ie. it still has the bug, but because of the privileges separation, you're box can't be 0wn3d anymore through this exploit).

      I thought thas was quite clear from this statement:

      However, everyone should update to OpenSSH 3.3 immediately, and enable priv separation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file:
      It would be silly if he said that in case the bug was introduced in 3.3
  • A patched version of OpenSSH could be released as soon as Friday, incorporating vendor patches received by this Thursday.

    Now, why can't MS and the like be that fast? With gazillions of coders on hand, you'd think they'd be able to at least match that. I like how open source projects allow lots of people to work on a problem independantly, all at the same time. The ultimate parallel processing!

    It seems that in addition to manufacturing new threats, they're also rehashing old threats to keep subscription renewals up. Perhaps it's time for Slashdot to add an Ethics topic?

    Well, MF has been known blow virus threats way out of proportion, almost to the extent of completely making them up, as is highlighted in this article. [slashdot.org] And there are probably many other examples of bad ethics. But perhaps a Business topic would be more inclusive? Maybe that's covered by The Almighty Buck, but TAB doesn't seem to fit with ethics as well. Would people stand for replacing TAB with Business, or should an Ethics topic be created, or should we just forget the whole thing?

  • A reply to all those bitching (Score:4, Insightful)

    by hayden ( 9724 ) on Tuesday June 25, 2002 @12:32AM (#3760892)
    Isn't it wonderful how a security hole in an open source program brings forth all the security experts on Slashdot. And they flame someone who know a shit load about it and is dedicated to improving security to the point of being a complete arsehole.

    Anyway. My guess is that this hole is something substantial, possibly very plateform dependent and any patches aren't going to be trivial. Seeing as all you people who felt the need to use fsck in their posts more than once know about as I do about this then my assumptions are as good as yours (and I don't feel the need to use the word fsck as an expletive once). Non-trivial patches mean that commercial vendors are going to take for ever to release final patches and if you are running anything open to the internet then it's likely to be ssh. Add it all up it means this could be very bad.

    Now the OpenSSH team is actually two. One that develops new stuff and does code audits specifically for OpenBSD and another that takes that and ports it to other architectures.

    All those bitching about full disclosure, you manage to be completely committed to a cause, idiots and miss the point of full disclosure all at once. If the bug is bad then releasing it when only the OpenBSD version of OpenSSH is patched would be an absolute security nightmare. Giving vendors advance notice is very much required in this case. When the vulnerability is announced then I'm sure it will be fully disclosed which will provide the opportunity to test a system for vulnerabilities.

    As for you people who are saying Theo is being pro-OpenBSD, read the above paragraph again and answer this question. If Theo really wanted to really rip on other OS's then what could he have done with this announcement? Only OpenBSD not vulnerable and with mindless full disclosure to cover his arse. You do the maths.

    The fact is Theo is a complete arsehole when it comes to security. Some see this as not a bad thing. With OpenBSD security is pretty much everything. To the vast majority of other "vendors" security is something they also do and with this Theo has a legitimate gripe. He has got a shitty reception from other vendors to something that will make a vital link in the security chain more secure. Is he making a point of this? Probably. Is he right to do that? Depends on your point of view. If it gets the "vendors" off their arses and add support for priviledge seperation in their ports then would this be considered a good thing? Most definately.

    When it boils down to it, Theo would be well within his rights to patch the OpenBSD version of OpenSSH (by using priviledge seperation) and hanging the other vendors out to dry. He didn't. Deal with it.

  • I think I'm going to go back to telnet and s/key! When was the last time you heard of a security hole in telnet?
    -russ

  • Does NOT work with 2.2 kernels. (Score:4, Informative)

    by netfunk ( 32040 ) <.gro.sulucci. .ta. .sulucci.> on Tuesday June 25, 2002 @04:03AM (#3761267) Homepage
    This just bit me in the ass, so I'm passing it on.

    The privilege separation code in OpenSSH 3.3 does not work with 2.2 Linux kernels.

    It relies on mmap() semantics that aren't supported before kernel 2.4 (maybe 2.3.x). OpenSSH will configure, compile, and install successfully. It will start up, but it will NOT accept connections.

    Your clients will get a "broken pipe" message, your syslog will get an "mmap: invalid parameter" message.

    The solutions are:
    • Upgrade to kernel 2.4 or higher.
    • Don't compile in Privilege Separation.
    • You might be able to compile privsep in and disable it, but I couldn't get this to work. Maybe I had a typo in my config file. I dunno.


    I didn't see this anywhere until I dug into my syslog and then the OpenSSH mailing list. You have been warned.

    If you do have kernel 2.4, you should read README.privsep in the openssh source distro, since you need to create a special directory and user/group for this (which also bit me in the butt...even if sshd had worked on 2.2, when I restarted it remotely, it didn't come back up because it didn't have that user...yeah, yeah, rtfm. :) )

    Good luck to everyone.

    --ryan.

Slashdot Top Deals

I program, therefore I am.

Close