OpenBSD Journal

Patching Timeliness

Contributed by jose on from the window-of-vulnerability dept.

After a recent story on Slashdot about how everyone is still running old SSL versions , I decided to gather together some links about patching timelines. Many people are on either end of the spectrum, "I do it right away every time" or "Why bother?"

On Friday, I saw a message on Bugtraq from the people at MITRE who run the CVE service stating that only 45% of vulnerabilities have been acknowledged by vendors . That's a pretty low number, but when you think about the number of acknowledgements you see vs. the number of vulnerabilities announced, that starts to seem realistic.

The "window of vulnerability" has been addressed by William Arbaugh in a pair of papers here and here , which definitely make for some good reading. Pair those up with an excellent 2002 Lisa paper from the guys at Wirex on about patching timelines . Also, an interesting paper from FIRST 1999 discusses patching methodlogies to keep on top of security as well as reliability.

Bringing it all back home, the usage graphs from OpenSSH show a clear response to vulnerabilities and new versions coming out, something which would be interesting to mine for in other services (BIND, SSL). As for OpenSSL vulnerabilities, Ben Laurie's lamentations on the subject are worth reading, too.

(Comments are closed)

Comments

  1. By Anonymous Coward () on

    Don't forget to mention OpenSSH's atrocious handling of their recent security holes in an attempt to force people into upgrading to new and untested versions rather than providing a real fix.

    Comments

    1. By Anonymous () on

      They were trying to get people to UPGRADE to the EXISTING TESTED VERSION of 3.2 that HAD PRIV SEPERATION that WAS A REAL FIX because it MITIGATED THE WORST OF THE VULNERABILTIES. Be GLAD they didn't just throw the patch out there so ONLY A FRACTION OF THE PEOPLE WOULD UPDATE like they ALWAYS DO and thus leading to even MORE COMPROMISED BOXES that you would have to deal with. My boxes already had 3.2 with priv seperation on a month before that even occurred. I looked at theo's email about using it and shrugged and thought "well jee, I'm glad I've already done that."

      Comments

      1. By Anonymous Coward () on

        it is hard to take this response seriously.
        claiming something that mitigates an attack as
        a real fix identifies an misunderstanding of
        the situation. it does not fix the vulnerability,
        thus is not a fix.
        you think chroot can't be bypassed?
        tell me, if someone can execute arbitary code as
        the reduced privilege user "sshd", can they
        own you? yes. kernel vulnerabilities. see
        select(2) or setitimer(2) recently. reduced
        privileges and a chroot jail won't help you here.

        so given there was a kernel vulnerability, and
        given that it could have been exploited even with
        privilege seperation, do you still think
        it was a "REAL FIX"?

        Comments

        1. By Anonymous Coward () on

          So... Mister I know everything... where is YOUR REAL FIX for this problem?

          easy to tell people that there is a problem, if you cannot even remotely help to find a solution.

          Comments

          1. By Anonymous Coward () on

            given that details of the problem were not released, how on earth could anyone construct a fix?
            they would have to find the problem themselves.
            i have no quibble with openssh over how they handled it, but claiming they released a fix in the form of privsep, is a fallacy.
            it is their call. they lost users and (in some people's eyes) credibility not me. if you depend on a vendor you don't trust, you should find someone else.

            Comments

            1. By Anonymous Coward () on

              http://marc.theaimsgroup.com/?l=freebsd-security&m=102516874607014&w=2

    2. By Anonymous Coward () on

      The developers at OpenSSH were handed a bad situation by the reckless manner in which ISS reported the vulnerability. ISS told OpenSSH about the bug, saying they would release an advisory in a week. A few days later, ISS released the advisory early, leaving the OpenSSH team in a bad position.

      It was not entirely the OpenSSH team's fault, and I think they handled it reasonably (they were correct in that privilege separation mitigated the attack). They were scrambling to make that very platform-specific feature work on platforms (Solaris) where the vendors weren't doing a damn thing to help them.

      By the time the actual week rolled around (the time when ISS claimed at first that they were going to release the advisory), the OpenSSH guys had released all the details and the "real fix".

      What more do you want? They don't even get paid to do this. There are commercial vendors that wouldn't have even responded at all in a week, much less responded immediately with a workaround and a new version within a week.

      Comments

      1. By Anonymous Coward () on

        i still think the critisim of ISS isn't called for. iirc it was someone on the freebsd security officer list that leaked information hence the early/bodged reporting.

    3. By Anonymous Coward () on

      This is not linux. Every new version is not a rewrite of the code! 3.4 contains a large number of small security fixes that you would have to be a complete moron not to want.

      Comments

      1. By Anonymous Coward () on

        3.4 had a drastic feature increase, it was not a single security patch. The correct path would have been to release a fix, not tell everyone there was a problem and force a massive upgrade for no reason. What world were YOU living in?

        Comments

        1. By djm () on

          3.4 had a drastic feature increase

          Bullshit. 3.4 just fixed the bug and included a few more checks.

        2. By Anonymous Coward () on

          If you consider security fixes and checks features, then yeah it had a massive feature increase. Otherwise, you're talking out of your ass.

          Comments

          1. By Anonymous Coward () on

            It WAS a massive feature increase compared to all the previous versions that were supposedly "safe." Try thinking before you post, okay?

            Comments

            1. By Anonymous Coward () on

              No system is 100% sure... even in the best system there are failure.

              So you are really unfaire with the open(bsd/ssh) people saying... the previous version that were "supposedly safe".

              They do what they can do have the most secure and safer system they can imagine/create. But in all case, that's for sure, someone will find a crack and enter.

              The important thing in this matter is not if the code is bullsh*t or was bullsh*t or if the fix is bullsh*t... or I don't know what else.

              The most important thing is that they recognize the problem and they do what they can to close the issue, even if it is a temporary one. And for that I must aknowledge that the open(bsd/ssh) team is really good and remarkable.

              my 2 cents.

        3. By Anonymous Coward () on

          Damn, I forgot all about those new features added in that version. Looks like you used a whole slew of the new flags at once.

          ssh -pt (post troll)
          ssh -m=/. (mentality reduced to that of a slashotter)
          ssh -imfw (I'm a fucking whiner)
          ssh -onrh (Offer no real help).
          ssh -mmuetiamaddgasapw (mod me up even though I'm a moron and deadly doesn't give a shit about post worthiness)
          ssh -dsrisfobiat (deadly should really implement some form of blocking idiots such as this)

          My favourite new flag is probably ssh -;-P

    4. By Bruce () on

      What they did was reasonable, under the circumstances. Because they were looking at a major SSH vulnerability, they wanted to give people a chance to protect their networks without immediately giving crackers an exploit toolkit. Nobody forced you to upgrade. You could even take this warning period as a chance to turn off SSH service on machines where this was an option, or at least to apply firewall rules reducing who could see your SSH port. Personally, I was very happy to have this opportunity to avoid what was about to become a widely known remote root hole.

      You, on the other hand, could just wait the two or three days until they released a specific patch and description of the problem. So what exactly is your complaint? You didn't want people to have a couple days to react to the vulnerability without crackers knowing exactly how to exploit hundreds of thousands of machines on the net?

      Grow up.

      Comments

      1. By Anonymous Coward () on

        Nobody forced you to upgrade.

        That's where you're wrong.

        Comments

        1. By Anonymous Coward () on

          you are wrong too my dear...

          Nobody will force someone to upgrade if they don't want to upgrade. I have a machine and it is still with bsd 2.7 and it works perfectly, and my ssh is not open to the internet.

          Next time I'll upgrade I'll surely take the last version of openbsd and automatically upgrade to the last version.

          Until then... NOBODY can force me to upgrade IF I DON'T WANT TO. I know the risks and I assume it, because I have nothing to loose in my small network where is located my bsd server.

          I have other boxs, and they have been fixed with the fix for openbsd.

          So Mr. I know everything... grow up a little bit before telling so stupid things and crying. Give us solution if you are so good...

    6. By RC () on

      they did not have a fix at the time they reported the bug. The best thing they could have done is to tell you how to limit the effect of the bug, which they did.

      The only thing I thought they did wrong was by NOT telling people that disabling S/Key (or compiling without BSDAuth) would have stopped the exploit completely (then, few would have rushed to upgrade). However, I can understand them not wanting to tell crackers precisely where the problem existed...

      All and all, it was a good handling of the problem.

  2. By Anonymous Coward () on

    Reading version banners will produce a lot of false positives for vulnerabilities. Most security patches make no effort to change the version or version banner, so the scanner will claim that its vulnerable no matter how many times you patch it.

  3. By Anonymous Coward () on

    subject says it all

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]