Hacking For The Common Good?

[InfoSec News <isn () C4I ORG>]

http://www.zdnet.com/intweek/stories/columns/0,4164,2596829,00.html

By Lewis Z. Koch, Inter@ctive Week
June 29, 2000 2:32 PM PT

He's nice-looking, polite and very intelligent. He goes by the name
Rain Forest Puppy, RFP for short. It's a name that might suggest
environmental leanings, but that would be a serious miscalculation.
RFP may turn out to be the software industry's worst nightmare. RFP,
for the pure pleasure of the intellectual chase, finds flaws and
vulnerabilities in programs that leading software companies insist are
really features that work to your benefit.

In reality, these programs are so badly constructed that, rather than
hinder malicious code such as the ILOVEYOU virus, they actually helps
viruses multiply and perpetuate themselves; they are built so sloppily
that 15-year-old computer miscreants can bring down Web sites such as
CNN and Yahoo!; and so poorly secured that people's credit cards,
medical records, Social Security numbers - whatever shred of privacy
one might wish to retain - are open to anyone who wants the
information.

In fact, these programs are so bad that a multimillion-dollar industry
has sprung up just to fix flawed software.

It used to be that when a hacker informed a software manufacturer of a
flaw in its programs that could be exploited for nefarious purposes,
the response, if any, was less than gracious. Not surprisingly,
hackers feel that their research has often saved software makers from
real chaos. Manufacturers are still not grateful. In fact, they often
accuse hackers of "promoting" their software's vulnerabilities,
believing in the Bishop Berkeley school of security: If no one hears
the tree fall - that is, the flaw in the forest of code - it doesn't
make a sound, or exist.

In the hacker community everyone wants to know about fallen trees.
They comb the Internet looking for them; some even take credit for
cutting them down.

New game rules

RFP, after consulting with several others, has submitted to the
Internet an "issue disclosure policy" - a kind of White Paper, a
work-in-progress that in its final form might result in a new
relationship between software manufacturers and the flaw-catchers.

First, three quick definitions: 1. There's the issue - that's the
vulnerability or flaw. 2. There's the originator - the person or group
who found the issue. 3. And there's the maintainer - the individual,
group or vendor that maintains the software, hardware or resources in
question.

Ticktock, ticktock

> From the time the originator contacts the appropriate e-mail addresses
found on the maintainer's Web site, the maintainer would have two
working days to respond that it is now aware that a problem exists. If
the maintainer chooses not to respond, the originator may publicly
disclose the issue on the Net in as much detail as he or she chooses.
In other words, the flaw-catcher is sending the message: "Talk to me
about this problem I discovered or face the consequences of dealing
with thousands of interested folks who might relish exploiting this
vulnerability."

If the maintainer does respond, the maintainer then has five working
days in which to fix the problem. If the problem isn't fixed, it will
be posted all over the Internet.

The maintainer also has to acknowledge the work done by the originator
in identifying the problem. RFP says that if the maintainer wishes to
compensate the originator, that's OK, too.

One hand clapping

Dorothy E. Denning, professor of computer science at Georgetown
University, is the author of the highly respected, enormously detailed
Information Warfare and Security (Addison Wesley). After reading RFP's
"policy," Denning said his approach was "pretty good." But she had
three problems, the first of which had to do with RFP's timeframes:
the two-day notice and five-day fix limits.

In an interview, RFP said the maintainer must merely send an
acknowledgment in two days - "a 'Yes, got your letter. Seems
important. Thanks. Back to you ASAP.' Nothing more than that."

RFP is flexible on the five-day fix, too. "A lot of vendors say: 'I
can't do a fix in five days.' You don't have to," he said. "You just
have to communicate with the originator that you're working on it.
Serious communications - not some bland, canned response like: 'We're
doing regression analysis and that will take some long time.' The fact
is, if you give them lots of time, they'll take it because they can."

Denning's second concern was with RFP's demand for "credit" and
"compensation." Denning contended that's a business decision for the
maintainer, and that it's a demand that could lead someone to infer
"extortion."

Here, too, RFP offers a necessary clarification. Giving credit, he
said, is nothing more than what responsible academics do all the time:
The person who discovered the problem deserves to be given credit.
That is why God created footnotes.

As for "compensation," RFP said he is not talking about money or
computer hardware. He's referring to being put on exclusive,
invitation-only lists the maintainers keep for elite people within the
computer community with special knowledge or interests, receiving the
latest updates, "neat tools" or a full version of the product.

Denning's final worry was about RFP's willingness to publish
"information about the vulnerabilities." What about "publication of
exploit tools?" she asked - the means by which one can manipulate the
purely intellectual flaw and exploit it for use in plundering a
computer, Web site or e-mail program.

RFP has two concise responses: "When computer security people suggest
fixes to their clients, they are constantly being bombarded by clients
who demand to know: 'Is it in exploitable form? No? Then we don't need
to fix it.' "

Besides, lack of a published way to exploit a flaw is a moot point,
RFP said, since there is growing sophistication, even among the
relatively inexperienced young, regarding methods for malevolently
manipulating code. "The fact of not publishing the exploit won't stop
anyone, except for the 24 hours it takes to write the exploit."

Software makers may despise RFP's "issue disclosure policy," but they
will have to deal with it. If they ignore it, they do so at their own
peril.

By the way, whose definition of secure code do you think U.S. District
Court Judge Thomas Penfield Jackson would accept - one written by
Microsoft Chairman Bill Gates or one written by RFP?

ISN is hosted by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".