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
| ||
|
From: yossarian at planet.nl (yossarian) Subject: RE: Disclosure policy in Re: RealPlayer vulnerabilities ----- Original Message ----- From: "Pavel Kankovsky" <peak@...o.troja.mff.cuni.cz> To: <full-disclosure@...ts.netsys.com> Sent: Saturday, October 09, 2004 12:11 AM Subject: Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities > 0. ("The primordial sin") The vulnerable product is released and all<BR> > information about the vulnerability is made available *by the vendor<BR> > itself* to anyone with enough competence, free resources, motivation,<BR> > and a copy of the product.<BR> > <BR> > This is conditio sine qua non. The rest of the story is nothing but<BR> > deobfuscation of that information.<BR> Classic - If this does not happen, all the rest must wait. Time and again it has been proved that vendors do not all fix. They have several options: 1. Call it a feature (DSO) 2. Bury it deep in a manual (no it is no disclosure look in manual pt 17, page 2711 third alinea.... (ControlSA default Crypto keys) and let the consultants in the field admit it. 3. Sue the b4stard that disclosed it. 4. Just ignore the disclosure (Compaq Insight Manager before HP) 5. Wait and see since so many products, so little research, no one will notice (Dell OpenManage) 6. Buy the people that disclose ... (well let's just not mention any names in this case) One thing that sometimes works (i have said it here before and have recently succesfully used it - rotten product not chosen by major customer - a big bank): Security Responsiveness Profiling. I.e if your are working for a hired by a possible customer of say product ladidah, in the product selection process, make it big item. Vendor Zippedidoo has never responded to postings about security defects, does not have a proces for reporting vulns, either they make flawless code, but since Zippedidoo Inc employs programmers and other people it is highly unlikely, or they bury it. We grade it a D minus. (since nothing has ever been posted). Vendor Yottum S.p.a. has a visible process for notification of defects you can actually find on their website - but nothing has ever been disclosed, grade it a B (either the product has failed scrutiny - bad sign - or no one uses it - worse. Vendor Memsahib Ltd has a visible process, some defects have been posted including 0day, and got fixed some time later - we graded it an A minus and it got selected. We explained in writing to Zippedidoo and Yottum how they failed. It hurt. The examples i used are mostly old, haven't recently checked.
Powered by blists - more mailing lists