full-disclosure - David Litchfield talks about the SQL Worm in the Washington Post

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>] [day] [month] [year] [list]

Message-ID: <200301292100.QAA20077@linus.mitre.org>
From: coley at linus.mitre.org (Steven M. Christey)
Subject: David Litchfield talks about the SQL Worm in the Washington Post

Georgi Guninski said:

>This sql hype highly resembles the code red stuff. Then people accused
>eeye for releasing the bug, though they didn't provide exploit
>code. IIRC Litchfield also didn't provide exploit code. Should
>advisories be "There is a bug. Go patch. End."?

Simply put, no.

For CVE, we regularly - almost daily - run into situations where we
can't figure out *which* bug a vendor actually patched.  This is
especially problematic with software that's used by multiple vendors,
and/or with vendors who do not provide specific credits to researchers
or other cross-references, but it also happens even with the best of
intentions.  Consider the series of closely-related PostgreSQL
vulnerabilities that were posted in August 2002, where careful
analysis shows that it's difficult to tell which vendors fixed which
issues.

In the process of asking vendors for clarification, we have sometimes
found they did not patch the bugs that they think they did.  We've
encountered this issue with nearly every major OS vendor out there,
whether open or closed source.

Tracking down these small but important inconsistencies is extremely
difficult when there are only "there is a bug" advisories.  Experience
has shown that to sufficiently distinguish between vulnerabilities, we
often need some notion of what the attack vector (or function) is.

Also, consider problems like buffer overflows, which these days can
include "new" bugs like integer overflows and signedness errors, array
index modification, field length tampering, etc.  Without some sense
of details, the consumer can't tell if a product has "the same old
obvious vulnerabilities" or some new flavors.  As an example, many of
last year's OpenSSH bugs were "interesting" and "new," or at least not
the same old obvious overflows - even if they were called overflows.
This can be inferred from the patches in the cases where the
advisories are not so precise.  On the other hand, one is rarely
certain whether the buffer overflows being reported for Microsoft
products are the "classic" overflows or the "new" overflows, because
there often isn't much detail in the Microsoft bulletins or even
independent researcher advisories.

- Steve