4 ms·

> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibi

> If we don't somehow make it socially acceptable to let any security researchers conduct the required social engineering to test supply chain attack susceptibility of OSS maintainers without tipping them off in advance, dangerous state actors -will- continue to do it and -not- tell anyone when they are successful. What's the result of that? Lots of known bad patches being sent in, wasting everyone's time, because now every researcher finds "do they spot my intentional bugs" as an easy way to get something published? There's no reason why you can't run these studies with their consent. Ask the maintainers. "But it will tip them off", yeah, in a "they would be aware that somebody might send faulty code at some point in the future" kind of way, which they certainly already are. To get consent, you don't need to tell them exactly when you will be sending it, who will be sending it, or what exactly it would be. If it did put them into permanent hyper-vigilance mode, then ... goal achieved?

lrvick 6y ago
This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future. Maybe this helps to raise awareness, even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade. I don't really know what purpose this would serve other than making people realize everyone got the same message, and everyone going back to being just as complacent as they were... but now we technically informed it was going to happen so it is fine now? Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this. I feel like this type of thing should be assumed to come from whitehats or blackhats always. I for one teach everyone around me that if they can compromise me, they can have the bitcoin private key I leave on my personal systems. They earned it, and I will see that outgoing transfer on that address as a canary. I have been compromised a couple of times in this game when multiple people colluded, and it only leveled up my opsec and threat model. Good. IMO we should double down and raise grants to offer as bug bounties for people that successfully get potentially malicious code past code review in majorly depended on open source projects. We need to encourage a -lot- of this behavior to train people.
- foldr 6y ago
  > even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade So...contrary to what you suggest in your first paragraph, all you need to do is send out a handful of warning emails at the appropriate juncture. What’s the problem? For sure you shouldn’t be submitting malicious code to a project without forewarning. That's just a basic ethical no-no. Even if you were right that this kind of unethical research somehow had beneficial results, the ends wouldn't justify the means.
  - lrvick 6y ago
    Well that basic ethical no-no is going to make it impractical for anyone to do open source supply chain integrity evaluation at scale because getting permission from thousands of people to do sweeping tests is impractical and warns everyone for a short period making it an inauthentic scenario. It will make it hard for things to improve, so millions will continue to get hacked due to supply chain attacks that almost no one is doing anything about. At what point does the ethical fault of negligence become so great that intervening to stop said negligence without consent becomes justified? We don't have much in the way of well defined law in this area yet, and it may take a long time to catch up. I suggest the lesser evil in the short term is to allow maintainers to suffer occasional mild embarrassment from time to time because they merged bad code. They get a valuable lesson out of the deal with no one getting hurt, no privacy violated, etc. If a maintainers don't want to review code with the understanding it could be malicious, then they have the right to never review or merge anything. All code contributions should be considered potentially malicious. Now, we also don't want to see repos bombarded with bad commits either if we can help it. Maybe a middle ground could exist where open source authors can signal a willingness to be tested once a year, and can signal if a test for this year has happened already. I think most projects would not do this, but it might be a step towards wide consent long term if someone cares to build such a system. In the decades before that though, there are not really any good options. If someones house is on fire and it has the potential to burn the neighborhood down, I don't imagine you should be faulted for doing what is required to put it out. Emergencies sometimes warrant dispensing with niceties. I think the supply chain attack risk is approaching emergency levels at this point. Negligence is the norm.

lrvick 6y ago

This suggestion, if taken to it's logical conclusion in my mind, I should send an email to every open source project maintainer ever warning them that at some point in the future I might attempt to validate their 2FA settings or try to submit mildly malicious code to them to test their ability to do code review at some unknown date in the future. Maybe this helps to raise awareness, even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade. I don't really know what purpose this would serve other than making people realize everyone got the same message, and everyone going back to being just as complacent as they were... but now we technically informed it was going to happen so it is fine now? Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this. I feel like this type of thing should be assumed to come from whitehats or blackhats always. I for one teach everyone around me that if they can compromise me, they can have the bitcoin private key I leave on my personal systems. They earned it, and I will see that outgoing transfer on that address as a canary. I have been compromised a couple of times in this game when multiple people colluded, and it only leveled up my opsec and threat model. Good. IMO we should double down and raise grants to offer as bug bounties for people that successfully get potentially malicious code past code review in majorly depended on open source projects. We need to encourage a -lot- of this behavior to train people.

foldr 6y ago
> even though in reality I will do tests like this to a tiiiiny percentage of repos over the next decade So...contrary to what you suggest in your first paragraph, all you need to do is send out a handful of warning emails at the appropriate juncture. What’s the problem? For sure you shouldn’t be submitting malicious code to a project without forewarning. That's just a basic ethical no-no. Even if you were right that this kind of unethical research somehow had beneficial results, the ends wouldn't justify the means.
- lrvick 6y ago
  Well that basic ethical no-no is going to make it impractical for anyone to do open source supply chain integrity evaluation at scale because getting permission from thousands of people to do sweeping tests is impractical and warns everyone for a short period making it an inauthentic scenario. It will make it hard for things to improve, so millions will continue to get hacked due to supply chain attacks that almost no one is doing anything about. At what point does the ethical fault of negligence become so great that intervening to stop said negligence without consent becomes justified? We don't have much in the way of well defined law in this area yet, and it may take a long time to catch up. I suggest the lesser evil in the short term is to allow maintainers to suffer occasional mild embarrassment from time to time because they merged bad code. They get a valuable lesson out of the deal with no one getting hurt, no privacy violated, etc. If a maintainers don't want to review code with the understanding it could be malicious, then they have the right to never review or merge anything. All code contributions should be considered potentially malicious. Now, we also don't want to see repos bombarded with bad commits either if we can help it. Maybe a middle ground could exist where open source authors can signal a willingness to be tested once a year, and can signal if a test for this year has happened already. I think most projects would not do this, but it might be a step towards wide consent long term if someone cares to build such a system. In the decades before that though, there are not really any good options. If someones house is on fire and it has the potential to burn the neighborhood down, I don't imagine you should be faulted for doing what is required to put it out. Emergencies sometimes warrant dispensing with niceties. I think the supply chain attack risk is approaching emergency levels at this point. Negligence is the norm.