5 ms·
"Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment.
by pweissbrod 5y ago
"Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment. The information should include the name of each targeted software, the commit information, purported name of the proposer, email address, date/time, subject, and/or code, so that all software developers can quickly identify such proposals and potentially take remedial action for such experiments."
That sounds more than reasonable as a request to make amends.
The article said that finding all this code is a real problem. If UMN and the students involved are contrite that should be easy to fulfill.
- fluidcruft 5y agoI actually disagree as it would expose which maintainers accepted these sorts of patches and that can have implications for their reputations and livelihood. Beyond that, this is just "Open Source software can be vulnerable to bad actors (News at 10)".
- sokoloff 5y agoThat's true to a point, but hiding that information is arguably (and in my estimation) worse. "We better not look for other incidences of this nefarious behavior because it might create a small amount of collateral damage. Better to leave those patches unexamined."
- fluidcruft 5y agoUMN has already said they've opened an investigation?
- sokoloff 5y agoThere seems to be transparency value in having a different organization do the investigation than made the original judgment to approve the research. Maybe there's an "internal affairs" equivalent that we'd trust, but this reads to me like "UMN made an error in approving this research but don't worry because UMN is now going to look into it."
- fluidcruft 5y agoSure, that's entirely reasonable. But that's not what the Linux Foundation is demanding, apparently.
- yndoendo 5y agoIs it your belief that maintainers should be viewed as automatons, impervious to mistakes, like how many view the service industry? Maintainers are humans, flawed just like us all, good maintainers choose to accept and learn from their gaffes.
- fluidcruft 5y agoNo, my belief is the IRB would only waive consent if this sort of public disclosure is not allowed. Naming-and-shaming is not a valid research goal. Improper research results in censure and exclusion from the scientific corpus, not full public disclosure.
- deleted 5y ago[deleted]
- elliekelly 5y agoBut let's also keep in mind these are humans, flawed and all, who were experimented on without permission. Ethical (and consensual) experiments would never reveal the identity of the participants and their exact reaction(s) under the experimental conditions. Just because the experiment started without any ethical considerations doesn't mean all ethical considerations should be ignored with respect to the "data" collected by the experiment.
- loeg 5y agoI don't believe the Linux kernel community would perceive the information in that way. Everyone is vulnerable to this kind of bad faith submission; gregkh and others seem to understand that.
- fluidcruft 5y agoIndividual kernel maintainers should probably be able to contact the IRB to inquire whether they were personally enrolled in the study. The IRB may reply to that, or they might ask the study to notify all enrolled participants individually. Those individuals could then on their own publicly disclose the fact that they were enrolled. But I don't see why the general public has any need to know anything and it's unreasonable to make the demand.
- bluGill 5y agoI can't think of any way other than what the kernel maintainers are already doing. I doubt those involved actually tracked the information needed separately, and even if they did I wouldn't trust them to have tracked everything.
- nash 5y agoThe paper claims they reverted all the patches at the time. Obviously they did not.
- gowld 5y agoHow is it "Obviously"?
- dylan604 5y agoI love this tactic. To me, if this was an actually controlled experiment, the last step in the experiment would be to undo the bugs they intentionally created. If they did not, this would definitely be sabotage. Based on that, they should have no problem being able to identify what they did. It's kind of a catch-22 for the UMN.
- dbcurtis 5y agoIndeed. If UMN can't tell how to undo the damage, then it is intentional sabotage, and should be prosecuted as such.
- squarefoot 5y agoThis post might give a hint on where to look to find who would probably benefit from sabotaging Linux security. https://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html https://www.mail-archive.com/cryptography@metzdowd.com/msg12...
- dylan604 5y agoFiction writers would have a hard time making something like this up. But at the same time, of course this is what happens. It's one of the oldest plays in the book to infiltrate the group you want to subvert, and then make changes from within so it is no longer a threat.
- nine_k 5y agoIt's like running an experiment by adding a venom in water supply, with a possible later remedial action of offering an antidote. They seemingly had some success with the first step, until this was duly noticed. The experiment itself may be a bad idea, but it's a good, useful wake-up call.
- pweissbrod 5y agoAgreed. It's a cool idea. It's not really computer science as much as a penetration test involving humans and processes. Of course without any semblance of prior consent it isn't quite sabotage but definitely outside the realm of ethical