Chapter 3: Proper and Ethical Disclosure
63
code is constantly changing, re-creating the vulnerability can be difficult. And, in these
instances, disclosing these vulnerabilities might not reduce the risk of them being ex-
PART I
ploited. Some are skeptical about using traditional vulnerability disclosure channels
for vulnerabilities identified in website code.
Legally, website code may differ from typical software bugs, too. A software applica-
tion might be considered the user’s to examine for bugs, but posting proof of discovery
of a vulnerable Web system could be considered illegal because it isn’t purchased like a
specific piece of software is. Demonstrating proof of a web vulnerability may be consid-
ered an unintended use of the system and could create legal issues for a vulnerability
researcher. For a researcher, giving up proof-of-concept exploit code could also mean
handing over evidence in a future hacking trial—code that could be seen as proof the
researcher used the website in a way the creator didn’t intend.
Disclosing web vulnerabilities is still in somewhat uncharted territory, as the infra-
structure for reporting these bugs, and the security teams working to fix them, are still
evolving. Vulnerability reporting for traditional software is still a work in progress, too.
The debate between full disclosure versus partial or no disclosure of bugs rages on.
Though vulnerability disclosure guidelines exist, the models are not necessarily keep-
ing pace with the constant creation and discovery of flaws. And though many disclosure
policies have been written in the information security community, they are not always
followed. If the guidelines aren’t applied to real-life situations, chaos can ensue.
Public disclosure helps improve security, according to information security expert
Bruce Schneier. He says that the only reason vendors patch vulnerabilities is because of
full disclosure, and that there’s no point in keeping a bug a secret—hackers will dis-
cover it anyway. Before full disclosure, he says, it was too easy for software companies
to ignore the flaws and threaten the researcher with legal action. Ignoring the flaws was
easier for vendors especially because an unreported flaw affected the software’s users
much more than it affected the vendor.
Security expert Marcus Ranum takes a dim view of public disclosure of vulnerabili-
ties. He says that an entire economy of researchers is trying to cash in on the vulnera-
bilities that they find and selling them to the highest bidder, whether for good or bad
purposes. His take is that researchers are constantly seeking fame and that vulnerability
disclosure is “rewarding bad behavior,” rather than making software better.
But the vulnerability researchers who find and report bugs have a different take,
especially when they aren’t getting paid. Another issue that has arisen is that gray hats
are tired of working for free without legal protection.
“No More Free Bugs”
In 2009, several gray hat hackers—Charlie Miller, Alex Sotirov, and Dino Dai Zovi—
publicly announced a new stance: “No More Free Bugs.” They argue that the value of
software vulnerabilities often doesn’t get passed on to gray hats, who find legitimate,
serious flaws in commercial software. Along with iDefense and ZDI, the software
