About the Author

Chris Shiflett

Hi, I'm Chris, a web developer and a founding member of Analog. I live and work in Brooklyn, NY.

Reporting Vulnerabilities

Ed Finkler (of CERIAS) just pointed me to a blog post made by one of his colleagues about reporting vulnerabilities.

The post discusses the risks associated with reporting vulnerabilities, and the conclusions drawn are disappointing but understandable. It's worth a read, and it relates slightly to a discussion Paul Jones and I had last year.

I've seen my share of irresponsible disclosure (and publicity), but it's sad that a basic risk analysis dissuades well-intentioned people from doing the right thing.

Note: You can Digg it.

About This Post

Reporting Vulnerabilities was posted on Tue, 23 May 2006 at 14:09:47 GMT.

10 Comments

1. Nate Klaiber's GravatarNate Klaiber said:

As a personal preference, if you find a bug in something I have built - I would like to know. I will then evaluate and fix and make any necessary changes. I feel that it should be done privately, with an email to the administrator or the like.

I do, however, understand the concerns expressed in the article. Its about watching your own back - for the administrators that would like to bring you down or make you suspect to something else that happened on the system. It depends on the type of administrator. An arrogant one would definitely try and defend their system and blame the intruder.

The problem is when the finger gets pointed to the one that pointed out the problem. In fact, it could get worse if there were other problems on the system and they blamed the person who pointed out the problem.

So - If it is a friend's site, I would tell them. If it was someone else I do not know - I may be silent to protect myself.

Interesting post.....

Tue, 23 May 2006 at 14:56:33 GMT Link

2. Chris Shiflett's GravatarChris Shiflett said:

In my opinion, when I discover a vulnerability in a site that I visit, I have a responsibility to report it. I've done this with Digg, Amazon, etc.

The problem that inevitably arises is that the contact does not take your report seriously. For example, with Amazon, my example exploit is harmless. I simply wanted to demonstrate the vulnerability without causing unnecessary alarm or suspicion. I think the danger is clear, but more than three months later, Amazon is still vulnerable.

I have a few options:

1. Take the "it's not my problem" stance and let the vulnerability persist.

2. Continue to bug Amazon incessantly.

3. Exploit Amazon's one-click feature in an attempt to make the danger clear.

4. Make the exploit public in an attempt to motivate Amazon to fix it.

So far, I'm hovering on option 2. Options 3 and 4 increase my personal risk to a level I'm uncomfortable with.

What would you do? :-)

Tue, 23 May 2006 at 15:11:35 GMT Link

3. Peter's GravatarPeter said:

To report a bug or exploit, it is firstly important to do it as anonymously as possible. Use an anonymous mailer or something like that.

Secondly, there is no need to bug someone like Amazon repeatedly to fix a simple bug in their system. It's their site and you can't force them to fix it.

With the comment above, particularly with point 3, you are risking personal litigation if you follow that route for something you describe as 'harmless'. I'm not sure what your personal motivation is, maybe to tell your friends "I fixed a bug on Amazon.com!", but personally I think you have done more than enough and should just let it go.

Tue, 23 May 2006 at 16:42:30 GMT Link

4. Chris Shiflett's GravatarChris Shiflett said:

Peter, I agree with your risk assessment.

My motivation to get Amazon to fix the vulnerability is just that I would prefer to have it fixed, because I feel confident that it will be discovered eventually, putting me (an Amazon user) at risk.

Tue, 23 May 2006 at 16:52:10 GMT Link

5. Aaron's GravatarAaron said:

5. Stop using the vulnerable system

Tue, 23 May 2006 at 18:00:46 GMT Link

6. Chris Shiflett's GravatarChris Shiflett said:

Heh. :-) That's definitely a valid option for a lot of people, Aaron. Perhaps it's really part of option 1, though?

I think the issue Pascal Meunier is trying to raise is that it can be difficult to determine whether an action is malicious, because the difference depends more upon intent than the action itself, and that's subjective. Thus, it's safest to keep quiet.

Is there a way to not keep quiet without exposing yourself to much risk?

Tue, 23 May 2006 at 18:16:35 GMT Link

7. Chris Shiflett's GravatarChris Shiflett said:

Here's a link from CERT that's helpful:

http://www.cert.org/reporting/vulnerability_form.txt

They also list their disclosure policy:

http://www.cert.org/kb/vul_disclosure.html

Tue, 23 May 2006 at 18:29:20 GMT Link

8. Ilia Alshanetsky's GravatarIlia Alshanetsky said:

I think when it comes to bug reporting, be it security or otherwise, you (as a developer) need to be careful not to put too many bariers to entry. Most people already fail to report bugs, by making it tough on the small percentage that does, especially tricky ones involving security, you risk alienating the few who do.

In my personal opion it is often better to have a red faced developer (or Company) rather then an unplugged security hole that is being actively abused by so called "blackhats". In my experience people often find every execuse to NOT fix security holes, until they get burnt badly, once or twice. After that they get on with the program so to speak, and if this process takes an occasional full disclosure, so be it.

In many cases people publish unfixed exploits because the vendor refuses to fix it or deploy a solution in a timely manner. So, the person who discovered the exploit publish in an attempt to accelerate fix deployment and warn users of the possible issue so that they can put intermediate workarounds.

Wed, 24 May 2006 at 02:53:18 GMT Link

9. Peter Pistorius's GravatarPeter Pistorius said:

I found a bunch of exploits on local university and business websites.

I phoned them up and let them know. A lot of the time you can find the person in charge of the website(s) by searching the website or asking the receptionist.

Once a guy asked me for my name and I just gave him a fake one... He appreciated me calling him but I wasn't going to take the risk.

Wed, 24 May 2006 at 16:58:12 GMT Link

10. tedd's Gravatartedd said:

My experience at telling anyone to correct anything is at best problematic and seldom received as intended.

My advice is to realize that money drives the incentive to change, unless they are hit in the pocketbook, they won't listen.

So, either leave them alone, get on with your life, and allow them to experience the problem financially by some hacker OR make a name for yourself. Choose your actions wisely.

tedd

Thu, 03 Aug 2006 at 14:29:44 GMT Link

Post A Comment

Personal Details and Comment

Style Guide

Line breaks are converted to paragraphs. Also use:

  • <a href="" title="">text</a>1
  • <em>text</em>
  • <blockquote><p>text</p></blockquote>
  • <code>2  <?php  if ($foo) {      $foo = TRUE;  }  ?></code>
  1. Note: <code> can be used inline (e.g. in paragraphs) or in a block as shown. Include whitespace and newlines in blocks.

Please enter Chris (my first name) below. This is a primitive spam prevention technique, and I apologize for the inconvenience.

Preview and Submit

Upcoming Talks

ConFoo

10 - 12 Mar 2010

At Hilton Montréal Bonaventure, Montréal, Canada.

South by Southwest

12 - 16 Mar 2010

At Austin Convention Center, Austin, Texas.

Dutch PHP Conference

10 - 12 Jun 2010

At TBD, Amsterdam, Netherlands.

O'Reilly Open Source Convention

19 - 23 Jul 2010

At Oregon Convention Center, Portland, Oregon.

New Comments

Niall Kelly wrote:

Having tried other methods without success and looked through plenty of bloated documentation, th...

Posted in Git on Snow Leopard
liukang wrote:

I have problem with this example. In my php.ini magic_quotes_gpc is off so i'm using only addsla...

Posted in addslashes() Versus mysql_real_escape_string()
RyanTheGreat wrote:

Well, I'm not Chris, but I will do my best to address the questions raised in the comments by Ian...

Posted in Security Corner: Cross-Site Request Forgeries
Chris Shiflett wrote:

Thanks for the kind words, Simon. I'm glad you liked the tutorial. In case it's helpful, here'...

Posted in Webstock
Chris Shiflett wrote:

Hi Robin, I plan to post something about it, but it's going to be hard to express everything i...

Posted in Webstock

Browse Comments

Work and Books

Analog Essential PHP Security HTTP Developer's Handbook