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]
Date: Fri, 18 Feb 2011 13:33:32 -0500
From: Valdis.Kletnieks@...edu
To: Charles Morris <cmorris@...odu.edu>
Cc: full-disclosure@...ts.grok.org.uk, "Zach C." <fxchip@...il.com>
Subject: Re: Vulnerability in reCAPTCHA for Drupal

On Fri, 18 Feb 2011 10:07:26 EST, Charles Morris said:
> It is my personal belief that all vulnerabilities should be patched
> regardless of existence of a known attack vector or exploit.

Let me fix that for you:

All vulnerabilities should be evaluated as to whether patching them
makes sense.  If it's a one-liner fix for a stupid logic error, yes
it probably should be patched whether or not there's a known exploit.

The problem starts when you hit something that's a deeply seated design
issue in a published API - then you need to balance the costs of possible
exploits against the equally real costs of fixing the problem (which may
end up requiring a possibly large number of third parties to fix their
usage of the API).  The Windows "shatter attack" is a good example:

https://secure.wikimedia.org/wikipedia/en/wiki/Shatter_attack

Why was that such a pain to fix over multiple years? Because you couldn't
fix it without breaking legitimate users of the interface.  And here it is
almost a decade later, and I'm not 100% convinced it's totally fixed yet.

That one was pretty obviously an issue where a paper was out showing how to
exploit it, in a very highly visible and widely distributed piece of software.
But there's plenty of packages that have only thousands or even mere hundreds
of users (especially off on the long-tail end of open-source).  If one of those
projects is discovered to have a major hole, but it's a package that's usually
used on a laptop and you need to run code on the target machine, how important
is it *really* to be patched? If the attacker is already running code on your
laptop as another user, the additional privilege escalation to your userid may
not matter that much anymore...

So yes, evaluation is needed.  But patching it may not make any realistic
sense, depending on the nature of the issue and who is potentially affected.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists