lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: phantasm at textbox.net (Robert Davies) Subject: SSH Exploit Request 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@...edu [mailto:Valdis.Kletnieks@...edu] > Sent: Thursday, November 13, 2003 11:08 AM > To: Jeremiah Cornelius > Cc: full-disclosure@...ts.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. >
Powered by blists - more mailing lists