[Full-Disclosure] Security Vulnerability Reporting and Response Process

• Previous message: Andrew Griffiths: "Re: [Full-Disclosure] Linux 2.0 remote info leak from too big icmp citation"
• Next in thread: Andreas Gietl: "Re: [Full-Disclosure] Security Vulnerability Reporting and Response Process"
• Reply: Andreas Gietl: "Re: [Full-Disclosure] Security Vulnerability Reporting and Response Process"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <feedback@oisafety.org>, "Craig Ozancin" <cozancin@symantec.com>
Date: Mon, 9 Jun 2003 09:11:09 +0100

Hi,

I think the introduction of the process makes a lot of sense,
however, I feel that the process as it stands presents a problem
with regard to dissemination of information.

1. In the proposal, Section 2.3 Timeline:
"The Finder and Vendor observe a 30-day grace period beginning
with the release of the remedy, during which they provide such
details only people and organizations that play a critical role
in advancing the security of users, critical infrastructures, and
the Internet."

a. Who is considered to be part of the exceptional
   list? Members of OI Safety? ISPs? What about security
   consultants?

b. If this information will be made available to anyone that
   plays a critical role in advancing the security of users,
   then how will the list be moderated and controlled?

As this process has been proposed by OI Safety, one cannot help
but think that these exceptions create an unfair advantage for
members of OI Safety. After all, many of the members provide a
chargeable vulnerability notification service (or offer a
vulnerability assessment product) to their customers - if they
are able to offer the information to their customers before the
information is issued to the general public, they have an unfair
advantage over anyone else that is not privy to the early release
of this information.

c. What can be done to prevent this problem from occurring?

2. In 7.3.11:
"The Vendor and the Finder shall exercise reasonable efforts to
avoid providing information in the security advisory that could
aid attackers in exploiting the vulnerability."

  And 7.3.12:
"The Security Advisory shall not include proof of concept code or
test code that could readily be turned into an exploit, nor
detailed technical information such as exact data inputs, buffer
offsets, or shell code strategies."

While the idea behind these points does make sense in that it
will help prevent attacks from 'script kiddies', I think that it
can be safely assumed that any attacker with some skills should
be able to reverse-engineer a fix and discover the underlying
vulnerability that was patched. Once that has been done, it is
likely the exploit details will be made publicly available, in
some form or another.

By not providing this information, smaller security consulting
firms and individuals will be unable to utilise or create PoC
code to test for these vulnerabilities, without having to go
through the 'illegal' process of reverse engineering the patches.
Instead, they will have to wait until details become available
from the 'underground' community... The net result is that
attackers will have a head start and organisation's security will
be put at risk!

Smaller security consulting firms and individuals may not have
the R&D capabilities or budgets that the larger security firms
have (such as the members of OI Safety) and thus may rely on the
exploit details and PoC code in advisories to help them with
their work. In my opinion, there are many smaller security
consulting firms and freelance security consultants that do a
very good job of helping secure the smaller organisations and
home users - something that should not be forgotten.

Organisations should not be forced to have to use vulnerability
assessment tools or services from the larger security
organisations that are privy to this sensitive information or
that have the large R&D budgets for 'figuring out' the underlying
cause / vectors / details of a vulnerability.

In my opinion, the restriction of this kind of information will
do more harm to the industry than good. I also feel that the only
companies that will benefit from the proposed timeline and the
restrictions on 'detailed' information are the OI Safety
companies - as they will share detailed information about the
vulnerabilities and will have access to the information long
before anyone else - giving them a distinct advantage in the
security industry.

a. Is there a way to provide some form of controlled release
   of this 'detailed' information?

b. Again, who will have access to the information and how will
   it be controlled?

I look forward to hearing your response.

Kind regards

Byrne Ghavalas

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: Andrew Griffiths: "Re: [Full-Disclosure] Linux 2.0 remote info leak from too big icmp citation"
• Next in thread: Andreas Gietl: "Re: [Full-Disclosure] Security Vulnerability Reporting and Response Process"
• Reply: Andreas Gietl: "Re: [Full-Disclosure] Security Vulnerability Reporting and Response Process"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]