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
| ||
|
Message-ID: <42C4BB3A.4080005@newsguy.com> Date: Fri Jul 1 12:08:30 2005 From: socrates at newsguy.com (Socrates) Subject: RE: Publishing exploit code - what is it good for I for one am glad to see PoC code. Too often vendors are very vague with their patchsets (Oracle basically says to install a huge tarball to fix 'critical' vulnerabilities without listing exactly what it fixes and the recent Backup Exec vulnerability had a later patch version available for a different unrelated problem than the published advisory for the agent password overflow - you had to read three different advisories to find out if the later patchset had the fix - it did, even then it was a crap shoot). Given the lack of disclosure from the vendors, I like to have PoC code available to test if the patch really was applied correctly (and was the correct one). Don't forget the instances when either a patch silently fails, or if you are a security admin, don't trust that the admins really patched all of their machines. I would forgo most PoC codes if vendors would *exactly* explain what was in their patchsets (and provided a way to test for the existence of easily) and what they addressed without these matrix's of different versions of their product cross-referenced to a simple 'critical' reference. Even as vague as MS announcements are, they are still one of the better disclosing vendors when it comes to their announcements. Then again, I like to learn from the PoC code to further my knowledge as how the inner workings of programs work and how much of a poor job someone did while coding it.
Powered by blists - more mailing lists