5 ms·

> 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 info

by bradly 5y ago

> 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?

tptacek 5y ago
Here you go: https://clinic.cyber.harvard.edu/files/2020/10/Security_Researchers_Guide-2.pdf https://clinic.cyber.harvard.edu/files/2020/10/Security_Rese...
- bradly 5y ago
  Thank you for the link, but is it something you expect all non-infosec engineers to know?
  - tptacek 5y ago
    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.
    - borski 5y ago
      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)
      - SCHiM 5y ago
        Is releasing the exploit problematic you think? In a legal sense?
        borski 5y ago
        I am not a lawyer, but for example, cracking a game is against the EULA and likely illegal. Releasing a cracker is much worse.
        tptacek 5y ago
        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.
        borski 5y ago
        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.
        tptacek 5y ago
        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.
  - ivraatiems 5y ago
    Yes, I think it is reasonable to know what's appropriate and what's not. I'm not in infosec.
  - anonzzzies 5y ago
    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.
- deleted 5y ago
  [deleted]
- severine 5y ago
  Great link. I posted it, so if people wants to discuss it: https://news.ycombinator.com/item?id=30710885 https://news.ycombinator.com/item?id=30710885

by bradly 5y ago

> 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?

tptacek 5y ago

Here you go: https://clinic.cyber.harvard.edu/files/2020/10/Security_Researchers_Guide-2.pdf https://clinic.cyber.harvard.edu/files/2020/10/Security_Rese...

bradly 5y ago
Thank you for the link, but is it something you expect all non-infosec engineers to know?
- tptacek 5y ago
  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.
  - borski 5y ago
    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)
    - SCHiM 5y ago
      Is releasing the exploit problematic you think? In a legal sense?
      - borski 5y ago
        I am not a lawyer, but for example, cracking a game is against the EULA and likely illegal. Releasing a cracker is much worse.
      - tptacek 5y ago
        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.
        borski 5y ago
        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.
        tptacek 5y ago
        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.
- ivraatiems 5y ago
  Yes, I think it is reasonable to know what's appropriate and what's not. I'm not in infosec.
- anonzzzies 5y ago
  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.
deleted 5y ago
[deleted]
severine 5y ago
Great link. I posted it, so if people wants to discuss it: https://news.ycombinator.com/item?id=30710885 https://news.ycombinator.com/item?id=30710885