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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200311131607.hADG7kGn005584@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031113/457b3482/attachment.bin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ