Oregon Supreme Court Declines To Hear Schwartz Case
merlyn writes "The Oregon Supreme Court declined to hear my case, leaving standing the unfavorable decision of the Oregon Appeals Court as the final authority on this eight-year-long case, well known to many
sysadmin and Perl hacker alike. Details at my fors-announce posting." If you're not sure what that means, you probably want to read at least this site which offers a straightforwardly partisan look at the complicated case of Intel vs. Schwartz as well as Schwartz's own page; it's a strange world where programmers and sysadmins can be convicted for seemingly innocent activities.
...cracking passwords an innocent activity?
You know... most everyone I know who has followed the case seems to agree that the only reason you got in trouble to begin with was because of your inability (some call it emotional ignorance) to communicate properly with the admins within Intel.
Still, all in all, I believe you've managed to do well for yourself. Written a couple of books, entrenched in the perl community, regular magazine article contributer, etc. You should feel lucky that you did not do any time in "pound you in the ass" Club Fed. You *should not* feel that somehow it's your god given right to have this little blight on your history removed (and to be honest, do you know *anyone* of any note or repute that doesn't have a bit of netorious past?).
So, just get over it, continue to pay off your legal bills (and that's really that this appeal is about, right?) and get on with your life.
Ok, so in Oregon it is a crime to "unlawfully, knowingly and without authorization alter a computer and computer network." The obvious solution here (for people working on computer networks in Oregon) is to obtain written permission from the appropriate authorities before altering a computer and/or computer network. Print up forms with the full text of the appropriate laws and give them to the appropriate people. Whenever you need to do anything, request permission in writing. If they complain, have them provide authorization in writing for performing specific common tasks at the discretion of the individual, but keep requiring written authorization for anything else. If the law really is as broad as it is being described, there is too great a risk of prosecution to do otherwise, especially if you deal with security testing. Either get permission or don't do it - there's no sense putting yourself at risk to do something that the network's owner probably won't care about anyway.
Sounds like a bad legal decision and it reflects poorly on Intel. But one thing to keep in mind: workplaces are all about politics. People who play their cards right seem to be able to get away with murder. People who hack and don't shmooze, on the other hand, are very vulnerable. If you are of the latter persuasion, do things completely by the book and get permission for anything even remotely out of the ordinary in writing.
Unless specificly authorized in his capacity as a consultant he never should have touched the password file.
As a consultant you may be in the situation, on a daily basis, that you have access to information which is not yours to do anything with. Thats the nature of the beast, don't screw with it.
As a consultant I have access to data on the customers of my clients. That data is confidential. Unless specificly using the data for testing I have zero right to that data. Even if it is in the database I have access to, and available to me based on my access privledges.
Having access to data doesn't mean you have the right to that data.
There's a good summary at the SANS Institute site. Schwartz did three different things: (1) installed a backdoor in a firewall, (2) did an unauthorized password scan, and (3) used one of the passwords he obtained through this scan to log into a system to which he should have had no access. He then copied the /etc/passwd file off that last machine, apparently to run an attack against it, as well.
Even a cursory review of the documents in the case make it clear that he wasn't framed, that he actually did the things he was charged with, and that at least one of the activities with which he was charged was not only unauthorized, but had been explicitly forbidden by his managers. He had been ordered to take his gateway down at one point. He did so, waited a few days, and then brought an equivalent service up on the same machine under a different name. (See this site for some more details.)
In my opinion, what he did was certainly grounds for dismissal, and almost certainly technically criminal. That said, I think the district attorney was unwise to pursue the case against Schwartz, since the damage done to his reputation just on the basis of what is clearly the case would have been punishment enough. Even without the convictions, no major site will ever touch him again: security geeks are dangerous, and the last one you need is one that won't obey the policies about what he or she may attack at any given time.
For years now we have been reading comments about What Randal Should Have Done.
It's easy to be critical from a distance. But before you're too smug in your assessment, walk a mile in his shoes, or in today's terms, sit for an hour at Randal's shell prompt. Many of us do every single day.
Randal was doing pretty much what many sysadmins do as an ordinary matter of course: secure and protect the systems they are responsible for. It's the job they're hired for, you know?
I've always felt that this amounted to a personality clash that spun out of control, bruised the ego of an Intel senior PHB, and then completely escaped from reality when it was referred as a criminal matter to the local gendarmerie.
Unless you live in or next to Washington County, Oregon, as I do, it may be hard to understand the pressure that develops when the local cops get a call from the largest employer in your area and the most powerful company in the state.
I remind everyone here that Randal was an Intel contractor with a one-line contract that basically ended up being interpreted in a completely arbitrary way.
Randal would be the first to say he did some things that weren't wise, but there was never any intent of illegality or damage to his client, the mighty Intel Corporation.
Intel has rightly gotten a big old black eye over this entire episode, at least among those who bother to learn the details, and at least as far as I know has not repeated this stupidity.
Randal has managed to keep going, dealing with an onerous legal case, the threat of jail, an extraordinarily out of whack fine, and daunting legal costs.
The Oregon law that all this hooked on is widely regarded as badly written and prone to misuse (I've written some Oregon law in my time, not in this particular area, and it's easy to see how this happens in the legislative process).
The gross sense of disproportion is the lesson I have learned from this sorry episode. It is sobering for any of us who take on sysadmin duties under any circumstances. As security becomes an ever more complex and consequential issue, that is a lesson everyone should take seriously. Just because you are doing the best you can, all of us have our flaws. What protection do you have if someone decides to settle a grudge with you and have the full weight of an ill-defined law and an immensely powerful legal apparatus thrown on you?
Good luck to Randal. He handled this with a lot more diplomacy and good cheer than many of us would probably have mustered.
--------
Bill Gates Is My Evil Twin.
This case ended exactly as it should have