3 ms·

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 p

• 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.
    • foldr 6y ago
      >Well that basic ethical no-no is going to make it impractical for anyone to do [x] There's tons of potentially useful research that's impractical because of ethical considerations. Just think of all the incredibly useful medical research that could be done in the absence of ethical constraints! In the end that's just tough cookies. If you can't do your research ethically then you can't do it. Period. If you really want to help the Linux kernel, offer your time as a patch reviewer. That would achieve far more than any attempt to deceive and embarrass others with pointless "research". (I say that it's pointless because the results are antecedently obvious – of course you can deceive reviewers if you spend enough time and effort on it.) In your ethical world, it seems that people who offer their spare time to review kernel patches are "negligent", while people who do nothing but carp from the sidelines are heroes. In my view, the situation is exactly the opposite.
• luckylion 6y ago
  > Do any security researchers ask permission before finding other vulnerabilities in random open source code? I have never observed this. That's not what happened. Nobody is asking (or is expected to ask) when they look for vulnerabilities. The researchers were trying to introduce vulnerabilities. Had they only looked at the tools that maintainers use and given those a good shake to see whether an attack vector is lurking there, everybody would have been happy. > 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. The likely consequence of that would be maintainers shutting down public contributions because nobody has time to deal with automated submissions from scripts that are bounty hunting.
  • lrvick 6y ago
    Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities with no intention of using them. There also might be middle ground where people submit benign code that clearly demonstrates highly risky behavior the reviewer should have noticed. Maybe I introduce code that covertly exfiltrates memory from a non sensitive address, but it is enough to understand I could have chosen a more sensitive one. Or code that simply executes a ping to my server, etc. Anyway, the point is, intent matters.
    • luckylion 6y ago
      > Trying to submit a vulnerability they had no intention of actually allowing to ship to the public is not that different from finding serious vulnerabilities with no intention of using them. It is different in that looking for vulnerabilities in code only costs you time, trying to introduce vulnerabilities costs the other person's time as well, and often producing vulnerabilities scales much better, e.g. you could write some tool that mails them patches, while they'd have to individually judge the merits. > There also might be middle ground where people submit benign code that clearly demonstrates highly risky behavior the reviewer should have noticed. I don't think so. The issue isn't so much with trying to get code reviewed, it's with wasting people's time. That they did so by trying to introduce bugs is just the icing on the cake. If you get consent, you can have all your tests and strengthen the infrastructure, without eventually breaking the system because every other "researcher" submits bogus code every day in hopes to have one slip through and write a paper on how they proved that project x is exploitable. I've noticed the same with general bounties. When you have a security.txt or are on hackerone etc, you'll get lots of useless automated submissions that are wasting your time. Once that happens, you'll either shut down the program, or start rejecting reports automatically which includes the possibility of a false positive.