Hacker News Reader

Comment by bradly | Hacker News Reader

> I don't think this person understands where white-hat boundaries are

Not that ignorance of the law is an excuse, but when are software developers not in infosec supposed to be taught these limits?

View on HN

Here you go:

https://clinic.cyber.harvard.edu/files/2020/10/Security_Rese...

Thank you for the link, but is it something you expect all non-infosec engineers to know?

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.

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.

Yes, I think it is reasonable to know what's appropriate and what's not. I'm not in infosec.

I work in banking and when probing (internal) api’s of partners/clients you accidentally find stuff; they are all very broken and it is normal to find bugs and holes while just probing the use of the api; not trying to find issues. Not sure how to prevent that and no I don’t know how far I can go; I know I cannot do my integration work if I do not do it. Not sure how others can. I would never report bugs to them though; I am old and cynical; software is very broken (especially since the Big Move to modern tech; I see more and more ‘out facing’ (still internal) APIs in banks written in js (not blaming the language but blaming the vast amount of cheap and untrained coders in that language niche); we used to write those apis against the real ‘basement’ backends, now they do (usually hiring an external consultancy corp like cap Gemini for big $$$ who then has it done by their offshore teams) and it is a freakin’ horror show; same for insurers); I assume going in I can somehow query all creditcard numbers in there, so no need to tell them that.

Great link. I posted it, so if people wants to discuss it: https://news.ycombinator.com/item?id=30710885

Reply on news.ycombinator.com