Hacker News Reader

Comment by tptacek | Hacker News Reader

I think the subtext of CFAA is that the law believes it shouldn't have to tell you not to try to pry credit cards out of someone else's website. I'm not speaking normatively, I'm just telling you the way it is.

I think publicized security research --- which I obviously support --- has created expectations among technologists that either weren't intended, or were more wishful than the facts support (lots of researchers, most probably, think the CFAA is a bad law and are happy to set expectations premised on its illegitimacy, but: see Wesley Snipes for how that turns out).

If there weren't lots of public security research, I don't think you'd really have to tell developers not to go looking for vulnerabilities.

Again, and to be clear: if it's something running on your own machine, or a machine you own, go nuts.

View on HN

This is an important caveat; the issue at hand is looking for vulnerabilities on other people's machines, not in other people's software. If it is running on your machine (read: not SaaS), reverse away.

Releasing the exploit, on the other hand, is a different story (don't do that)

Is releasing the exploit problematic you think? In a legal sense?

I am not a lawyer, but for example, cracking a game is against the EULA and likely illegal. Releasing a cracker is much worse.

It depends on how you got the bug. If you test something on your own machine and find a vulnerability, you're fine publishing it (modulo you may be civilly liable if a binding contract prevents you from doing that kind of research --- a pretty rare case). If you find a vulnerability in someone's SAAS application running on their server and publish it, the publication itself probably isn't unlawful --- the problem you'll have is that you've also published evidence that you committed a federal crime.

To be clear: I meant releasing an exploit, not a bug.

Per my understanding, there is a distinct difference between releasing a bug (that you found in software on your own machine) vs. releasing a tool that exploits that bug.

I don't really think that's true either, though obviously it has to be at least a little riskier to release an exploit; like, a fact pattern that has actually happened before is "someone writes an exploit, and a friend uses that exploit to steal a bunch of credit cards; the exploit writer is culpable as a co-conspirator". But just releasing an exploit by itself is I think --- NOT A LAWYER, TALK TO A LAWYER --- pretty safe.

This also comes up in discussions about exploit markets: you can sell an exploit to a bounty program, or to Zerodium or whatever, but people always think you can make more (for instance, if it's some dumb SQLI, more than the $0 the public exploit markets will pay you for it) by selling "on the dark web". But if you're selling a bug that only lets you exploit some specific SAAS application "on the dark web" to some anonymous criminal (or someone a jury will think you should have known was a criminal), you're taking a chance that a prosecutor will make a case that you took money to facilitate a specific crime that they're now going to charge you with.

Yeah, I’m not totally certain, and I suspect intent matters.

My example was that cracking a game is illegal, but releasing a cracker is much much worse.

And, again, IANAL.

Part of it is that there's a specific law criminalizing copy protection bypasses (the DMCA), but it also includes an explicit exemption for security research.

Reply on news.ycombinator.com