RE: [Full-Disclosure] SSH Exploit Request

From: Robert Davies (
Date: 11/13/03

  • Next message: Ryan Johnson: "Re: [Full-Disclosure] Re: Funny article"
    To: <>
    Date: Thu, 13 Nov 2003 12:08:41 -0500

    I am failing to see the logic in some of these issues here...

    A service is flawed in one way or another, patch it! If the vendor says the
    service is broke in some way, believe them, get off your lazy ass and get
    patching. If you are the admin, do your job and quit whining!

    Since that argument throws about the sniveling of, "We can't afford the
    downtime of a server reboot", then think of it this way, with services such
    as SSH, a restart of the SSH Service does NOT shut down the whole server or
    kill active connections, instead it's a 2 second lapse where the server will
    refuse the connection, in which super important person Z will just have to
    rety to connect.

    If that is not good enough for you, then think of it another way, while you
    sit there thinking about if it is reasonable to take the 5 minutes out of
    your day to compile updated packages and install them as needed, some skript
    kiddie is going through your server looking for more toys to play with on
    your network.

    If the reluctance in patching is due to upsetting someone whom can't afford
    the downtime, think about your job security after your network is breached
    and you did not take the initative to repair a critical flaw anyway.

    I am quite bothered out the ass by well paid admins that are too damn lazy
    to spend the few minutes it takes to repair a flawed service. Either start
    doing your job, or get the hell out of the way for those of us that want to
    do the job required properly!


    > -----Original Message-----
    > From: []
    > Sent: Thursday, November 13, 2003 11:08 AM
    > To: Jeremiah Cornelius
    > Cc:
    > Subject: Re: [Full-Disclosure] SSH Exploit Request
    > On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said:
    > > > > We need to test it before we are permitted to upgrade.
    > Please help.
    > > > Help yourself and redesign your patch management.
    > > Yeah. Everyone can do that, smartass.
    > No, he's right. The OP's environment apparently requires that
    > there be testing before they're allowed to upgrade.
    > That's *broken*. Plain and simple.
    > "Testing can reveal the presence of flaws, but not their
    > absence" - Dijkstra.
    > How many people have trouble getting *known* *good* exploits
    > to run in their environment? Now think hard here - if the
    > exploit *works*, then yes, you have a problem. But if it
    > doesn't work, *it doesn't prove the problem is actually
    > fixed*. So you end up in a situation where you have *known*
    > vulnerable boxes, and a fix to install, and the fix isn't
    > being installed because you're busy trying to verify if the
    > patch actually works, or if you simply have a defective
    > exploit that would have worked if you had used gcc 2.96
    > instead of gcc 3.3 (a
    > *known* issue for a lot of exploits), or if you had too many
    > environment variables and something moved around in memory, or....
    > So let's see.. We have a fix from the vendor/maintainer that
    > is claimed to fix the problem. The canned exploit doesn't
    > work. Now, it's POSSIBLE that your exploit is b0rked, the
    > fix didn't work, and if you changed something the exploit would work.
    > Now how much effort are you going to put in to that testing
    > (assuming that you're qualified to do it), while you have
    > vulnerable machines in production?
    > *That* is why the OP's patching scheme is broken.

    Full-Disclosure - We believe in it.

  • Next message: Ryan Johnson: "Re: [Full-Disclosure] Re: Funny article"