3 ms·

Hm, from the reading, it seem he was pretty careful to not do any harm, but still, is this type of practical research actually legal?

richbell 3y ago
It depends on the company. Many companies have bug bounty or vulnerability disclosure programs that explicitly guarantee safe harbor+protections for researchers. However, not all organizations are happy to be contacted about security issues. Sometimes doing the right thing can still result in (threats of) legal repercussions. https://arstechnica.com/tech-policy/2021/10/missouri-gov-calls-journalist-who-found-security-flaw-a-hacker-threatens-to-sue/ https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal...
- azeemba 3y ago
  The bug bounties are usually pretty clear that you aren't allowed to make changes in the production systems. Here they made many changes - including changing the name of a release. The bug bounties also prefer seeing a working attack instead of theoretical reports. So not sure how they could have tested their attack in this situation without making actual changes.
  - richbell 3y ago
    It depends. Sometimes companies only permit testing in specific test domains, other times they permit it as long as your activity is clearly identifiable (e.g., including a custom header in all request). It does seem like walking a precarious tight rope.
richardwhiuk 3y ago
Essentially, generally, no. Once you've discovered a security hole, exploiting it to see how much access you can get is generally frowned upon.
- Twirrim 3y ago
  I know Marcus, the guy they mention that first caught the problem. He had no end of trouble getting Meta to acknowledge the severity of what he'd found, and they just constantly went radio silence on him, in between not really understanding the problem. I ended up having to reach out to someone senior I knew in the security org there to get them to swoop in and pick up the report, before it got any actual traction (I'd worked with that senior security engineer in a previous job).
  - mike_hearn 3y ago
    One may suspect that they do know, but if you widen the scope of bug bounty programmes to encompass open source project supply chain then your programme immediately turns into a dollar piñata. For a long time Apple didn't have a bug bounty programme at all. This wasn't because they didn't care about security. It's because their own internal audits were generating enough reports to saturate the available capacity for bug fixing, so paying for more reports would have just duplicated work. Generally this is the pattern at big tech firms: you want to turn your internal security teams to a problem for a while before starting to pay out for a new class of bugs. But of course it's hard to descope a problem from bug bounties, it looks very bad.
    - richardwhiuk 3y ago
      That sort of suggests you are under-funding your fixing capability.

richbell 3y ago

It depends on the company. Many companies have bug bounty or vulnerability disclosure programs that explicitly guarantee safe harbor+protections for researchers. However, not all organizations are happy to be contacted about security issues. Sometimes doing the right thing can still result in (threats of) legal repercussions. https://arstechnica.com/tech-policy/2021/10/missouri-gov-calls-journalist-who-found-security-flaw-a-hacker-threatens-to-sue/ https://arstechnica.com/tech-policy/2021/10/missouri-gov-cal...

azeemba 3y ago
The bug bounties are usually pretty clear that you aren't allowed to make changes in the production systems. Here they made many changes - including changing the name of a release. The bug bounties also prefer seeing a working attack instead of theoretical reports. So not sure how they could have tested their attack in this situation without making actual changes.
- richbell 3y ago
  It depends. Sometimes companies only permit testing in specific test domains, other times they permit it as long as your activity is clearly identifiable (e.g., including a custom header in all request). It does seem like walking a precarious tight rope.

richardwhiuk 3y ago

Essentially, generally, no. Once you've discovered a security hole, exploiting it to see how much access you can get is generally frowned upon.

Twirrim 3y ago
I know Marcus, the guy they mention that first caught the problem. He had no end of trouble getting Meta to acknowledge the severity of what he'd found, and they just constantly went radio silence on him, in between not really understanding the problem. I ended up having to reach out to someone senior I knew in the security org there to get them to swoop in and pick up the report, before it got any actual traction (I'd worked with that senior security engineer in a previous job).
- mike_hearn 3y ago
  One may suspect that they do know, but if you widen the scope of bug bounty programmes to encompass open source project supply chain then your programme immediately turns into a dollar piñata. For a long time Apple didn't have a bug bounty programme at all. This wasn't because they didn't care about security. It's because their own internal audits were generating enough reports to saturate the available capacity for bug fixing, so paying for more reports would have just duplicated work. Generally this is the pattern at big tech firms: you want to turn your internal security teams to a problem for a while before starting to pay out for a new class of bugs. But of course it's hard to descope a problem from bug bounties, it looks very bad.
  - richardwhiuk 3y ago
    That sort of suggests you are under-funding your fixing capability.