[ISN] Three Minutes with Rain Forest Puppy

From: InfoSec News (isnat_private)
Date: Thu Oct 04 2001 - 01:02:53 PDT

  • Next message: InfoSec News: "RE: [ISN] Firing (and Hiring) Hackers"

    http://www.pcworld.com/news/article/0,aid,63944,00.asp
    
    [I've really got to tweak the bot that much more and give it a better
    name than just bawt, after a little nudge we were able to find this
    article and three minutes with Scott Culp which will get posted
    tonight also.  - WK]
    
    
    Kim Zetter, PCWorld.com
    Friday, September 28, 2001
    
    Rain Forest Puppy (RFP) is the handle of a well-known twenty-something
    hacker and security consultant based in Chicago. In addition to
    authoring tools that help hackers break into systems, RFP has also
    discovered a number of security holes in software products, which he
    has published on the Web after notifying the software maker. He has
    written a disclosure policy for publishing information about security
    holes, which serves as a guideline for other bug hunters. PC World
    spoke with him about the protocol for publicizing vulnerabilities and
    the pros and cons of full disclosure.
    
    
    PCW: What led you to draft your disclosure policy for publishing
    software security holes?
    
    RFP: I started looking at the discussions that were going back and
    forth between vendors and researchers about disclosing bugs. A
    researcher would disclose a bug without talking to a vendor first, and
    the vendor would say that the unwritten rule was that the researcher
    had to tell the vendor first. The term "unwritten rules" kept coming
    up, and I thought that's the problem, they're unwritten. So I took a
    stab at writing my own, for my personal use, to get the ball rolling.
    
        
    PCW: Are you surprised that your policy has become the industry
    standard?
    
    RFP: I wouldn't say it's an industry standard. A lot of people have
    taken it and modified it to draft their own. I'm not trying to impose
    it on other people. I talked to a lot of people in drafting it to get
    a general consensus, but my way is not necessarily the only way to do
    this.
    
    
    PCW: What has been the response from vendors toward your policy?
    
    RFP: Microsoft is for it. They're the only vendor I really got
    feedback from. I've seen people use it with other vendors, but I
    haven't really discussed with anyone whether everyone was receptive to
    that.
    
    
    PCW: Is the five-day window that you give vendors to respond to a
    report about a vulnerability appropriate? For instance, in the case of
    companies that don't have an organized response team set up, it might
    take them five days just to read your e-mail.
    
    RFP: My policy is that they've got one week, five working days, to
    return communication. If they don't acknowledge it in a week--if
    they're on vacation or whatever--then that's already a poor
    response. Because if you're pushing products out, and you're having
    security problems, and it takes you a week to even become aware of
    them, then that's a problem in itself. We're just talking about a
    matter of initiating communication, not the time in which they need to
    get the fix out. Some people do have a policy that says you have seven
    days to fix this or I'm releasing the announcement. Of course, that's
    impractical in some situations.
    
    At least, acknowledge [my e-mail], tell me what you're doing to fix
    the problem. If you need more time, tell me the reasons why you need
    more time, just explain it to me and be honest. The policy is not
    about how to disclose the vulnerability, it's more about how to get
    both parties to effectively open a communication channel and what each
    one should expect from each other.
    
    
    PCW: In general, how good are vendors at responding to problems?
    
    RFP: They're getting a little better. The big players at least have
    become aware of the need to respond and are doing the right thing. The
    problem is the rapid introduction of new vendors--on a daily basis
    there are more and more people getting into the game, making software,
    pushing out products. While one or two vendors start to get it, you
    have four or five new ones--the mom-and-pop-shops--that haven't
    encountered this issue yet.
    
    
    PCW: Is the ratio of holes to lines of code in software getting worse?
    
    RFP: I don't think the ratio is getting worse, the amount of code is
    increasing. Everyone is doing it bigger and better at such a rapid
    rate; the code base is just expanding at an enormous rate and because
    of that bugs are introduced.
    
    
    PCW: Consumers blame vendors for getting products out too quickly and
    not putting the effort or money into testing. Is it correct to blame
    software vendors?
    
    RFP: A company will not sell products if security is its number one
    focus. Getting the product out to the customer, having it work, and
    making the money are all first, and security falls down on the list
    into sixth or seventh place as far as priorities. It really comes down
    to risk mitigation. If one or two bugs leak through, are they willing
    to accept that risk? Do they spend extra money and delay the product
    announcement? If they do, then that affects sales. Unfortunately,
    that's how business practices are today. It's the push to market
    attitude: let's just get it out and then we'll go back and fix it
    later.
    
    But I guess it comes down to who do you blame for a Web-site
    defacement: the hacker who defaced it, the system administrator who
    didn't secure his box, or the software vendor because there was a bug
    in the OS program?
    
    We should really stop looking at trying to point fingers and just get
    the problem fixed.
    
    
    PCW: Isn't that what the hacking community is doing, though, laying
    blame on vendors when they publish a vulnerability announcement and
    deriding vendors for shoddy products?
    
    RFP: No, we're trying to get the bugs fixed. If the vendor is
    responsible and we can open up a communication channel, then we
    succeed at that.
    
    
    PCW: You sometimes work closely with Microsoft to help them find and
    fix holes in their products. What is your relationship with the
    company?
    
    RFP: When I find a vulnerability, I'll follow my policy with them. As
    long as they're receptive and keep communication open and keep me in
    loop, I'll work with them.
    
    
    PCW: When was the last time you found a bug in one of their products?
    
    RFP: That would be the Unicode bug which I found last December. They
    were immediately responsive. I mailed them at around 2 a.m. on a
    Friday night and got a response from them a couple of minutes
    later. They had a patch turned around in two days.
    
    
    PCW: Which other software vendors do you work with?
    
    RFP: A lot of smaller vendors which tend to be free software
    vendors. I really try to help them out on a personal level because
    it's typically a hobby product [of the maker]. Some of them are
    responsive and some of them aren't. I try to take the time to explain
    why they should be receptive and to explain the problem. Here are some
    patches that they should apply [to their product] and why.
    
    
    PCW: Are software vendors lazy when it comes to testing their
    products?
    
    RFP: They don't take the time to find problems. The historical record
    is great right now with information about vulnerabilities. And if a
    vendor, before making product xyz, would go to the historical security
    record and look at other products that are similar to xyz and see what
    bugs those products had and double-check to make sure that their
    product doesn't have them, I think a lot of the vulnerabilities would
    be reduced.
    
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.
    



    This archive was generated by hypermail 2b30 : Thu Oct 04 2001 - 03:02:27 PDT