Advisory advice

So let's say John Doe has found a critical vulnerability within X operating system.

John Doe informs the X developers about the hole, and X is patched. John Doe releases an advisory and proof of concept shortly after.

Acme Co. has a server on (unpatched) X operating system. Hacker Bob reads John Doe's advisory and uses the PoC to exploit Acme Co.'s server. Acme sues John Doe for releasing the advisory and code which was used to exploit their server.

What can John Doe do to protect himself, I'm wondering if it's possible to apply something like the GFDL or some other license to the advisory and software to prevent lawsuits or whatnot.

Any advice would be great, thanks!

ps any other tips or insights on the disclosure process would be helpful as well.

Quote:

---

Hacker Bob reads John Doe's advisory and uses the PoC to exploit Acme Co.'s server. Acme sues John Doe for releasing the advisory and code which was used to exploit their server.

---

From what I've seen general practise is to put a flaw into the program to prevent someone (kiddies) from using the code as is. General belief is that those that can find and fix the flaw would be able to do the code from scratch.

I suspect it'd be hard to prove that the POC was the true source for the exploitation. Additionally, I wonder how much the courts would say that it is the responsibility of the company to patch their systems if the patch was released.

Quote:

---

Additionally, I wonder how much the courts would say that it is the responsibility of the company to patch their systems if the patch was released.

---

I've always felt that releasing an advisory after a patch is the way to go, however I've been in situations before where the vendor doesn't respond or doesn't recognize the seriousness of an issue, in which case something has to be done. That's the scenario that requires some kind of protection.

Would a disclaimer work in this situation?

I see that alot on some of the tutorials for cracking and related topics, they'll add a disclaimer to the top or bottom of the page.. or have you read and accept something before you can look through said-document.

Hey Hey,

You've definately got a subject that warrants further discussion...

I think that PoC exploits have several responsibilities...

1) Pressure a company to release a patch/fix if they haven't already (It is good to give them time but like Soda said... sometimes you need to light a fire under them).

2) Demonstrates the necessity to install the patch/fix or apply a work around to Administrators of vulnerable machines... if they haven't already installed them.

3) Keeps geeks like us on our toes and gives us something to play with.

4) Gives the skiddies something to play with (if they're bright enough to figure out what's skewed in the code)...

Now a lot of you might think that 4 is a problem more than a responsibility that the PoC or any follow exploits may fulfill... but the occasional hack/crack job can be a wake up call for lazy administrators. If a patch has been out for 6 months and you still haven't bothered to install it... and you still haven't been fired for being inept... then sometimes walking in and finding one of your servers compromised may be the wake up call you need.

It's kind of like seatbelts... 40... 30 and even 20 years ago... so many fewer people wore seatbelts... even though they save lifes. It wasn't because they were any less intelligent than we are now... it's because accidents weren't as common and not as many lives were lost... It takes losing more lives to accidents to make people realize that seatbelts and airbags are needed.... sometimes it even takes losing someone close... to demonstrate how serious it is because people just don't realize...

The same thing happens with exploits and vulns and being compromised at work can provide the same wake up call to install patches that hearing your friend was thrown through the window of his truck at 30Mph because he wasn't wearing his seatbelt.

Anyways... a little off topic... but I believe it to be relevant... now back to the task at hand. Now MsM had the right idea with the skewing of code... it happens with a lot of the PoC, etc that's released... however they are usually quite simple to fix and I think even the skiddies have it down to a science.... I think the proper way (assuming the exploit is remote and this is only my opinion) is to code the exploit to only work against the loopback (127.0.0.1)... or against a single private subnet (192.168.1.0/24)... If someone wants to test with it... they can make the changes to setup an appropriate environment... You could also limit it to non-routable (private) addresses... but this could still be used internally on larger corporations... so it would depend on how gun-shy you are about what you release.

Anyways... there's 2 cents and then some for ya.

Peace,
HT

Hi Soda~

Quote:

---

I've been in situations before where the vendor doesn't respond or doesn't recognize the seriousness of an issue, in which case something has to be done. That's the scenario that requires some kind of protection.

---

You might like to check the CERT website and see what their policy is? I seem to recall they give the vendor 30 days then publish the vulnerability regardless.

I guess it falls under something like "fair comment in the public interest" A bit like discovering defects in domestic appliances or automobiles?

Cheers

Quote:

---

Now a lot of you might think that 4 is a problem more than a responsibility that the PoC or any follow exploits may fulfill... but the occasional hack/crack job can be a wake up call for lazy administrators. If a patch has been out for 6 months and you still haven't bothered to install it... and you still haven't been fired for being inept... then sometimes walking in and finding one of your servers compromised may be the wake up call you need.

---

Case in point: MS didn't patch their own SQL servers that were connected online when the Sapphire/Slammer worm went amok.

Quote:

---

I've always felt that releasing an advisory after a patch is the way to go, however I've been in situations before where the vendor doesn't respond or doesn't recognize the seriousness of an issue, in which case something has to be done.

---

Yup. That's actually happened here. Take a gander at Vorlin's little Red Hat find. To date, I believe, RH has never acknowledged this particular hole and believes that it isn't serious. I remember going through some of this with Vorlin and Vorlin waited a fairly long time before releasing this one out. Granted there's no real POC in the form of code, so to speak.

Does anyone know of an exploit finder who's been sued for releasing a patch? I don't think it's happened (yet?). And I think part of that is due to the debate, which I suspect is 50-50 in the industry as a split, of whether there should be full disclosure or not. Note that in France, IIRC, it's illegal to release code, something that K-OTik, IIRC.

Thanks for the comments HT, MsM, winds, and johnno

winds- Thats sort of what I'm looking for... is a publicly known and commonly used "disclaimer" or license of some sort similar to GPL or creative commons or w/e to use with advisories.
-------------

Quote:

---

Does anyone know of an exploit finder who's been sued for releasing a patch? I don't think it's happened (yet?). And I think part of that is due to the debate, which I suspect is 50-50 in the industry as a split, of whether there should be full disclosure or not. Note that in France, IIRC, it's illegal to release code, something that K-OTik, IIRC.

---

Similar, but I am having trouble finding the article. I'm trying to contact a prof who told us about this, here it is the best I can remember:

A teacher wrote exploit code for a old DB hole, and had the class use it for a lab. A student takes it out of class, and exploits a hospital DB that's exposed on the net. A patient dies in the ER from a lack of patient info and a deadly combo of medicine. The school and student are both sued and/or brought to some kind of justice.

Mind you this is the best I can remember, I'll get the article soon. IMO, the hospital is responsible for negligence.
-------------

This is how I've done it in the past-
1. Find vuln
2. Notify vendor

If the vendor responds, work with them, provide advisory and PoC exclusively. When a patch is being developed, I've been using Secunia for the advisory part. When the patch is released, release a detailed advisory. I personally don't release PoC code, because I believe if the advisory is detailed enough, you should be able to recognize the threat w/o code.

If the vendor doesn't respond, I contact Secunia and let them use their contacts to try and get the vendor's attention. And that won't always work either, and then they will release the advisory. By having Secunia publish first, it becomes public domain and the one that finds the vuln can't really be touched.

I personally believe that writing PoC code is crucial, it allows you to see how far you can go with a hole, however I personally don't believe that making it public is ethical. If the advisory and overview is strong enough, admins can make their changes.

BTW, Secunia gives the vendors a "short week" to make some kind of response back.

Quote:

---

A teacher wrote exploit code for a old DB hole, and had the class use it for a lab. A student takes it out of class, and exploits a hospital DB that's exposed on the net. A patient dies in the ER from a lack of patient info and a deadly combo of medicine. The school and student are both sued and/or brought to some kind of justice.

Mind you this is the best I can remember, I'll get the article soon. IMO, the hospital is responsible for negligence.

---

Ah. This is somewhat a different situation. The student in particular is responsible for negligent homicide. It isn't necessarily the fact that the student used the exploit but rather that his actions resulted in a death. That's a little different than just exploiting something. If someone knows which case this is so we can get the accurate details that would help.

This kind of result is why I was surprised the Sapphire/Slammer writer didn't get nailed for the 9-1-1 services that were hit and downed by the worm. The worm was written to show the importance of patching but resulted in causing two seperate 9-1-1 services to go down due to pure volume.

Quote:

---

I personally don't release PoC code, because I believe if the advisory is detailed enough, you should be able to recognize the threat w/o code.

---

What if the advisory isn't detailed enough? Releasing a detailed enough advisory will still lead to the creation of exploit code. So if someone creates said code, then goes and exploits something that results in the death of someone (say similar scenario as above) are not the vulnerability finder and the company still at fault for giving so many details? At what point do you draw the line?

Quote:

---

This is how I've done it in the past-
1. Find vuln
2. Notify vendor

---

AFAIK, that's how it's always done or how it should be done. The accepted practise is to send it to the vendor. If the vendor doesn't respond within a reasonable time, the question is now the responsibility to the community at large (that is, how risky is it if the community continues with this "hole"?). From what I've seen it's been acceptable to release the vulnerability if the company doesn't after 8-14 weeks. Remember, it's not the company's image that's important here but rather the security of the IT industry as a whole. If you find a major kernel flaw in Linux and the Kernel Development crew doesn't release a patch (a very unlikely scenario, IMO), then do you not have a responsibility to all Linux users/admins to help secure their systems?

Quote:

---

I personally believe that writing PoC code is crucial, it allows you to see how far you can go with a hole, however I personally don't believe that making it public is ethical ( emphasis added ). If the advisory and overview is strong enough, admins can make their changes.

---

Key word here is ethical. That would depend ...
Depend on response of author or organization that released the program ( for profit or not ):
1) Did they respond to you about the hole/vulnerability in a timely manner?
2) Were they responsive to your concerns?
3) Did they attempt to patch the code in a timely manner?
4) Did they announce the vulnerability in an appropriate manner?

As far as posting the actual PoC, I would take the advice here, manipulate it in such a way as the reader would have had to have the ability to find it in the first place to use the exploit. ( more on that later )

As far as the disclaimer; as implied here and in other posts on other topics, it will depend on the jurisdiction in which it is released, their laws, current moods of their courts, etc.

The only thing that comes to mind were the cases involving “DeCSSplus” . ( Google for it, there were many in the U.S. ( California ) and Norwegian courts, and much written about it.
At the very top of the readme.txt ( v1.0 ) was

Quote:

---

!! THIS PROGRAM IS FOR EDUCATIONAL PURPOSE ONLY !!
!! YOU ARE NOT ALLOWED TO MISUSE THIS PROGRAM TO COPY DVDS !!

---

I am not going to get into " Freedom of Speech" or " Freedom of the Press" issues here, but courts look at such things as “ what is reasonable and prudent”
Is it reasonable to only give the author 10 days to fix it? Or might 30 days be more reasonable ( if CERT , a recognized authority sets a time frame like this, would this not be “reasonable”, or at least defendable using CERT as a reference? )

Don’t get me wrong, I am not saying CERT is correct just because they are CERT . But I believe they understand something that the lay person ( say, someone on a jury ) would not easily:

1st) 10 days may not be enough for an author, who may be on vacation and unreachable for a week or two, and/or the new code needs extensive testing ( unless you want to grandstand )

2nd) If you found the exploit, hole, whatever, someone else has either already found it or will!

I the believe the later is the key to your question, what everyone here and in the computer security industry must agree to, for a PoC to be acceptable. ( and that goes back to covering yourself by manipulating the code so that only someone with the knowledge enough to find the exploit could reproduce it from your PoC. )

If everyone in the computer security industry agrees that it could have been discovered already, not disclosed, and currently or in the very near future exploited ( even though non-disclosed or the loss not calculable ) then any liability concerning releasing the Poc, especially within an industry accepted time frame should be negligible.


My example would be: What if you found a vulnerability, notified the author. That author released it under a GNU. They failed to respond. Six months later, a utility company’s systems crashed because someone exploited that same vulnerability. Five hundred people died because of that crash. How would you feel if you did not do everything that was “ reasonable and prudent” ?

Quote:

---

What if the advisory isn't detailed enough? Releasing a detailed enough advisory will still lead to the creation of exploit code. So if someone creates said code, then goes and exploits something that results in the death of someone (say similar scenario as above) are not the vulnerability finder and the company still at fault for giving so many details? At what point do you draw the line?

---

There are other correct ways to go through the disclosure process, I agree with most of them depending on the scenario.

Here's a tricky scenario: A vulnerability in a custom web application, such as websites at Bank One, retailers, forums...

A public PoC code won't help anyone, I think we can all agree on that. But what do you do if the vendor doesn't respond (with and without their attention)? If you release the same advisory to the public that you sent to the vendor, it's only valuable to people who want to attack the site.

Quote:

---

I think we can all agree on that. But what do you do if the vendor doesn't respond (with and without their attention)? If you release the same advisory to the public that you sent to the vendor, it's only valuable to people who want to attack the site.

---

Or valuable to a stockholder who wants to fire the crapheads running the business, or someone sensible who wants to cease doing business with lamers?

IT security has wider implications than the pure IT environment ;)

Good point.

Would others agree that advisories should be made public in this situation? I'm kinda changing my perspective on this, considering I'm in 2 of these situations now...

User's of a site would have to mitigate risk as well...