Slashdot Mirror


Due Diligence?

ekr writes "The OpenSSL remote buffer overflows discovered at the end of July got a lot of press here on /. But how many people actually fixed their machines? I decided to study this question, and the results are kind of depressing. Two weeks after the release of the bug, over two thirds of the servers I sampled were still vulnerable. Even two weeks after the Slapper worm was announced, a third of the total servers were vulnerable. The paper can be found here in PDF or Postscript."

5 of 202 comments (clear)

  1. Should have upgraded by Hegemony · · Score: 5, Informative

    I didn't and paid for it. Within about 3 hours time, some bastard got in, created a superuser, DoS'd nasa.gov, spawned a few irc servers, and started scanning other IP's for the same exploit. Damn they work fast.

  2. Re:Vulnerability Check by James_G · · Score: 5, Informative
    How does one check if a server is vulnerable without actually "breaking in", i.e. make oneself liable to prosection? I skimmed through the PDF but could not find anything about this.

    Well if you'd read the PDF instead of skimming it, you would have seen this:

    Thus, we can simply connect to the HTTPS server and issue a HEAD request. The server responds with an HTTP header containing the Server: field and hence the answer we desire:

    Server: Apache/1.3.26 (Unix) mod_ssl/2.8.10 OpenSSL/0.9.6

    They then went on to verify that SSLv2 is not disabled, but they mention later in the paper that on only 10 hosts was this done.

    Theoretically you could change the response to report the more recent version which would make this check innacurate, but why would anyone bother doing that? Far easier to just upgrade OpenSSL.

  3. Due diligence. by Black+Parrot · · Score: 5, Informative


    This is too easy, folks. Subscribe to your distro's update announcement list, read your mail daily, and apply the relevant patches promptly.

    It's really not that hard. A typical update for me is:

    1. read mail
    2. ncftpget whatever.rpm
    3. rpm -Uhv whatever
    4. read rest of mail
    By far the most time-consuming part is waiting for the RPM to download. Some say that it's even easier for source-based distros.

    --
    Sheesh, evil *and* a jerk. -- Jade
  4. Run right out and get nessus. by AugstWest · · Score: 5, Informative

    If you haven't yet, you should definitely check out nessus.

    It'll scan your machiens for known vulnerabilities and give you pointers on how to go about taking care of any that it finds. It's also got built-in updating to pull in the latest exploits.

    The clients are even getting pretty spiffy these days, and the project has matured very rapidly.

  5. Downstream Liability by sczimme · · Score: 5, Informative


    In the same vein, readers might be interested in a presentation we did at RSA 2002; the topic was Downstream Liability for Attack Relay and Amplification

    (A two-page summary is available here.)

    We described a scenario in which an intruder compromised a system, used it as a jumping-off point, and subsequently caused damages to an individual. The paper focuses on the legal side of things; IANAL but the other two authors - Tim Rosenberg, J.D. and Ron Plesco, J.D. - are.

    I also state my opinion, which is that "...patches should be installed no later than ten (10) calendar days after release of the patch by the vendor". Discuss.

    --
    I want to drag this out as long as possible. Bring me my protractor.