Talk About A Security Hole, Go To Jail?

Nu11.org writes "According to a SecurityFocus article, 'Federal prosecutors in California went too far when they put a man in prison for disclosing a website security hole to the people at risk from it.'" According to the article, "...by explaining how the vulnerability worked, and why customer data was at risk, prosecutors asserted, the security specialist 'impaired the integrity' of the affected network", citing the case of Bret McDanel and his former employer, Tornado Development, Inc. We've discussed the disclosure of software exploits recently.

Comments

Re:I've figured this sort of thing would happen

[legLess]

Not to pull a wet blanket over your martyr story (and not to slam Randal, 'cause I don't want to get punched at the next Perl Mongers meeting), but you're leaving out some important details:

• Intel caught him and told him to stop. He continued.
• He actually used some of the passwords to login, although he didn't change or grab any data.
• None of this was directy related to performance of his duties as a contractor.

I think Intel was merciful the first time, cause they could have nailed him then. The end result is awfully harsh and all out-of-proportion to the harm caused, however he was by his own admission doing something illegal that he'd been warned not to do.

This case is similar. Yes, the prison sentence is crazy for the crime, however what this guy did was stupid. He was clearly going after the reputation of his former employer: if he'd been motivated only by the good of the customer, he would have sent the email while on the job. Also, he could have just warned folks without publishing exploit details.

This is a problem many geeks have -- getting nailed for doing something technically correct but socially unnacceptable. Most of the rules that run the world aren't written down and never will be. You can be technically correct and still wrong wrong wrong.

Timeline of Events by Tornado Employee

[Anonymous Coward]

Jan 12, 2000 Customer support at Tornado gets an email from an exempoyee saying there is a HTTP REFERER problem in their product (along with 15 other webmail providers hotmail included).

Jan 13, 2000 Development has written a fix and tested the fix (cgi redirect and code to cause all urls in the email to go through this redirect, nothing big).

Feb 1, 2000 McDanel quit (gave 2 weeks notice) because of problems with managment dealing with another employee.

Aug 24, 2000 McDanel contacts customer support (he is friends with this person) and asks if the problem is ever going to get fixed (McDanel was allowed to keep his account free after quitting, which shows that he didnt leave on horrible terms, and maintained friendships with many people in the company, infact some people in the company tossed work to his fiancees company).

Aug 27, 2000 McDanel was told no they were not going to fix the problem (unknown at that time was that the QA person closed this bug report months ago without applying the fix).

Aug 30, 2000 email from one of the managers at Tornado to McDanel regarding his web page

Aug 31, 2000 McDanel sent emails to the customers at the rate of 6.67/sec (10 rcpt's per body (so the body is effectivly 10% the size) delay 1.5 seconds between each body). The system logs showed NO impairment during this time.

Later the system was shut down (sendmail, web server, etc) *then* the system load went up (resumably when they were deleting the emails, which in itself is a crime).

McDanel was on the phone with admins just prior to sending and continued talking to one admin for 20 minutes, then called others and helped this company fix their system when it broke (turns out it broke cause they were deleting the emails, but none the less McDanel did whatever he could to try to help them, including spending several hours on the phone with them the night the emails were being sent).

In every instance that he sent emails (6.67/sec to a 8 cpu UE 4500 with a gig of ram, that in no way is a DoS) there was no downtime, the xdelay in the mail headers was 1 second or less, it was not suffering at all. The queue stayed below 30 mails most of the time (once for less than 1 minute it went over 30 mails but it quickly processed that and the queue was below 30 again).

Sendmail (which they used) will automatically queue the emails if the load is too high. The mere fact that the queue was empty (or nearly so they do not log if there is less than 30 in the queue) indicates that the system was not overloaded.

The fact that the cpu load reports (HP Openview) indicated that the load did not go up until AFTER services were shut down (if you kill sendmail, sendmail cannot cause load - period!) also shows that it was not a DoS.

What is worse is that McDanel was charged under the 1998 version of 18 USC 1030. The new version (patriot act) makes it tons easier for them to convict you. If you attempt to impair the integrity and are unsuccessful, you can still be guilty (before you actually had to do something, now you just have to attempt/intend to do it, and presumption of intent is easy for them to prove, they just have to say it).