The trouble is that he was not mandated to do it, and it is not obvious that he had the leeway to do it. This gives him no ass-covering material. There's no piece of paper that unambiguously says he was permitted to do what he did. He can only argue about vague general principles.
I actually think the "vague general principals" are surprisingly supportive of the RC5 client, as I laid out in my second point. Here's a document that explicitly states what he can and cannot do, and he quite oddly follows it well.
I mean, seriously. There's alot of mileage to be gotten out of the fact that this document:
1) Says sysadmins are effectively autonomous
2) Lays out restrictions that are almost entirely followed to the letter(including WRT CPU usage).
Sigwinch, read the supporting documentation I provided earlier. Those are their policies. His actions are not even clearly a violation of them!
Never take a risky action in a corporation without considering how it will sound in front of a Federal jury or Congressional committee. "So, Mr. McOwen, are you're telling us that you were converting these computers to your own use to win a $1000 prize?"
http://www.theonion.com/onion3723/nobel_fever.ht ml
:-)
Seriously though, the Nobel Prize is a much richer purse than RC5 will ever have; you don't see people being hauled off to jail for discovering the top quark!
To a jury of bums, rednecks, and career Taco Bell cooks, that $1000 prize will be damning. Ditto for newspapers and blood-n-depravity TV news shows.
Americans love two things:
1) Seeing criminals shot down by the public.
2) Seeing Goliath shot down by David.
The problem with McOwen is that it transcends the criminal-citizen barrier: Quite a few of us could imagine doing something unique and productive at work that some bureaucrat might not agree with. This self-identification means that the criminal prosecution becomes a personal threat that we'll pay (through advertising dollars) to watch allieviated.
"Piss your boss off, go to jail." The hacker/citizen barrier is *nothing* against this.
So? The humorless gentlemen in the dark polished cars, wearing nice suits and ray ban sunglasses don't give a flying fuck that the situation is bad. All they care about is the documentary evidence that *you* made it measureably worse.
Consider the opposite situation--suppose McOwen was in a tightly controlled secure environment, with all software change controlled and all decisions made through three levels of bureaucracy. Clearly McOwen would be much worse off -- not only would he be obviously and knowingly violating the decision making policies of his organization, but he'd be doing so in a manner in stark contrast to standard operating procedure.
He'd be screwed.
But that's not how it went. There was no strong top down organizational structure; it was all UGA could do to keep their sysadmins from maliciously harassing users! There was no "line in the sand" that McOwen crossed; his job was to maximizing the value of university computing resources and he did so. If he added minutely to system insecurity, the fact that he was hired to do things in an insecure manner(telnet blah) is at least a strongly mitigating factor.
Security is a process, as Bruce says. With little process in place, there was little for him to violate.
You do if you're a career state-employed academic bureaucrat. Any one of 'career', 'state-employed', 'academic', or 'bureaucrat' would be bad news. Put them all together and it's a deadly situation. The person carrying out this campaign against McOwen is certainly clueless, likely vindictive, likely monomaniacal, and *committed*. Once a person like that starts a campaign, they'll push it as far as possible. They won't know when to give up.
Couldn't have said it better myself--this is where my reluctance to entirely blame the prosecuter's office comes from.
It would arguably have been better to continue with 40-bit DES, and let the electronic pearl harbor force Congress to clean house at the NSA.
An interesting historical what-if. An electronic Pearl Harbor would plant a pernicious seed of doubt in the validity of all electronic records though, significantly destabilizing our entire system of indentured servitude / credit card debt. Given the personal profitability of being able to legitimately challenge the veracity of your entire debt history, I'm unconvinced any quality of crypto would ever be able to save an economy thrown into a tailspin by an EPH.
"Cracking DES" had the best possible effect, I think: It destroyed political opposition while leaving public trust unsullied.
Offtopic, but... WEP is an impressive accomplishment. They actually managed to design a cryptosystem that has cipher- and key-exchange-independent insecurity (the 24-bit initialization vector).
My favorite independent vulnerability right now involved keystroke password analysis in SSH1. Effectively, you monitor the timing variations between characters in a user's password as they're sent on the network and use hidden markov chains to determine the most likely keys that are being entered. It turns out that we take longer to transition between certain keys than certain other keys, and this transition distance can be indepedently analyzed.
If they really did just make up this numbers, the case could blow up in their faces.
Well, I made up the numbers WRT $200,000/yearly for a single T1--the difference is I was showing ballpark figures, whereas they're seeking felony conviction.
Big difference:-)
During the day, the truck is *HIS*. He can pick his own routes, make a detour for a customer who is in a huge hurry, bend the traffic regulations, and generally do whatever it takes to get the job done. He job is a big one, and he therefore has a lot of leeway to make autonomous decisions. Suppose he wants to take the truck home at the end of the day to move a sofa. If he takes 10 seconds to get the boss's permission, taking the truck is perfectly OK.
Bad example--the equivalent circumstance is McOwen physically transporting the servers to his home to run some work for him there. You can't get around that -- you mention grand theft later; the reason it's grand theft is because the trucks were supposed to be there but instead disappeared!
It's not arguable that the movement of the sofa is at all within the mission of the trucking company; however it is extremely arguable that academic research and collaborative mathematical analysis is directly within the mission of a university. It does not matter if you would have made the same choice; you merely need to accept that it was a reasonable conclusion to reach for this to be an issue of internal policy disagreement and nothing more.
If it's your job to use them that way, you just do it. However, if there is a person who could say no, and you don't ask, you have done something wrong.
I'm reminded of the history of the HP Deskjet; which was fought tooth and nail by the laser printer heirarchy at HP.:-)
There's *always* a person who could say no to something. The question is whether the general consensus is that something is not to be done -- no human organization can operate unanimously; it creates too many absolutes of power. Mr. McOwen may have known some might have disagreed with his use of the software, but there's always someone who disagrees. The question is: Who else knew of his actions, who else approved, and how does legitimate access to company hardware turn into the equivalent of a foreign hacker maliciously breaking in and subverting computer resources?
In a criminal case it is not necessary to prove substantial monetary damages, it is merely necessary to prove that the person did something they had not been given permission to do.
"Did you have passwords to these machines?"
"Yes."
"Did you steal them?"
"No."
"Who gave them to you?"
"My employer."
"To do what with?"
"Configure the machines."
"How so?"
"In a manner that maximized their usefulness."
"Any specifics?"
"Just what's in the guide."
"Did you violate the restrictions in the guide?"
"No."
If you allow fear to govern your actions, you are letting the enemy dictate your actions.
At the point of criminal prosecution, your hope for a peaceful ending (unless you wish to plea) is over.
It's funny, but I am also being serious. The Internet search engines are already starting to correlate information with specific people.
Thus why I've told a couple girls to never do porn. We're only a scant few years away from large scale eigenvector based face searches through large image databases, and the code is almost certainly going be trained against porn--there's no larger source of stock human photography!
The prosecutor is actually a good point of approach, if you can get him in touch with a clueful expert.
A guy can hope:-)
Anyway, I understand what you're saying
Ditto.
I just think it's McOwen's fault for not establishing a paper trail showing permission.
My hope is that McOwen saved a few emails from coworkers higher than him expressing approval for the project...
"The Young Male Sysadmin's Guide To Not Going To Prison"
I feel like I'm looking at the title of one of those "World's Thinnest Books". Of course, considering the state of the economy, a chapter on how to successfully steal bread so you don't starve to death might be useful...
You hire me to pick stocks. I pick bad stocks -- you fire me.
I didn't steal from you.
I didn't intentionally seek to defraud your company.
I didn't hide the stocks I purchased.
I was more aggressive than normal, but not unusually so.
I simply bought the wrong stocks, and got canned for it.
Should I go to prison for losing you money?
Now imagine I didn't actually even lose you anything -- you were merely concerned that at some point in the future, the stocks I picked might possibly expose the company negatively.
Should I have even been fired?
Possibly--but possibly not. If it's not even obvious if I should be fired, how could it be obvious that I should be imprisoned?
For the support of the organization, not for his own personal amusement, and most assuredly *not* for an effort to win him a prize.
It is my contention that his personal goals and the mission of his company were not in conflict, and furthermore the odds of him actually winning the prize, remote enough(even with whatever rank he managed to achieve), the prize small enough, and the actual distribution of that profit distributed enough that for all intents and purposes the value of that prize goes to zero.
In terms of the prize itself, his probabilistic share probably didn't add up to the price of a can of Mountain Dew. That's a Red Herring and you know it.
That a university is publicly oriented does not give its employees license to do whatever they think is in the public interest. A university is a corporation, just like any other, and the use of its resources must be approved by management.
First of all, you're wrong. A university is not a standard corporation any more than a political party is, particularly not a university established as a branch of the government! The explicitly avowed dedication to academic freedom means a hell of alot.
Second, I haven't seen a single shred of evidence to state that he himself didn't have the discretionary authority to decide to run this software. Administrators were exhorted to behave in a manner compatible with the values of the university; as I noted, the RC5 system was extraordinarily compatible with the values as they were laid down, down to relinquishing CPU upon request.
In fact, if one examines the documents linked in the previous post in depth, one finds an extraordinary amount of power given to system administrators -- so much, in fact, that "management" sees the need to specifically warn administrators not to be overly or overtly malicious towards students. This seems to me an implication that sysadmins had an extraordinary amount of autonomy over the systems they deployed.
Whether or not you feel this is a good thing for management or even a professional thing for Mr. McOwen, the implication that the systems were under his discretionary control is quite clearly there.
He wasn't a consultant, sigwinch. He was one of the operators.
Incidentally -- these machines were going for some time, with no complaints being rendered for quite some time. This means a couple things:
1) Other admins who noticed either approved, yielded to McOwen's discretionary authority, or were able to remove it themselves. Any way you slice it, the time he was granted helps, not hurts his position. (By contrast, a genuine attack usually *hurts* a network, causing reasonably quick corrections.)
2) Management either approved, or itself issued little low-level discretionary authority. In other words, management ordered the sysadmins to keep things running. If the sysadmins extracted more value from the sunk costs, and it was (reasonably) within the mission of the university -- so be it.
Unreviewed, untested, warranty-less binaries that engage in continuous communication with remote servers are a serious security threat, as well as a threat to the integrity of the machines.
Yeah, welcome to Winamp, Windows Media Player, RealPlayer, Yahoo Messenger, and Windows itself.
Give be a break. The majority of university networks are so riddled with out of date daemons and unfirewalled ports it's ludicrous to suggest a single daemon with no known polling vulnerabilities is going to outweigh it. (By contrast, simply spoofing Winamp's update page is enough to destroy it.)
And what the fuck does that have to do with this discussion? The question is whether he had permission, not whether he would have had a good justification if he had asked for permission.
The question is if he had to ask. My point is that the burden is on the university to show he actually did need to ask, because he was clearly acting within the bounds laid out in the rules the school made public in a position that demands a large amount of autonomy.
Remember, that you would have made a different choice is irrelevant; the question is whether he had the right to make such a choice. In my mind, the fact that so much time passed between his use of university resources and his eventual shutdown means that quite a few people knew of this incident and one person elected to express discretionary priveledge and can him. That's fine--it happens--but you don't send someone to jail for it.
And even if that was our discussion, brute-force cracking RC5 is a stunt. It doesn't do a damn thing for security.
Silly. You have no idea how much Cracking DES did, do you? Do you have any idea how significant the EFF's DES Cracking book was in making sure AES happened, and in forcing 3DES to be the standard of the day?
Do you understand how recent it was that the federal government was saying it would take a foreign government inordinate and unrealistic amounts of time and money to crack even one DES key?
Do you realize how many algorithms, *today*, still depend on 40 bit RC4? Most SSL sites -- that travesty that is 802.11 WEP -- the garbage is everywhere.
Are you an idiot? Do you know nothing about computers?
Ask this again two weeks from now.
Diligent recovery from this compromise would involve...
a lot of things that didn't happen. At all. Even in the slightest.
You can't charge for damages that didn't occur. It's like filing a suit for your own wrongful death because somebody coughed next to you and they might have had TB--first of all, you ain't dead, second of all, they didn't have it!
Competent professionals help the client accomplish their mission. If they have ideas for new mission objectives, or even for cool charitable projects that don't really accomplish much, they discuss it with the boss. They *don't* run off and reconfigure hundreds of pieces of high tech equipment for their own whimsy.
I claim this did help with the mission, and that it was reasonable for McOwen to believe this was within his assigned powers. If his interpretation was at odds with that of the administration, perhaps he deserved to lose his job -- but this doesn't even pass the giggle test for felony hacking. They were HIS BOXES. He had a legitimate accounts, probably even root accounts and did things that were *arguably* legitimate.
Sysadmins *never* have the right to turn hundreds of the institution's machines into zombies for their own pet projects.
Oddly enough, who do you go to if you have a project that could really use a few hundred machines? You go to management, they look at you funny and tell you to go to the guru to decide whether or not to do it.
In most places with vast amounts of computing resources, there's usually a sysadmin at the top of the pile choosing what goes where--and if there's nobody on top of everything, like there aren't at most understaffed universities, everyone who has legitimate acccess is expected to legitimately use it--however they see fit, as long as they follow the rules.
Hardly. It's vandalism, plain and simple. The alterations he performed obviously had no relevance to the organization's mission, they had a potential serious deleterious impact on the mission, and he deliberately chose not to ask permission when doing so would have required little time or effort.
I provided extensive documentation showing the compatibility of this project to the university mission. I don't need to show it's absolutely correct -- merely that it's plausible.
Whatever deleterious effect you mention *didn't happen*, and as far as I can tell hasn't *ever* happened. Complete lack of precedent for a deleterious effect has an effect in a courtroom, you know.
The law is the least of his problems. Not only did he recklessly fuck over hundreds of his client's machines, he whined about the client's consternation on the Internet.
If the prospect of a decade of prison rape wouldn't make you run screaming like a horror movie prom queen into whatever abandoned warehouse of an online forum you could find -- you're a stronger man than I.
For the rest of his life, any time a prospective employer does a web search on him this story will show up in all its tawdry glory.
Oh, this is much better than a felony conviction. It don't say, "Have you ever been mentioned on Slashdot" on the employment forms, you know:-)
I propose a new phrase for the Internet lexicon: "Pulling a David McOwen". It will be the Darwin Award of Career Limiting Moves.
Heh. Doctors play God, admins play BOFH. Both make mistakes, but the latter almost never kills anyone. Strip root, maybe. Strip down, though? For "hacking" his own machines?
He ran rc5, not rm -rf. He used computers to compute, not to destroy. He yielded processor when needed, rather than hog it to the exclusion of all others.
Felony hacking my ass, and *everybody* knows it.
I do feel for the prosecutor, though. I don't think he realizes how badly he's being used.
> Reprimanded, shreprimanded. It should achieve their own felony prosecution.
I'd be more than happy with a simple reprimand. It's a matter of fairness after all -- we think the charges against Mr. McOwen are excessive; it would behoove us not to levy similar charges against the prosecuter's office.
In both circumstances, there are quite a few others who are much more deserving of investigation.
I am not a lawyer. I may once have thought to become one, but I have since been a technologist and a cryptographer. But I do not appreciate what Mr. McOwen is being accused of, and here are my thoughts on the matter:
====
To state that this case deserves to get thrown out of court -- with the prosecuting attorneys being reprimanded for falsifying financial figures to achieve a felony prosecution -- is not only a reasonable statement, it's possibly an obvious one. I have five arguments from which I draw these conclusions:
First, Mr. McOwen's terms of employment were easily open ended enough to consider this a valid use of network resources.
Second, University policy clearly granted Mr. McOwen permission to administer the machines as he saw fit, as long as he did so "fairly and in accordance with University policy."
Third, Mr. McOwen was acting in due diligence against billions of dollars in yearly national liability from a weak computer security environment.
Fourth, the Prosecution's numbers cannot be justified in any way, shape, or form.
Fifth, the very prosecution of this case creates a grave chilling effect against the ability for computer administrators to successfully maintain the systems they are charged with.
1) The exact job specifications of Mr. McOwen's employment were not and literally could not be set in stone; his basic task was to administer the systems according to the precepts of the site they were deployed. In this case, the site was an educational institution. Educational institutions, as opposed to even corporate workplaces, exist as nodes of "basic research" and "collaborative and non-profit volunteerism". Surely, it is not inconcievable that given the extraordinarily high degree of public works that universities are known for, that he might have come to the reasonable conclusion that installation of software that contributed to a public good (the global improvement of cryptographic quality) would be a fair extension of the mission of the university.
2) The University of Georgia's computer security policies, available at http://www.uga.edu/compsec/summary.html , clearly give Mr. McOwen wide latitude to administer systems however he saw fit. It states, "Those who administer computers and network facilities shall perform their duties fairly, in accordance with University policies." As this is the primary document describing University policies with respect to computer security, it stands by itself as a sufficient source of guidance for Mr. McOwen. Users are admonished that they "...shall take full responsibility for messages that they transmit through the University's computers and network facilities"; such responsibility refers specifically to "fraud, harassment, obscenity, and the like." Surely the analysis of simple numbers does not rise to the level of obscenity! There are admonitions against Trojan Horses and computer virii, yet both tools exist to procure access where none existed before--Mr. McOwen was granted his access legitimately. Indeed, the university specifically defines Trojan Horses in a detailed guide available at available at http://www.uga.edu/compsec/use.html : "A Trojan horse is a program with a hidden, destructive function, or a program designed to trick users into revealing confidential information such as passwords." There was nothing hidden about the RC5 code, and as for destructiveness, few would argue it is destructive to a computer to ask it to compute! Though there is a mention against "cracking", it is specifically in reference to the cracking of computers--Mr. McOwen was analyzing a code specifically authorized and designed to be analyzed. Even if he had been running a genuine system cracking utility, the detailed rules specifically authorize system administrators to do so. Mr. McOwen even actively complied with the requirement to give higher priority to users with more important work by running software that immediately yielded resources requested to any other software that requested them. Given the degree to which Mr. McOwen explicitly complied with university regulations, it is difficult to see the validity of this case.
3) Statistics have shown a multi billion dollar a year loss to the country from insufficient encryption and computer security systems. Such damage is often either concentrated or traced from machines with inadequate network security. University machines, almost always under-administered and very often forced to be publically accessable due to the academic requirements of students (one could not expect a place of higher learning to be as firewalled as the FBI!), often either directly experience financial damage or indirectly contribute to theoretical litigation expenses from being used as "jumping off points" for larger attacks. By contributing to the global awareness of the dangers of insufficient security, David expressed a degree of "due diligence" towards solving a problem the university was contributing to. Such due diligence constitutes a legitimate usage of system resources as a mitigating factor in any future litigation, much as active and genuine safety research mitigates against gross negligence in product liability circumstances.
4) No actual damage can be substantiated by the prosecution. The RC5 software, far from being heavy on network traffic, is a class of code known as "embarassingly parallelizable". In other words, the system consumes extraordinarily little network traffic for the amount of processing it does. Such processing is often done on systems with only intermittent modem connectivity; the university posessed a network connection several hundred times faster with permanent connectivity. It is beyond even the pale of conception that any communication from the RC5 system did, could have, or might have been predicted to cause any form of lesser service to any other network service. Indeed:
Suppose the school spent $200,000 on their internet connection yearly, for a single T1 interface capable of transfering one million, five hundred and fifty four thousand bits per second. Suppose the "damage" lasted over two years. This would place an upper cap of damages still at but $400K, and this would be presuming that the attack consumed the entire sum total of network resources. No such claim is being made. Lets assume that each transmission consisted of sixteen thousand bits every two days, and there were a hundred machines participating. These remain ballpark figures, but they're useful for illustrating the utter lack of direct damage. Over two years, those one hundred machines would exchange 584,000,000 bits.
This seems significant, until one realizes that the network as described posessed capacity to carry approximately 97,130,880,000,000 bits. The RC5 system, as it were, used up all of 0.0006% of the network capacity.
0.0006% of $400,000, incidentally, comes out to about $2.40.
5) Prosecution of Mr. McOwen would have a drastic chilling effect on the ability of computer administrators to do their work. When something as trivial as a pocket change's worth of network bandwidth can lead to felony prosecution, it becomes too risky to do much of anything. Mr. McOwen's judgement on the matter was trusted, and even if--in retrospect--management would have made separate selections, it's a questionable matter whether he could have fairly predicted that. His actions were questionable even as a offense worthy of termination, given the wide berth that system administrators require to be effective and the vast freedoms inherent in the academic environment. They'd be laughed out of any civil court in the country, and the fact that they've reached criminal court--at the felony level, which would deprive Mr. McOwen of his freedom, his voting rights, and even his ability to simply procure employment--is a grave insult.
This case should be thrown out of court, and the defendant's legal fees covered in full. Nobody should be allowed to abuse the power of the court in this manner.
Yours Truly,
Dan Kaminsky
Certified Information Systems Security Professional
> I think you are confusing "expected" (as in,
> average or mean value) with "desired" (as in,
> dreamed or wished)
That doesn't help your case. On average, it doesn't rain at most people's weddings. On average, there aren't flies in expensive drinks. On average, you're not going to meet the perfect person (though I suppose there's argument that, due to psychological misdefinition, they're almost certain to already have someone...that's *why* they're perfect.)
> Ironic doesn't mean unfortunate.
> It means unexpected. It's unfortunate
> to have rain on a wedding day, not ironic.
Unexpected for who? My primary point, which I think I proved, was that a simple definition of irony as "unexpected" is insufficient, even by those who think Ironic Isn't.
This is an interesting case of local vs. global context. Can something be locally ironic but globally predictable?
It's clearly *more* ironic when *more* people don't consider something unexpected. But, again, dramatic irony involves one set of people knowing and watching and the other set unknowing and experiencing. So there's clearly an aspect of separated knowledge in terms of the concept of irony.
Effectively, my point is that Alanis is singing about the personal perception of expected result (rain free wedding) vs. realistic possibility that actually "happened"(monsoon, which never happens on TV).
If it happened TO YOU, you'd consider it supremely ironic. You'd expect an insect in your alchohol if it was from some shady dive of a brewery, but not from a Chardonnay. You'd expect rain any other day but the one day that was supposed to be perfect for the rest of your life. And for the love of god, you'd expect to get your pardon before the executioner pulled the switch!
Irony is the betrayal by reality to an individual. It's intensely personal, and while the situation you listed was indeed much more ironic...I'm unsure it's really necessary for the personal perception of irony.
You effectively marked "active participation against the circumstance, when such circumstance wouldn't have been suffered without it" as the ironic agent. This is a definite contributer to irony, but I'm unconvinced it's a required one.
> Irony is, most commonly, "incongruity between
> the actual result of a sequence of events and
> the normal or expected result".
Lets use your definition, why don't we.
> * rain on your wedding day
Lets see. Do you imagine your wedding day will have rain? No, I believe the expected result of a wedding day is beautiful, sunny, life-affirming sunshine, perhaps with some brilliant and vast cloud formations on an almost blindingly blue sky.
Thunder and lightning on a continual background of a monsoon downpour is neither a normal nor expected image of one's wedding day. It's not even normal or expected weather in most locations on average, though it is known to happen ("I just never expected it'd happen to me!").
> * a free ride when you've already paid
Well, lets see. Consider a context in which you'd require a paid ride, i.e. a bus trip or a plane ride. Your normal and expected result if you *hadn't* paid was that you'd have been summarily kicked out and not given passage.
That you *did* pay, but turned out not being *required* to, *is indeed* neither normal nor expected.
> * the good advice you just didn't take
What's the normal expected result of receiving good advice? Isn't it following it? If you don't follow it, and get really hammered because of it, at the last second before the hammer falls don't you say, "Great, and I was actually *warned* about this...how ironic that the one time I recognize good advice, I don't follow it."
> * the black fly in your Chardonnay
I ask for a wedding ring. I receive a sekret decoder ring. Definitely not the normal or expected result.
Oops, not ironic. Fits your definition, but not ironic. Irony has some aspect of the betrayal by reality aspect which your definition doesn't cover.
Its when I ask for a wedding ring, the perfect size, the perfect model, everything is wonderful and I worked so hard to make it so...then it slips off her finger within 5 minutes and gets flushed down the toilet(in other words--I made it too perfect). That's irony--if I hadn't worked so hard, I'd have been happier.
It is indeed irony if you wouldn't have gotten a black fly in your drink if you hadn't ordered the Chardonnay, and is indeed *made* ironic that it's in the *more* expensive drink rather than in some cheap slop.
> * a death row pardon two minutes too late
Assuming a pardon is going to happen, it's normal and expected that it'll occur before the body is smoking with tens of thousands of volts.
If it happens after, *during* the process of execution...oops.
Remember, dramatic irony hinges on the fact that the reader knows something that the characters don't. A pardon must be delivered by someone--this someone doesn't know that the person is already in the process of being killed. An execution must be executed by someone--this person doesn't know that a pardon is forthcoming. The third party observer knows both, but can't do anything--thus the song.
> * winning the lottery and dying the next day
You finally get exactly what you want, despite its inherent rarity. Then you're hit by a bus the next day.
It's not normal or expected to win the lottery.
It's not normal or expected to get hit by a bus.
If you get the former(an extreme good), you *really* don't expect the latter (an extreme bad) to happen shortly. Therefore it's ironic, by your definition.
> * a traffic jam when you're already late.
Have you ever *been* in this situation? You've got it calculated down to the microsecond exactly how late you're going to be, presuming traffic follows normal patterns and you speed a little.
When you don't NEED it to be normal and smooth, it is. When you desperately REQUIRE it to be easily traversable, it gels into gridlock.
> * a no-smoking sign on your cigarette break
Obviously not a smoker. Throw in "biological demand and expectation." It's a goddamn *CIGARETTE BREAK*, you've got all of two words to find an expectation in there.
> * meeting the man of your dreams and then meeting his beautiful wife
Perfect mates are depressingly rare. The idea that you'd finally find one, only to learn that exactly what you wanted was no longer accessible to you due to someone more perfect for them than you is quite ironic.
It's the betrayal by reality that really defines irony. It's the satisfaction of expectations, *along with a twist that makes those expectations unsatisfactory*. "Be careful what you wish for, you just might get it" is a perfect illustration of irony, and is more selective even than your standard.
I do find it ironic that english professors insist with such regularity that something is not ironic when it rather clearly can be understood as so with a minimum of situational context.
Rabin's method is...interesting, in its usage of implicit state. But it's not perfect, and as I hope to show, there are semi-serious attacks against it.
To understand his method, one must follow its evolution from the baseline. The most obvious launching point is the PRNG XOR technique: Essentially, two hosts agree to seed a Pseudo Random Number Generator* with the same originating seed, then XOR** their data against that stream of entropy. The unique material that separates the sender and receiver from the rest of the world that is to be kept in the dark is not the psuedorandom stream of data but rather the key that both sides used to establish and synchronize their identical streams of pseudorandom data. If anyone else was to receive this seed, they too would be able to decrypt the XOR'ed ciphertext stream actually sent from the sender to the receiver.
From here we get his shared interaction with a (pseudo, but we'll ignore that)random stream of data.
One major problem, of course, is that there's absolutely no doubt of the *size* of the encrypted message being sent. XOR doesn't increase nor decrease the amount of bytes in the messages "ATTACK" or "SURRENDER", let alone hide whether a message is being sent or not. One thing we can do is have the sender continually broadcast the output of his PRNG whether or not its being XORed against anything, and send a "PRNG differential"(in other words, the exact opposite of whatever the PRNG counter reads) when a ciphertext segment is to begin. Of course, anyone who doesn't have the seed for the PRNG can't know such a trigger occurred, so (as should sound familiar) in order to offline-analyze the cipherstream, they have to analyze all the chaff that its hidden with. The sender and receiver have to be *exchanging* all that cruft though, but that's what they pay to avoid exposure to traffic analysis. The key to the transmission remains, however, the seed to the pseudorandom transmission.
From here we get his asymmetric capture/ignore differential between the eavesdropper and the receiver.
The problem is, in the real world, it's unrealistic for each theoretical communication channel to simultaneously occupy all bandwidth that they might eventually use--especially since the number of possible connections in a network scales exponentially for each additional member! As always in computer science, we need to find a way to convert a high order problem into a fixed expense, O(1).***
So Rabin's solution was to centralize the entropy source. But a central entropy source has to be used differently--the PRNG key can't be used as the message key, because the sender with the message is no longer the generator with the seed. Furthermore, if XOR is be used, entropy cannot be continually shared among all the active sessions, since repeatedly XORing the same entropy against different data compromises the security of the entire system. So what Rabin did was presume the two sides could exchange, not the seed to the PRNG, but a set of "counter times" at which to extract a subset of entropy from the communal pile. Every individual stream would probabilistically negotiate a unique and separate random stream of entropy culled from the global shared pool. This shared key would grant the sender and the receiver the ability to communicate with eachother, but could never independantly decrypt the datastream. Without the "private" reduction from the
"public" shared entropy source, the key would provide no assistance in decrypting the data--and since the data was essentially XOR'ed against a unique set of random data, the data would indeed be uncrackable, because the eavesdropper didn't copy all the necessary pieces.
What's to prevent this copying? "The data stream for the shared entropy is too large."
This is apparently empirically untrue. Solar entropy was brought up as a possible source of shared entropy, with the immediate rejoinder that NASA et al. have no problem storing *vast* amounts of data from the Sun. I heard numbers as large as an exabyte a day of data storage, though I'm sure (I Hope!) that's a gross exaggeration. 24TB a day is easily within reason, however, and 24TB / 24 hours / 60 minutes / 60 seconds leads to a stream of data that reaches 266MB/s.
Standard hardware isn't exactly built to parse data quite that fast, even though that's well within the boundries of full-time recording capacity. But there's no actual need to continually record, since as long as an eavesdropper is looking for interesting things to pull off the wire, they can immediately begin recording from the global datastream whenever they see something being XORed through it.
Essentially, everyone's sharing the same chaff pool, which is moderately interesting.
What's most interesting is the fact that there's an asymmetric function buried in this, and that's Discrete Time. Standard analog time can be considered the "standard" clock; Discrete Time is the beat of the global entropy pool sending up a new value. If one knows the right data at the right time(which segments to use as XOR values), very little expense needs to be levied to discover the plaintext. If one eventually finds out the right data, but much later, a relatively extreme expense needs to be paid to determine the historical value of the cost.
A major possible attack, of course, is subversion of the central source of data. Implementations that use sequential chunks, instead of randomly plucked bits, would be pretty vulnerable to a central source that *looked* random but actually provided significant information to the end listener.
On the flip side, there's a very good question on what a pseudorandomly selected subset of a truly random bitstream qualifies as. Pseudorandom? No--there's no seed that will reveal those bits; one tenth of thermal noise is still thermal noise. Random? Well, they were selected by a predictable function from a non-secret source. Perhaps they're pseudo-pseudo-random?
Hope this analysis helped some of you understand.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
* Pseudo Random Number Generator: a function that converts a fixed set of bits into an infinitely large set of predetermined but statistically random numbers)
** XOR: Exclusive OR; a trivial and reversable operation that scrambles data on a bit by bit basis. XORing something with random data once results in random data; XORing it again with the same random data results in the original content.
*** O(1): Order 1 -- No matter how many items in set N, the task will only be done once.
Cisco's had to deal with some pretty nasty patents being lodged against it; as far as I've seen, they've not gone out and actively used so-called "nuclear" patents(for their MAD capacity) as a method of extortion.
A while ago, Slashdot linked to a story about what I feel is truly the most interesting model for 3D fabrication: Ice.
Much as the military has been pushing for the ability to deliver damage with energy instead of ammunition(because ammunition requires supply lines, separation of parts, and so on, while power simply requires any of a thousand sources), ice fabbers only require water to do their work. In my mind, the temporary nature of the material(which can even be three dimensional and thus reflective of its internal structure!) is outweighed by the near-zero marginal costs and surprising flexibility of such a device.
This company seems like they're just trying to tweak manufacturers into making noises(thus validating them to VCs who will give them money). It's like the old obsession over plastics, only spoofed into the P2P/Napster/No-Money-Economy model. The sheer coolness of arbitrary ice sculptures belies the fact that very few materials build correctly layer-by-layer--in other words, since your materials are limited, you can't go off and download a car or even a rolex--the parts won't last!
Arbitrary chimeras will come before arbitrary rolexes. Creatures are self-assembling, rolexes aren't.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
I wrote about this some time ago. (Actually, I devoted about four months of my life to writing about it, which never went anywhere. Thus, Dan Learns The First Rule Of Design: If Thou Can't Code, Nothing's Gonna Change:-)
Kudos to Jamie for investigating this further; the following was my original submission on this topic:
=======
The mind boggles. Police have apparently raided a student's dorm room due to his participation in a heavy metal music inspired gaming clan, "Bled For Days." The article goes to some length not to mention the exact game, including ominous references to a "war-like" "game of chess" where "it's not like we were going to kill you or anything". The game in question, of course, is the seminal Humans vs. Bugs vs. Yellow Psychic Alienswargame, Starcraft. The presence of a web page listing in-game rivalries was apparently taken for death threats. For all the talk of "children" being unable to differentiate fake violence from the real thing, it seems to me that "adults" were the ones breaking into someone else's home, carrying loaded weapons, confiscating expensive goods while availing themselves of the opportunity to search for anything more valuable(i.e. drugs).
As hilariously pitiful as this seems, there's a real problem here. The tragedy is that, sooner or later, the credibility of authorities trying to fight real computer crime will be so stretched that even when society desperately requires their intervention, the police will find themselves unable to get even the slightest shreds of voluntary cooperation. A bizarre and ultimately truly dangerous attitude, the apathetic chuckle, has spawned over recent years by Zero Tolerance(and apparently, Intelligence, Accountability, or Political Responsibility) policies; the exact policies that have lead to first graders being suspended for pointing chicken at eachother and being expelled for kissing a girl on the cheek. People are willing to quickly accept these ridiculous and flagrantly neglectful abuse of power because "it's funny to laugh at...but I can't do something about it, isn't that someone else's job?"
This threatens the core legitimacy of what really are genuinely critical services; the police, the school, and the administrators all become jokes, not to be taken seriously. The immediate reaction my friends had to this incident at Kent State was, "The last time police at Kent State didn't understand what the students were up to, somebody won a Pulitzer Prize". Since the most damaging effect of any computer security violation is the long term degradation of trust in a given service, the ignorance these busts show eventually makes it harder to actually control and address genuine security issues, such as DDoS attacks. Instead of simply laughing and moving on, what can we, as a community do to prevent these kind of occurances in the future? Would something as simple as a confidential "reality check" group of experts, made available to law enforcement as consultants, be helpful? Would a set of guidelines, peer reviewed by the community, be useful? Instead of cursing the darkness, how can we praise the light?
Jesus! For Heaven's sake, I was just making a Goddamn Joke! Holy Mother Of All That Is Holy, I fear for the souls of this Heathen Humorless Wretch of a Discussion Forum!
(Anyway, saying "Billion Dollar War Chest" MS is going down in six months--like the Slashdot headline implied--is more ridiculous than even this quote. Of course, that's not what ESR said, but that's what we saw.)
My point is, if you have to check to see if *your* version of 5.6.0 is the same as the dangerous version of 5.6.0, that version number just lost a hell of alot of relevance and is essentially meaningless.
YES! It IS! It's too hard for me to read the source code to every app I run. I admit it. I want to trust Theo. I want to believe his prying eyes are protecting me from danger. I don't *want* to have to go diving into the code he writes or even the fixes he claims when a new vulnerability comes out. I want to know: Is this the exact same code that is vulnerable everywhere else? Then upgrade. Is this NOT the exact same code, and therefore I should check the Changelog?
I'm not asking alot. I'm merely asking the question: What do version numbers mean, if they *aren't* snapshots of code?
Actually, that's pretty interesting! Here's my output on OpenBSD for Sparc. Note the lack of "Locally Applied Patches", which I appreciate.
Still, I question if the version number should stay stable. Suppose, for a moment, that the rest of the world finally discovers major holes in 5.6.0. Should OpenBSD administrators have to root around the Changelogs to realize they're running a safe build? Wouldn't it be better for them to be running 5.6.0_OB2.7 and see that, heh, the Changelog shows that the new stuff protects them?
===
$ perl -v
This is perl, v5.6.0 built for sparc-openbsd
Copyright 1987-2000, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under openbsd
Compiled at May 5 2000 12:35:29
@INC:
/usr/libdata/perl5/sparc-openbsd/5.6.0
/usr/local/libdata/perl5/sparc-openbsd/5.6.0
/usr/libdata/perl5
/usr/local/libdata/perl5
/usr/local/libdata/perl5/site_perl/sparc-openbsd
/usr/libdata/perl5/site_perl/sparc-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/site_perl
/usr/lib/perl5/site_perl
.
Because I wanted command completion. What, you think sh is the height of security? Among other things, *any* shell can be trojan'd to attack replace su, or even/bin/su, with a mod that captures the root password. The advice to never log in as root, and rather to su to it, is thus rather dangerous.
You are correct, of course. Most things shouldn't be done as root. I could theoretically have checked versions without it. This is somewhat on the order of a spelling flame, but I'll take it in stride.
As for my qualifications, feel free to scan my BugTraq posts, and thank you for helping to prevent my ego from growing too large.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Yes, I can definitely hunt down the changes, and Theo is well within his rights to change the source. Hell, I'm thrilled he's fixing problems.
But should I have to check a changelog to know there's a change?
That's the bottom line question. Should not a version reflect a snapshot of code? Should not I be able to trust a given codebase by its version alone, rather than have to audit the source by hand?
If a version *doesn't* refer to a snapshot of code...well, what does it refer to?
Slashdot Mirror
The trouble is that he was not mandated to do it, and it is not obvious that he had the leeway to do it. This gives him no ass-covering material. There's no piece of paper that unambiguously says he was permitted to do what he did. He can only argue about vague general principles.
I actually think the "vague general principals" are surprisingly supportive of the RC5 client, as I laid out in my second point. Here's a document that explicitly states what he can and cannot do, and he quite oddly follows it well.
I mean, seriously. There's alot of mileage to be gotten out of the fact that this document:
1) Says sysadmins are effectively autonomous
2) Lays out restrictions that are almost entirely followed to the letter(including WRT CPU usage).
Sigwinch, read the supporting documentation I provided earlier. Those are their policies. His actions are not even clearly a violation of them!
Never take a risky action in a corporation without considering how it will sound in front of a Federal jury or Congressional committee. "So, Mr. McOwen, are you're telling us that you were converting these computers to your own use to win a $1000 prize?"
http://www.theonion.com/onion3723/nobel_fever.h
Seriously though, the Nobel Prize is a much richer purse than RC5 will ever have; you don't see people being hauled off to jail for discovering the top quark!
To a jury of bums, rednecks, and career Taco Bell cooks, that $1000 prize will be damning. Ditto for newspapers and blood-n-depravity TV news shows.
Americans love two things:
1) Seeing criminals shot down by the public.
2) Seeing Goliath shot down by David.
The problem with McOwen is that it transcends the criminal-citizen barrier: Quite a few of us could imagine doing something unique and productive at work that some bureaucrat might not agree with. This self-identification means that the criminal prosecution becomes a personal threat that we'll pay (through advertising dollars) to watch allieviated.
"Piss your boss off, go to jail." The hacker/citizen barrier is *nothing* against this.
So? The humorless gentlemen in the dark polished cars, wearing nice suits and ray ban sunglasses don't give a flying fuck that the situation is bad. All they care about is the documentary evidence that *you* made it measureably worse.
Consider the opposite situation--suppose McOwen was in a tightly controlled secure environment, with all software change controlled and all decisions made through three levels of bureaucracy. Clearly McOwen would be much worse off -- not only would he be obviously and knowingly violating the decision making policies of his organization, but he'd be doing so in a manner in stark contrast to standard operating procedure.
He'd be screwed.
But that's not how it went. There was no strong top down organizational structure; it was all UGA could do to keep their sysadmins from maliciously harassing users! There was no "line in the sand" that McOwen crossed; his job was to maximizing the value of university computing resources and he did so. If he added minutely to system insecurity, the fact that he was hired to do things in an insecure manner(telnet blah) is at least a strongly mitigating factor.
Security is a process, as Bruce says. With little process in place, there was little for him to violate.
You do if you're a career state-employed academic bureaucrat. Any one of 'career', 'state-employed', 'academic', or 'bureaucrat' would be bad news. Put them all together and it's a deadly situation. The person carrying out this campaign against McOwen is certainly clueless, likely vindictive, likely monomaniacal, and *committed*. Once a person like that starts a campaign, they'll push it as far as possible. They won't know when to give up.
Couldn't have said it better myself--this is where my reluctance to entirely blame the prosecuter's office comes from.
It would arguably have been better to continue with 40-bit DES, and let the electronic pearl harbor force Congress to clean house at the NSA.
An interesting historical what-if. An electronic Pearl Harbor would plant a pernicious seed of doubt in the validity of all electronic records though, significantly destabilizing our entire system of indentured servitude / credit card debt. Given the personal profitability of being able to legitimately challenge the veracity of your entire debt history, I'm unconvinced any quality of crypto would ever be able to save an economy thrown into a tailspin by an EPH.
"Cracking DES" had the best possible effect, I think: It destroyed political opposition while leaving public trust unsullied.
Offtopic, but... WEP is an impressive accomplishment. They actually managed to design a cryptosystem that has cipher- and key-exchange-independent insecurity (the 24-bit initialization vector).
My favorite independent vulnerability right now involved keystroke password analysis in SSH1. Effectively, you monitor the timing variations between characters in a user's password as they're sent on the network and use hidden markov chains to determine the most likely keys that are being entered. It turns out that we take longer to transition between certain keys than certain other keys, and this transition distance can be indepedently analyzed.
If they really did just make up this numbers, the case could blow up in their faces.
Well, I made up the numbers WRT $200,000/yearly for a single T1--the difference is I was showing ballpark figures, whereas they're seeking felony conviction.
Big difference
During the day, the truck is *HIS*. He can pick his own routes, make a detour for a customer who is in a huge hurry, bend the traffic regulations, and generally do whatever it takes to get the job done. He job is a big one, and he therefore has a lot of leeway to make autonomous decisions. Suppose he wants to take the truck home at the end of the day to move a sofa. If he takes 10 seconds to get the boss's permission, taking the truck is perfectly OK.
Bad example--the equivalent circumstance is McOwen physically transporting the servers to his home to run some work for him there. You can't get around that -- you mention grand theft later; the reason it's grand theft is because the trucks were supposed to be there but instead disappeared!
It's not arguable that the movement of the sofa is at all within the mission of the trucking company; however it is extremely arguable that academic research and collaborative mathematical analysis is directly within the mission of a university. It does not matter if you would have made the same choice; you merely need to accept that it was a reasonable conclusion to reach for this to be an issue of internal policy disagreement and nothing more.
If it's your job to use them that way, you just do it. However, if there is a person who could say no, and you don't ask, you have done something wrong.
I'm reminded of the history of the HP Deskjet; which was fought tooth and nail by the laser printer heirarchy at HP.
There's *always* a person who could say no to something. The question is whether the general consensus is that something is not to be done -- no human organization can operate unanimously; it creates too many absolutes of power. Mr. McOwen may have known some might have disagreed with his use of the software, but there's always someone who disagrees. The question is: Who else knew of his actions, who else approved, and how does legitimate access to company hardware turn into the equivalent of a foreign hacker maliciously breaking in and subverting computer resources?
In a criminal case it is not necessary to prove substantial monetary damages, it is merely necessary to prove that the person did something they had not been given permission to do.
"Did you have passwords to these machines?"
"Yes."
"Did you steal them?"
"No."
"Who gave them to you?"
"My employer."
"To do what with?"
"Configure the machines."
"How so?"
"In a manner that maximized their usefulness."
"Any specifics?"
"Just what's in the guide."
"Did you violate the restrictions in the guide?"
"No."
If you allow fear to govern your actions, you are letting the enemy dictate your actions.
At the point of criminal prosecution, your hope for a peaceful ending (unless you wish to plea) is over.
It's funny, but I am also being serious. The Internet search engines are already starting to correlate information with specific people.
Thus why I've told a couple girls to never do porn. We're only a scant few years away from large scale eigenvector based face searches through large image databases, and the code is almost certainly going be trained against porn--there's no larger source of stock human photography!
The prosecutor is actually a good point of approach, if you can get him in touch with a clueful expert.
A guy can hope
Anyway, I understand what you're saying
Ditto.
I just think it's McOwen's fault for not establishing a paper trail showing permission.
My hope is that McOwen saved a few emails from coworkers higher than him expressing approval for the project...
"The Young Male Sysadmin's Guide To Not Going To Prison"
I feel like I'm looking at the title of one of those "World's Thinnest Books". Of course, considering the state of the economy, a chapter on how to successfully steal bread so you don't starve to death might be useful...
--Dan
Consider this example:
You hire me to pick stocks. I pick bad stocks -- you fire me.
I didn't steal from you.
I didn't intentionally seek to defraud your company.
I didn't hide the stocks I purchased.
I was more aggressive than normal, but not unusually so.
I simply bought the wrong stocks, and got canned for it.
Should I go to prison for losing you money?
Now imagine I didn't actually even lose you anything -- you were merely concerned that at some point in the future, the stocks I picked might possibly expose the company negatively.
Should I have even been fired?
Possibly--but possibly not. If it's not even obvious if I should be fired, how could it be obvious that I should be imprisoned?
Something to think about.
Yours Truly,
Dan Kaminsky, CISSP
For the support of the organization, not for his own personal amusement, and most assuredly *not* for an effort to win him a prize.
:-)
It is my contention that his personal goals and the mission of his company were not in conflict, and furthermore the odds of him actually winning the prize, remote enough(even with whatever rank he managed to achieve), the prize small enough, and the actual distribution of that profit distributed enough that for all intents and purposes the value of that prize goes to zero.
In terms of the prize itself, his probabilistic share probably didn't add up to the price of a can of Mountain Dew. That's a Red Herring and you know it.
That a university is publicly oriented does not give its employees license to do whatever they think is in the public interest. A university is a corporation, just like any other, and the use of its resources must be approved by management.
First of all, you're wrong. A university is not a standard corporation any more than a political party is, particularly not a university established as a branch of the government! The explicitly avowed dedication to academic freedom means a hell of alot.
Second, I haven't seen a single shred of evidence to state that he himself didn't have the discretionary authority to decide to run this software. Administrators were exhorted to behave in a manner compatible with the values of the university; as I noted, the RC5 system was extraordinarily compatible with the values as they were laid down, down to relinquishing CPU upon request.
In fact, if one examines the documents linked in the previous post in depth, one finds an extraordinary amount of power given to system administrators -- so much, in fact, that "management" sees the need to specifically warn administrators not to be overly or overtly malicious towards students. This seems to me an implication that sysadmins had an extraordinary amount of autonomy over the systems they deployed.
Whether or not you feel this is a good thing for management or even a professional thing for Mr. McOwen, the implication that the systems were under his discretionary control is quite clearly there.
He wasn't a consultant, sigwinch. He was one of the operators.
Incidentally -- these machines were going for some time, with no complaints being rendered for quite some time. This means a couple things:
1) Other admins who noticed either approved, yielded to McOwen's discretionary authority, or were able to remove it themselves. Any way you slice it, the time he was granted helps, not hurts his position. (By contrast, a genuine attack usually *hurts* a network, causing reasonably quick corrections.)
2) Management either approved, or itself issued little low-level discretionary authority. In other words, management ordered the sysadmins to keep things running. If the sysadmins extracted more value from the sunk costs, and it was (reasonably) within the mission of the university -- so be it.
Unreviewed, untested, warranty-less binaries that engage in continuous communication with remote servers are a serious security threat, as well as a threat to the integrity of the machines.
Yeah, welcome to Winamp, Windows Media Player, RealPlayer, Yahoo Messenger, and Windows itself.
Give be a break. The majority of university networks are so riddled with out of date daemons and unfirewalled ports it's ludicrous to suggest a single daemon with no known polling vulnerabilities is going to outweigh it. (By contrast, simply spoofing Winamp's update page is enough to destroy it.)
And what the fuck does that have to do with this discussion? The question is whether he had permission, not whether he would have had a good justification if he had asked for permission.
The question is if he had to ask. My point is that the burden is on the university to show he actually did need to ask, because he was clearly acting within the bounds laid out in the rules the school made public in a position that demands a large amount of autonomy.
Remember, that you would have made a different choice is irrelevant; the question is whether he had the right to make such a choice. In my mind, the fact that so much time passed between his use of university resources and his eventual shutdown means that quite a few people knew of this incident and one person elected to express discretionary priveledge and can him. That's fine--it happens--but you don't send someone to jail for it.
And even if that was our discussion, brute-force cracking RC5 is a stunt. It doesn't do a damn thing for security.
Silly. You have no idea how much Cracking DES did, do you? Do you have any idea how significant the EFF's DES Cracking book was in making sure AES happened, and in forcing 3DES to be the standard of the day?
Do you understand how recent it was that the federal government was saying it would take a foreign government inordinate and unrealistic amounts of time and money to crack even one DES key?
Do you realize how many algorithms, *today*, still depend on 40 bit RC4? Most SSL sites -- that travesty that is 802.11 WEP -- the garbage is everywhere.
Are you an idiot? Do you know nothing about computers?
Ask this again two weeks from now.
Diligent recovery from this compromise would involve...
a lot of things that didn't happen. At all. Even in the slightest.
You can't charge for damages that didn't occur. It's like filing a suit for your own wrongful death because somebody coughed next to you and they might have had TB--first of all, you ain't dead, second of all, they didn't have it!
Competent professionals help the client accomplish their mission. If they have ideas for new mission objectives, or even for cool charitable projects that don't really accomplish much, they discuss it with the boss. They *don't* run off and reconfigure hundreds of pieces of high tech equipment for their own whimsy.
I claim this did help with the mission, and that it was reasonable for McOwen to believe this was within his assigned powers. If his interpretation was at odds with that of the administration, perhaps he deserved to lose his job -- but this doesn't even pass the giggle test for felony hacking. They were HIS BOXES. He had a legitimate accounts, probably even root accounts and did things that were *arguably* legitimate.
Sysadmins *never* have the right to turn hundreds of the institution's machines into zombies for their own pet projects.
Oddly enough, who do you go to if you have a project that could really use a few hundred machines? You go to management, they look at you funny and tell you to go to the guru to decide whether or not to do it.
In most places with vast amounts of computing resources, there's usually a sysadmin at the top of the pile choosing what goes where--and if there's nobody on top of everything, like there aren't at most understaffed universities, everyone who has legitimate acccess is expected to legitimately use it--however they see fit, as long as they follow the rules.
Hardly. It's vandalism, plain and simple. The alterations he performed obviously had no relevance to the organization's mission, they had a potential serious deleterious impact on the mission, and he deliberately chose not to ask permission when doing so would have required little time or effort.
I provided extensive documentation showing the compatibility of this project to the university mission. I don't need to show it's absolutely correct -- merely that it's plausible.
Whatever deleterious effect you mention *didn't happen*, and as far as I can tell hasn't *ever* happened. Complete lack of precedent for a deleterious effect has an effect in a courtroom, you know.
The law is the least of his problems. Not only did he recklessly fuck over hundreds of his client's machines, he whined about the client's consternation on the Internet.
If the prospect of a decade of prison rape wouldn't make you run screaming like a horror movie prom queen into whatever abandoned warehouse of an online forum you could find -- you're a stronger man than I.
For the rest of his life, any time a prospective employer does a web search on him this story will show up in all its tawdry glory.
Oh, this is much better than a felony conviction. It don't say, "Have you ever been mentioned on Slashdot" on the employment forms, you know
I propose a new phrase for the Internet lexicon: "Pulling a David McOwen". It will be the Darwin Award of Career Limiting Moves.
Heh. Doctors play God, admins play BOFH. Both make mistakes, but the latter almost never kills anyone. Strip root, maybe. Strip down, though? For "hacking" his own machines?
He ran rc5, not rm -rf. He used computers to compute, not to destroy. He yielded processor when needed, rather than hog it to the exclusion of all others.
Felony hacking my ass, and *everybody* knows it.
I do feel for the prosecutor, though. I don't think he realizes how badly he's being used.
--Dan
www.doxpara.com
> Reprimanded, shreprimanded. It should achieve their own felony prosecution.
I'd be more than happy with a simple reprimand. It's a matter of fairness after all -- we think the charges against Mr. McOwen are excessive; it would behoove us not to levy similar charges against the prosecuter's office.
In both circumstances, there are quite a few others who are much more deserving of investigation.
--Dan
I am not a lawyer. I may once have thought to become one, but I have since been a technologist and a cryptographer. But I do not appreciate what Mr. McOwen is being accused of, and here are my thoughts on the matter:
====
To state that this case deserves to get thrown out of court -- with the prosecuting attorneys being reprimanded for falsifying financial figures to achieve a felony prosecution -- is not only a reasonable statement, it's possibly an obvious one. I have five arguments from which I draw these conclusions:
First, Mr. McOwen's terms of employment were easily open ended enough to consider this a valid use of network resources.
Second, University policy clearly granted Mr. McOwen permission to administer the machines as he saw fit, as long as he did so "fairly and in accordance with University policy."
Third, Mr. McOwen was acting in due diligence against billions of dollars in yearly national liability from a weak computer security environment.
Fourth, the Prosecution's numbers cannot be justified in any way, shape, or form.
Fifth, the very prosecution of this case creates a grave chilling effect against the ability for computer administrators to successfully maintain the systems they are charged with.
1) The exact job specifications of Mr. McOwen's employment were not and literally could not be set in stone; his basic task was to administer the systems according to the precepts of the site they were deployed. In this case, the site was an educational institution. Educational institutions, as opposed to even corporate workplaces, exist as nodes of "basic research" and "collaborative and non-profit volunteerism". Surely, it is not inconcievable that given the extraordinarily high degree of public works that universities are known for, that he might have come to the reasonable conclusion that installation of software that contributed to a public good (the global improvement of cryptographic quality) would be a fair extension of the mission of the university.
2) The University of Georgia's computer security policies, available at http://www.uga.edu/compsec/summary.html , clearly give Mr. McOwen wide latitude to administer systems however he saw fit. It states, "Those who administer computers and network facilities shall perform their duties fairly, in accordance with University policies." As this is the primary document describing University policies with respect to computer security, it stands by itself as a sufficient source of guidance for Mr. McOwen. Users are admonished that they "...shall take full responsibility for messages that they transmit through the University's computers and network facilities"; such responsibility refers specifically to "fraud, harassment, obscenity, and the like." Surely the analysis of simple numbers does not rise to the level of obscenity! There are admonitions against Trojan Horses and computer virii, yet both tools exist to procure access where none existed before--Mr. McOwen was granted his access legitimately. Indeed, the university specifically defines Trojan Horses in a detailed guide available at available at http://www.uga.edu/compsec/use.html : "A Trojan horse is a program with a hidden, destructive function, or a program designed to trick users into revealing confidential information such as passwords." There was nothing hidden about the RC5 code, and as for destructiveness, few would argue it is destructive to a computer to ask it to compute! Though there is a mention against "cracking", it is specifically in reference to the cracking of computers--Mr. McOwen was analyzing a code specifically authorized and designed to be analyzed. Even if he had been running a genuine system cracking utility, the detailed rules specifically authorize system administrators to do so. Mr. McOwen even actively complied with the requirement to give higher priority to users with more important work by running software that immediately yielded resources requested to any other software that requested them. Given the degree to which Mr. McOwen explicitly complied with university regulations, it is difficult to see the validity of this case.
3) Statistics have shown a multi billion dollar a year loss to the country from insufficient encryption and computer security systems. Such damage is often either concentrated or traced from machines with inadequate network security. University machines, almost always under-administered and very often forced to be publically accessable due to the academic requirements of students (one could not expect a place of higher learning to be as firewalled as the FBI!), often either directly experience financial damage or indirectly contribute to theoretical litigation expenses from being used as "jumping off points" for larger attacks. By contributing to the global awareness of the dangers of insufficient security, David expressed a degree of "due diligence" towards solving a problem the university was contributing to. Such due diligence constitutes a legitimate usage of system resources as a mitigating factor in any future litigation, much as active and genuine safety research mitigates against gross negligence in product liability circumstances.
4) No actual damage can be substantiated by the prosecution. The RC5 software, far from being heavy on network traffic, is a class of code known as "embarassingly parallelizable". In other words, the system consumes extraordinarily little network traffic for the amount of processing it does. Such processing is often done on systems with only intermittent modem connectivity; the university posessed a network connection several hundred times faster with permanent connectivity. It is beyond even the pale of conception that any communication from the RC5 system did, could have, or might have been predicted to cause any form of lesser service to any other network service. Indeed:
Suppose the school spent $200,000 on their internet connection yearly, for a single T1 interface capable of transfering one million, five hundred and fifty four thousand bits per second. Suppose the "damage" lasted over two years. This would place an upper cap of damages still at but $400K, and this would be presuming that the attack consumed the entire sum total of network resources. No such claim is being made. Lets assume that each transmission consisted of sixteen thousand bits every two days, and there were a hundred machines participating. These remain ballpark figures, but they're useful for illustrating the utter lack of direct damage. Over two years, those one hundred machines would exchange 584,000,000 bits.
This seems significant, until one realizes that the network as described posessed capacity to carry approximately 97,130,880,000,000 bits. The RC5 system, as it were, used up all of 0.0006% of the network capacity.
0.0006% of $400,000, incidentally, comes out to about $2.40.
5) Prosecution of Mr. McOwen would have a drastic chilling effect on the ability of computer administrators to do their work. When something as trivial as a pocket change's worth of network bandwidth can lead to felony prosecution, it becomes too risky to do much of anything. Mr. McOwen's judgement on the matter was trusted, and even if--in retrospect--management would have made separate selections, it's a questionable matter whether he could have fairly predicted that. His actions were questionable even as a offense worthy of termination, given the wide berth that system administrators require to be effective and the vast freedoms inherent in the academic environment. They'd be laughed out of any civil court in the country, and the fact that they've reached criminal court--at the felony level, which would deprive Mr. McOwen of his freedom, his voting rights, and even his ability to simply procure employment--is a grave insult.
This case should be thrown out of court, and the defendant's legal fees covered in full. Nobody should be allowed to abuse the power of the court in this manner.
Yours Truly,
Dan Kaminsky
Certified Information Systems Security Professional
> I think you are confusing "expected" (as in,
> average or mean value) with "desired" (as in,
> dreamed or wished)
That doesn't help your case. On average, it doesn't rain at most people's weddings. On average, there aren't flies in expensive drinks. On average, you're not going to meet the perfect person (though I suppose there's argument that, due to psychological misdefinition, they're almost certain to already have someone...that's *why* they're perfect.)
--Dan
> Ironic doesn't mean unfortunate.
> It means unexpected. It's unfortunate
> to have rain on a wedding day, not ironic.
Unexpected for who? My primary point, which I think I proved, was that a simple definition of irony as "unexpected" is insufficient, even by those who think Ironic Isn't.
This is an interesting case of local vs. global context. Can something be locally ironic but globally predictable?
It's clearly *more* ironic when *more* people don't consider something unexpected. But, again, dramatic irony involves one set of people knowing and watching and the other set unknowing and experiencing. So there's clearly an aspect of separated knowledge in terms of the concept of irony.
Effectively, my point is that Alanis is singing about the personal perception of expected result (rain free wedding) vs. realistic possibility that actually "happened"(monsoon, which never happens on TV).
If it happened TO YOU, you'd consider it supremely ironic. You'd expect an insect in your alchohol if it was from some shady dive of a brewery, but not from a Chardonnay. You'd expect rain any other day but the one day that was supposed to be perfect for the rest of your life. And for the love of god, you'd expect to get your pardon before the executioner pulled the switch!
Irony is the betrayal by reality to an individual. It's intensely personal, and while the situation you listed was indeed much more ironic...I'm unsure it's really necessary for the personal perception of irony.
You effectively marked "active participation against the circumstance, when such circumstance wouldn't have been suffered without it" as the ironic agent. This is a definite contributer to irony, but I'm unconvinced it's a required one.
Yours Truly,
Dan Kaminsky, CISSP
http://www.doxpara.com
> Please shut up and maybe your verbal dribble will pass us by...complete fewking IDIOT
Fucking, good sir. Say it. FUCKING. Not fewking, not f***ing, FUCKING.
The only thing sadder than a flamer who can't flame is a swearer who can't swear.
Believe me what you will. But *fuck* completely empty political correctness.
--Dan
> Irony is, most commonly, "incongruity between
> the actual result of a sequence of events and
> the normal or expected result".
Lets use your definition, why don't we.
> * rain on your wedding day
Lets see. Do you imagine your wedding day will have rain? No, I believe the expected result of a wedding day is beautiful, sunny, life-affirming sunshine, perhaps with some brilliant and vast cloud formations on an almost blindingly blue sky.
Thunder and lightning on a continual background of a monsoon downpour is neither a normal nor expected image of one's wedding day. It's not even normal or expected weather in most locations on average, though it is known to happen ("I just never expected it'd happen to me!").
> * a free ride when you've already paid
Well, lets see. Consider a context in which you'd require a paid ride, i.e. a bus trip or a plane ride. Your normal and expected result if you *hadn't* paid was that you'd have been summarily kicked out and not given passage.
That you *did* pay, but turned out not being *required* to, *is indeed* neither normal nor expected.
> * the good advice you just didn't take
What's the normal expected result of receiving good advice? Isn't it following it? If you don't follow it, and get really hammered because of it, at the last second before the hammer falls don't you say, "Great, and I was actually *warned* about this...how ironic that the one time I recognize good advice, I don't follow it."
> * the black fly in your Chardonnay
I ask for a wedding ring. I receive a sekret decoder ring. Definitely not the normal or expected result.
Oops, not ironic. Fits your definition, but not ironic. Irony has some aspect of the betrayal by reality aspect which your definition doesn't cover.
Its when I ask for a wedding ring, the perfect size, the perfect model, everything is wonderful and I worked so hard to make it so...then it slips off her finger within 5 minutes and gets flushed down the toilet(in other words--I made it too perfect). That's irony--if I hadn't worked so hard, I'd have been happier.
It is indeed irony if you wouldn't have gotten a black fly in your drink if you hadn't ordered the Chardonnay, and is indeed *made* ironic that it's in the *more* expensive drink rather than in some cheap slop.
> * a death row pardon two minutes too late
Assuming a pardon is going to happen, it's normal and expected that it'll occur before the body is smoking with tens of thousands of volts.
If it happens after, *during* the process of execution...oops.
Remember, dramatic irony hinges on the fact that the reader knows something that the characters don't. A pardon must be delivered by someone--this someone doesn't know that the person is already in the process of being killed. An execution must be executed by someone--this person doesn't know that a pardon is forthcoming. The third party observer knows both, but can't do anything--thus the song.
> * winning the lottery and dying the next day
You finally get exactly what you want, despite its inherent rarity. Then you're hit by a bus the next day.
It's not normal or expected to win the lottery.
It's not normal or expected to get hit by a bus.
If you get the former(an extreme good), you *really* don't expect the latter (an extreme bad) to happen shortly. Therefore it's ironic, by your definition.
> * a traffic jam when you're already late.
Have you ever *been* in this situation? You've got it calculated down to the microsecond exactly how late you're going to be, presuming traffic follows normal patterns and you speed a little.
When you don't NEED it to be normal and smooth, it is. When you desperately REQUIRE it to be easily traversable, it gels into gridlock.
> * a no-smoking sign on your cigarette break
Obviously not a smoker. Throw in "biological demand and expectation." It's a goddamn *CIGARETTE BREAK*, you've got all of two words to find an expectation in there.
> * meeting the man of your dreams and then meeting his beautiful wife
Perfect mates are depressingly rare. The idea that you'd finally find one, only to learn that exactly what you wanted was no longer accessible to you due to someone more perfect for them than you is quite ironic.
It's the betrayal by reality that really defines irony. It's the satisfaction of expectations, *along with a twist that makes those expectations unsatisfactory*. "Be careful what you wish for, you just might get it" is a perfect illustration of irony, and is more selective even than your standard.
I do find it ironic that english professors insist with such regularity that something is not ironic when it rather clearly can be understood as so with a minimum of situational context.
Yours Truly,
Dan Kaminsky, CISSP
http://www.doxpara.com
Rabin's method is...interesting, in its usage of implicit state. But it's not perfect, and as I hope to show, there are semi-serious attacks against it.
To understand his method, one must follow its evolution from the baseline. The most obvious launching point is the PRNG XOR technique: Essentially, two hosts agree to seed a Pseudo Random Number Generator* with the same originating seed, then XOR** their data against that stream of entropy. The unique material that separates the sender and receiver from the rest of the world that is to be kept in the dark is not the psuedorandom stream of data but rather the key that both sides used to establish and synchronize their identical streams of pseudorandom data. If anyone else was to receive this seed, they too would be able to decrypt the XOR'ed ciphertext stream actually sent from the sender to the receiver.
From here we get his shared interaction with a (pseudo, but we'll ignore that)random stream of data.
One major problem, of course, is that there's absolutely no doubt of the *size* of the encrypted message being sent. XOR doesn't increase nor decrease the amount of bytes in the messages "ATTACK" or "SURRENDER", let alone hide whether a message is being sent or not. One thing we can do is have the sender continually broadcast the output of his PRNG whether or not its being XORed against anything, and send a "PRNG differential"(in other words, the exact opposite of whatever the PRNG counter reads) when a ciphertext segment is to begin. Of course, anyone who doesn't have the seed for the PRNG can't know such a trigger occurred, so (as should sound familiar) in order to offline-analyze the cipherstream, they have to analyze all the chaff that its hidden with. The sender and receiver have to be *exchanging* all that cruft though, but that's what they pay to avoid exposure to traffic analysis. The key to the transmission remains, however, the seed to the pseudorandom transmission.
From here we get his asymmetric capture/ignore differential between the eavesdropper and the receiver.
The problem is, in the real world, it's unrealistic for each theoretical communication channel to simultaneously occupy all bandwidth that they might eventually use--especially since the number of possible connections in a network scales exponentially for each additional member! As always in computer science, we need to find a way to convert a high order problem into a fixed expense, O(1).***
So Rabin's solution was to centralize the entropy source. But a central entropy source has to be used differently--the PRNG key can't be used as the message key, because the sender with the message is no longer the generator with the seed. Furthermore, if XOR is be used, entropy cannot be continually shared among all the active sessions, since repeatedly XORing the same entropy against different data compromises the security of the entire system. So what Rabin did was presume the two sides could exchange, not the seed to the PRNG, but a set of "counter times" at which to extract a subset of entropy from the communal pile. Every individual stream would probabilistically negotiate a unique and separate random stream of entropy culled from the global shared pool. This shared key would grant the sender and the receiver the ability to communicate with eachother, but could never independantly decrypt the datastream. Without the "private" reduction from the
"public" shared entropy source, the key would provide no assistance in decrypting the data--and since the data was essentially XOR'ed against a unique set of random data, the data would indeed be uncrackable, because the eavesdropper didn't copy all the necessary pieces.
What's to prevent this copying? "The data stream for the shared entropy is too large."
This is apparently empirically untrue. Solar entropy was brought up as a possible source of shared entropy, with the immediate rejoinder that NASA et al. have no problem storing *vast* amounts of data from the Sun. I heard numbers as large as an exabyte a day of data storage, though I'm sure (I Hope!) that's a gross exaggeration. 24TB a day is easily within reason, however, and 24TB / 24 hours / 60 minutes / 60 seconds leads to a stream of data that reaches 266MB/s.
Standard hardware isn't exactly built to parse data quite that fast, even though that's well within the boundries of full-time recording capacity. But there's no actual need to continually record, since as long as an eavesdropper is looking for interesting things to pull off the wire, they can immediately begin recording from the global datastream whenever they see something being XORed through it.
Essentially, everyone's sharing the same chaff pool, which is moderately interesting.
What's most interesting is the fact that there's an asymmetric function buried in this, and that's Discrete Time. Standard analog time can be considered the "standard" clock; Discrete Time is the beat of the global entropy pool sending up a new value. If one knows the right data at the right time(which segments to use as XOR values), very little expense needs to be levied to discover the plaintext. If one eventually finds out the right data, but much later, a relatively extreme expense needs to be paid to determine the historical value of the cost.
A major possible attack, of course, is subversion of the central source of data. Implementations that use sequential chunks, instead of randomly plucked bits, would be pretty vulnerable to a central source that *looked* random but actually provided significant information to the end listener.
On the flip side, there's a very good question on what a pseudorandomly selected subset of a truly random bitstream qualifies as. Pseudorandom? No--there's no seed that will reveal those bits; one tenth of thermal noise is still thermal noise. Random? Well, they were selected by a predictable function from a non-secret source. Perhaps they're pseudo-pseudo-random?
Hope this analysis helped some of you understand.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
* Pseudo Random Number Generator: a function that converts a fixed set of bits into an infinitely large set of predetermined but statistically random numbers)
** XOR: Exclusive OR; a trivial and reversable operation that scrambles data on a bit by bit basis. XORing something with random data once results in random data; XORing it again with the same random data results in the original content.
*** O(1): Order 1 -- No matter how many items in set N, the task will only be done once.
"Bad security is better than no security. With bad security, you *think* you're safe. With no security, you know you aren't."
A system using 128 Bit WEP thinks its secure. A system using 0 bit WEP uses IPSec* and actually is.
Yours Truly,
Dan Kaminsky, CISSP
DoxPara Research
http://www.doxpara.com
* Yes, IPSec is an utter horror to configure. It manages to work, which is more than I can say for WEP!
> Kind of like CISCO with their patent on NAT
Cisco's had to deal with some pretty nasty patents being lodged against it; as far as I've seen, they've not gone out and actively used so-called "nuclear" patents(for their MAD capacity) as a method of extortion.
I don't expect them to start.
--Dan
A while ago, Slashdot linked to a story about what I feel is truly the most interesting model for 3D fabrication: Ice.
Much as the military has been pushing for the ability to deliver damage with energy instead of ammunition(because ammunition requires supply lines, separation of parts, and so on, while power simply requires any of a thousand sources), ice fabbers only require water to do their work. In my mind, the temporary nature of the material(which can even be three dimensional and thus reflective of its internal structure!) is outweighed by the near-zero marginal costs and surprising flexibility of such a device.
This company seems like they're just trying to tweak manufacturers into making noises(thus validating them to VCs who will give them money). It's like the old obsession over plastics, only spoofed into the P2P/Napster/No-Money-Economy model. The sheer coolness of arbitrary ice sculptures belies the fact that very few materials build correctly layer-by-layer--in other words, since your materials are limited, you can't go off and download a car or even a rolex--the parts won't last!
Arbitrary chimeras will come before arbitrary rolexes. Creatures are self-assembling, rolexes aren't.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
I wrote about this some time ago. (Actually, I devoted about four months of my life to writing about it, which never went anywhere. Thus, Dan Learns The First Rule Of Design: If Thou Can't Code, Nothing's Gonna Change :-)
Details available at http://www.doxpara.com/cluehunting.html.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Kudos to Jamie for investigating this further; the following was my original submission on this topic:
=======
The mind boggles. Police have apparently raided a student's dorm room due to his participation in a heavy metal music inspired gaming clan, "Bled For Days." The article goes to some length not to mention the exact game, including ominous references to a "war-like" "game of chess" where "it's not like we were going to kill you or anything". The game in question, of course, is the seminal Humans vs. Bugs vs. Yellow Psychic Aliens wargame, Starcraft. The presence of a web page listing in-game rivalries was apparently taken for death threats. For all the talk of "children" being unable to differentiate fake violence from the real thing, it seems to me that "adults" were the ones breaking into someone else's home, carrying loaded weapons, confiscating expensive goods while availing themselves of the opportunity to search for anything more valuable(i.e. drugs).
As hilariously pitiful as this seems, there's a real problem here. The tragedy is that, sooner or later, the credibility of authorities trying to fight real computer crime will be so stretched that even when society desperately requires their intervention, the police will find themselves unable to get even the slightest shreds of voluntary cooperation. A bizarre and ultimately truly dangerous attitude, the apathetic chuckle, has spawned over recent years by Zero Tolerance(and apparently, Intelligence, Accountability, or Political Responsibility) policies; the exact policies that have lead to first graders being suspended for pointing chicken at eachother and being expelled for kissing a girl on the cheek. People are willing to quickly accept these ridiculous and flagrantly neglectful abuse of power because "it's funny to laugh at...but I can't do something about it, isn't that someone else's job?"
This threatens the core legitimacy of what really are genuinely critical services; the police, the school, and the administrators all become jokes, not to be taken seriously. The immediate reaction my friends had to this incident at Kent State was, "The last time police at Kent State didn't understand what the students were up to, somebody won a Pulitzer Prize". Since the most damaging effect of any computer security violation is the long term degradation of trust in a given service, the ignorance these busts show eventually makes it harder to actually control and address genuine security issues, such as DDoS attacks. Instead of simply laughing and moving on, what can we, as a community do to prevent these kind of occurances in the future? Would something as simple as a confidential "reality check" group of experts, made available to law enforcement as consultants, be helpful? Would a set of guidelines, peer reviewed by the community, be useful? Instead of cursing the darkness, how can we praise the light?
CDA, known to old school net rats as the Communications Decency Act, being christened the new title for MP3 CDs?
No, worse:
CDA, better known to me as Compress Da' Audio: The first major MP3 ripping group that publically released tracks and (I believe) albums too.
The mind boggles.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Jesus! For Heaven's sake, I was just making a Goddamn Joke! Holy Mother Of All That Is Holy, I fear for the souls of this Heathen Humorless Wretch of a Discussion Forum!
(Anyway, saying "Billion Dollar War Chest" MS is going down in six months--like the Slashdot headline implied--is more ridiculous than even this quote. Of course, that's not what ESR said, but that's what we saw.)
--Dan
"God is Dead." --Nietzche
"Nietzche is Dead." --God
My point is, if you have to check to see if *your* version of 5.6.0 is the same as the dangerous version of 5.6.0, that version number just lost a hell of alot of relevance and is essentially meaningless.
--Dan
Umm, you seem reasonably intelligent, would you mind explaining how you got my desire for unique version numbers to mean "I want no fixes"?
--Dan
Is it really too hard to read the errata?
YES! It IS! It's too hard for me to read the source code to every app I run. I admit it. I want to trust Theo. I want to believe his prying eyes are protecting me from danger. I don't *want* to have to go diving into the code he writes or even the fixes he claims when a new vulnerability comes out. I want to know: Is this the exact same code that is vulnerable everywhere else? Then upgrade. Is this NOT the exact same code, and therefore I should check the Changelog?
I'm not asking alot. I'm merely asking the question: What do version numbers mean, if they *aren't* snapshots of code?
--Dan
Actually, that's pretty interesting! Here's my output on OpenBSD for Sparc. Note the lack of "Locally Applied Patches", which I appreciate.
/usr/libdata/perl5/sparc-openbsd/5.6.0
/usr/local/libdata/perl5/sparc-openbsd/5.6.0
/usr/libdata/perl5
/usr/local/libdata/perl5
/usr/local/libdata/perl5/site_perl/sparc-openbsd
/usr/libdata/perl5/site_perl/sparc-openbsd
/usr/local/libdata/perl5/site_perl
/usr/libdata/perl5/site_perl
/usr/lib/perl5/site_perl
Still, I question if the version number should stay stable. Suppose, for a moment, that the rest of the world finally discovers major holes in 5.6.0. Should OpenBSD administrators have to root around the Changelogs to realize they're running a safe build? Wouldn't it be better for them to be running 5.6.0_OB2.7 and see that, heh, the Changelog shows that the new stuff protects them?
===
$ perl -v
This is perl, v5.6.0 built for sparc-openbsd
Copyright 1987-2000, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=openbsd, osvers=2.7, archname=sparc-openbsd
uname='openbsd'
config_args='-Dopenbsd_distribution=defined -dsE'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O2', gccversion=2.95.2 19991024 (release)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=true
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, usemymalloc=n, prototype=define
Linker and Libraries:
ld='ld', ldflags =''
libpth=/usr/lib
libs=-lm -lc
libc=/usr/lib/libc.a, so=so, useshrplib=true, libperl=libperl.so.6.0
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags=' '
cccdlflags='-DPIC -fPIC ', lddlflags='-Bshareable '
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under openbsd
Compiled at May 5 2000 12:35:29
@INC:
.
===
(Why was there bash in your shell?)
/bin/su, with a mod that captures the root password. The advice to never log in as root, and rather to su to it, is thus rather dangerous.
Because I wanted command completion. What, you think sh is the height of security? Among other things, *any* shell can be trojan'd to attack replace su, or even
You are correct, of course. Most things shouldn't be done as root. I could theoretically have checked versions without it. This is somewhat on the order of a spelling flame, but I'll take it in stride.
As for my qualifications, feel free to scan my BugTraq posts, and thank you for helping to prevent my ego from growing too large.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Meow:
Yes, I can definitely hunt down the changes, and Theo is well within his rights to change the source. Hell, I'm thrilled he's fixing problems.
But should I have to check a changelog to know there's a change?
That's the bottom line question. Should not a version reflect a snapshot of code? Should not I be able to trust a given codebase by its version alone, rather than have to audit the source by hand?
If a version *doesn't* refer to a snapshot of code...well, what does it refer to?
--Dan
Yes, alot of other distributions do it.
Now, why would I put the question to the number one distribution known for doing it right, when everybody else does it to?
To redefine that which is known as "doing it right", so we don't get any more Debian Secret Backported Bugfixes.
:-)
--Dan