RE: SSH Exploit Request

["Robert Davies" <phantasm () textbox net>]

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!

RKD

> -----Original Message-----
> From: Valdis.Kletnieks () vt edu [mailto:Valdis.Kletnieks () vt edu] 
> Sent: Thursday, November 13, 2003 11:08 AM
> To: Jeremiah Cornelius
> Cc: full-disclosure () lists netsys com
> 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.
Charter: http://lists.netsys.com/full-disclosure-charter.html