full-disclosure - SSH Exploit Request

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]

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