Linux 5.13 Reverts and Fixes the Problematic University of Minnesota Patches
phoronix.com
phoronix.com
If only they had contacted the Linux Foundation ahead of time to get permission, and set up terms, like a real pen-test. Then work could be done on detecting, and preventing these sorts of attacks, maybe resulting in a system that could help everyone. At the very least a database for security researchers that are registered, but unknown to maintainers, where they could store hashes of bad commits. Then a check if any of those commits made it through. I know the kernel makes use of rebasing, so that might not be the best approach technically, but something like that. To ease the pain of wasting developers time, sponsors could put up money that the maintainer gets if they catch it, and maybe a smaller amount if they have to revert it.
EDIT: if the Linux Foundation said no, they could have tried another large open source project with a governing body, Apache, Python, Postgres, Firefox, etc. It wouldn't have been as flashy and high profile, but it would have still been the same research, and odds are you would find at least one project willing to participate.
Granted, In the case of linux, it might make more sense if it were the combination of the Linux Foundation & Linus. It's their project, they can subject their volunteers to any tests they want. It may drive away some volunteers, but wether to take that risk or not, is up to the project to decide. For something as big as the kernel they may decide to get permission from the individual maintainers, maybe even limit the research to only the subsystems that agree to participate.
In any case, the point I'm trying to make, is that this kind of testing may be beneficial, if the project is aware of it, and agrees to it. Who gets to decide on behalf of the project, would depend on the hierarchy of each project.
Not really. Everyone knows this flaw exists, the interesting part is how to fix it. Did you read the "suggestions" the researchers made in their paper[1]? They're clueless.
It's like pointing out that buildings can be robbed by breaking their windows. No shit. What do you want to do about it?
[1] https://twitter.com/SarahJamieLewis/status/13848800341465743...
Signed, UMN Researchers.
Edit: Wait, the cops are here. We sincerely apologize for any harm our research group did to your business. Our goal was to identify issues with the windows on your buildings and we are very sorry that the method used in the “smashing windows to take cash” paper was inappropriate.
More like they posted on your facebook pro-<insert your kink here> messages. There's some value in grounding the analogy in reality.
> I think the cash theft is analogous to the dev time the researchers wasted.
That's a fantasy that developers would like to believe because they put an inappropriate valuation on the the time spent on software. The inability to face this, has been disturbing from the start.
If you're messing with someone's systems, or (as in this case) with someone's processes, you don't get to claim to be the good guy unless they agreed to it before the fact. It's not rocket science.
Fair enough. The kernel maintainers are probably much more aware of this than the average open source project. Maybe for some projects it would change their mindset from knowing that this could be happening, to knowing that this will be happening.
Maybe it's a pipe dream, but I have a feeling it could lead to discussions of "what could we have done to catch this automatically," which in turn would lead to better static analysis tools.
Edit: It would be about as useful as pen testing that includes social engineering. That is to say, everyone knows there are dishonest people, but they may not be aware of some of the techniques they use.
It did do that, at least twenty years ago. Static analysis tooling is a huge, active area of research and the kernel is frequently a target of that research. Ditto for other areas like language development (see the recent work on getting Rust into the kernel). If these students had tried making real contributions to those areas, I'm sure they would have been welcome. But that kind of work is difficult and requires real research and development, which these students aren't interested in and/or capable of. So we got this trash instead, and now hopefully you understand the harsh reaction to it.
I do wonder if they would have published if they didn't expect disclosure by angry Linux maintainers, i.e. if they really believe they were weakly successful. Generally, I think this is the type of finding that normally gets lost if there's no pre-disclosure.
True as far as it goes, but the most valuable failing research is that which fails to produce an expected positive result.
Next most valuable is failing to corroborate a novel hypothesis (which is probably what you meant).
When you get an expected result, you haven't learned much, regardless of whether you were (or should have been) expecting success OR failure (with the exception being getting more, or more accurate, data that narrows error bars).
We do know since the researchers have told the linux community, the university and IEEE what those patches where. Please do not spread further misinformation about the case.
Please read the IEEE statement and the full Linux TAB review.
https://www.ieee-security.org/TC/SP2021/downloads/2021_PC_St...
And for full disclosure, I'm one of the four authors of the original complaint to IEEE back in December about the research. I fully believe all the facts have been put forth and there is no reason to spread misinformation about the incident.
They wanted to prove that others are too trusting, they got exactly what they wanted: heightened suspicion to things that are normally expected to be done in good faith.
I understand that inside the academic world the status imparted by "researchers and students at a University" is significant and important. For those of us outside the academic world, it's prudent and has no downside for us to drop our perception of them below the floor you'll continue granting them.
But season this old recipe heavily with some “fuck around and find out” and things get pretty spicy.
[1] https://www.ieee-security.org/TC/SP2021/downloads/2021_PC_St...
And pointless?
Let's assume that most people are giving their opinions to their best knowledge. We shall be careful when telling someone to stop spreading misinformation as this is how fascism starts. "I am right, you are wrong, stop talking!"
Throwing around accusations of spreading misinformation to further your opinion in an argument makes it harder to call out real misinformation.
The fact that they didn't communicate _clearly_ with the kernel about exactly which patches this was about at the time when they announced their paper is extremely icky, and makes my sympathy for later misunderstandings/misinformation very limited.
The researchers conducting the research thinking this was a good idea, the IRB review process at the UMN, IEEE accepting the IRB exception after ethical concerns where raised, and the overreaction from gregkh on the LKML.
Hopefully there is a silver lining and we see better research collaboration between the kernel devs and researchers going forward. IEEE has a job to do around all of this going forward.
I don't think it was an overreaction. I think it was a very valid reaction.
However yes, review of the patches was proper but all this could have been done with less unfounded accusations from gregs side.
Really curious who makes unfunded accusations ...
And the resulting conversations between Aditya Pakki and Greg. Aditya was never part of the hypocrite commit research, accusing them for this is just bad.
Greg's concerns proved to be overblown, but at the time they were raised he had reason to believe them valid.
At the time, UMC had not "debriefed" the kernel maintainers they lied to in the "hypocrite commits".
And then Pakki didn't mention that these new patches were generated by a tool, and submitted a bunch of "nonsense" patches with no explanation.
What reason did GKH have to trust anyone associated with the "hypocrite commits" at that point?
(ps. don't think you deserve all the downvotes here...)
Yes, they are bad patches and the research is also questionable. But this is not bad faith nor malicious.
Do you want to take a moment and explain how your broken static anylizer isn't involved?
Or, y'know. Click on the profile.
I did click your profile, but this is a post about deception. Trust no one.
Here we saw the emperor go on a full war path against the entire place of origin of a couple of misguided individuals. Not a proportionate response.
The IRB is a gatekeeper, yes, but it is also a resource. You should be working with the IRB to make sure everything you are doing is above the board, because ultimately, if you do something unethical or harmful to individuals or society, that's still on you, even if you got your plan stamped by the IRB. You shouldn't have an antagonistic relationship where you use the vague and technically accurate but misleading descriptions of your research an an attempt to get a "get out of consequences free" card.
Which suggests an entirely new line of inquiry: testing IRB procedures to see whether unethical proposals will be approved if described in misleading terms.
While we're at it, we should check to see whether proposals ostensibly from people who are not faculty or students, or who perhaps don't even exist, are ever approved.
Regardless of the results, we can conclude that having to sign a statement promising to never do unethical research before submitting a proposal, and insisting on identity verification before proposals are reviewed, will lower the chances of unethical research proposals slipping through.
> Based on the overall positive reviews and the recommendation of all reviewers to accept the work, the PC did not discuss this paper during the online PC meeting; [...] When, after acceptance, the authors tweeted the abstract of the work in November 2020, several people expressed concerns about human-subject research featured in this work. At that time, the PC chairs discussed these concerns [...]. As a result of these discussions, the PC chairs asked the authors to clarify the experiments with the University of Minnesota Institutional Review Board (IRB). We now acknowledge that this offer was a mistake
Basically: they did not review it and once it was published and people complained, they reacted. What's the point of the PC then?
- Researchers submitted paper to IEEE.
- Researcher twitter about it.
- Tweet was deleted, because people pointed out it was bad humans subject researcher. (consent and deception)
- Other researchers not from UNM, filled complaints to IEEE.
- Researcher mislead (so far seems like) IRB, arguably IRB failed to do a job and just rubber stamped human subject research exemption, after research was conducted ...
- Paper got accepted to IEEE.
- Researchers push more patches to Linux kernel.
- Plonk email from Greg.
- UNM response latter indirectly blaming only researchers but not IRB.
- Paper get retracted from IEEE
- IEEE Response letter.
- We are here.
Maybe "believe" would be better used here? Knowing would mean to know precisely what each of these changes does and whether they open up new vulnerabilities and then having confidence that all is well. Gaining this confidence requires work. And unless you put that work in, you are left to trusting/believing.
(Edit: what I mean here is that the researchers could be totally nice and ethical people, but the Linux devs would still have to either take a risk by trusting them OR put in the work to check it all OR decide not to put in that work)
maybe the issue is we aren't using static analysis enough / don't have enough static analysis tools?
A thorough review of the IRB documents revealed potential problems in the description of the experiments, and concluded that insufficient details about the experimental study were provided to the IRB. [0]
[0]Read the above linked IEEE response latter.
> Investigation of these patches revealed that the description provided by the authors in the paper is ambiguous and in some cases misleading. The experiments do not provide convincing evidence to substantiate the main claims in the paper and the technical contributions of the work need to be revisited.
Interesting that they list ethical considerations added to the review process, but are not adding content quality considerations to the review process. I think that's at least as embarrassing to PC. You can say that they erred in assuming the uni covered the ethics review, but what are they doing if they're accepting papers without checking that the papers support their own claims?
This makes them invalid. Their entire claim is based on malicious code entering the kernel, not anonymous/fake name commits (which is a separate issue). If you take that away there is no actual paper, just a hypothesis which everyone already knew and thus does not warrant this much fanfare. They added nothing to the research field, bothered people with it while contributing to no-one but themselves.
This is what we around here now call "Diederik Stapelen" (since he is a infamous example here): faking you data, using people to do/in your work, presenting it as true and gaining from it. It is omnipresent in some fields and in my opinion should be met with severe repercussions as it damages everyone else who was not part of it.
Replace researchers with hackers, CIA, North Korea, China, etc. Do you still have the warm fuzzies?
The fact of the matter is they broke the trust and your expectation is that since they've been exposed they can be trusted again?
No, if anything the event has shown that additional vetting and layers of scrutiny might be needed to protect against bad actors in the future should they be malicious.
* I type good.
They lied to their IRB.
What evidence do you have that they're telling the truth now?
We should just trust the liars when they pinky swear to tell the truth? There's a certain saying about what you win when you play shitty games that comes to mind. Being deceptive causes people to lose trust in you.
Or, my personal favorite: fuck around, find out. UMN fucked around, now they're finding out.
Maybe the NCAA could organize competitive code reviewing leagues? I bet you would get e.g. a highly motivated Caltech team reviewing USC contributed patches, and vice versa.
Starting to feel like pen testing is a broken profession.
In general, the fury and seethe which this experiment inspired is amazing. IMO the real disgrace is not the experiment itself, but the response. The kernel developers need to stop being martyrs and playing blame games. They need to be rational and take responsibility for improving their own procedures. Because, if they didn't already have them, governments now have entire departments studying how to use deliberate vulnerabilities in open source projects, for military intelligence and other purposes. And they will not be deterred by the continued public flogging of the University of Minnesota.
I don't know if you've ever talked to one, but they take a real pride in their work, most make a pitiful salary in comparison to FAANG levels but they still do it because it is full of interesting challenges you can't find anywhere else.
UMN broke that trust. No one is asking the departements to close least of all the maintainers, but you have to understand that kernel devs are not a faceless machine. They spend their limited time on something that is used to make a prodigious amount of money, while never really getting any. In that context they are more than within their rights to be livid.
They do, and to a very largr extent the same exact overreaction happens in private orgs and we just get to see it when it's the Linux kernel. But at the end of the day, there was an overreaction, and it was public. Both the UMN and the kernel maintainers need to step up and make improvements now, and move forward with level heads.
Have any of the kernel maintainers acknowledged the primary concern behind the misguided research? That is, (quoting parent comment) "governments now have entire departments studying how to use deliberate vulnerabilities in open source projects"?
You must trust contributors to your project to some extent. If you don't extend some trust, you can't have contributors. That level of trust is then adjusted off that base level based on experience.
It is perfectly reasonable to drop someone below your base level of trust if they lie to you. This doesn't necessarily mean that the base level of trust needs to be adjusted.
In this case, the review process caught all the known harmful commits (which were from anonymous emails so recieved base level trust) and thus the base line level of trust seems to be working.
Here the "contributors" had done multiple commits and were coming from a university that had previously upstreamed several commits. There was and should be an expectation of trust because you can't scrutinize every commit for several hours (they just don't have them enough maintainers for it).
The real disgrace was the experiment. The response was fairly natural for humans with imperfect information being experimented on.
Please be more specific. How do you think the Linux kernel maintainers should improve their procedures to prevent clownshows like this in the future? No points for mentioning things that they already do or assuming infinite maintainer hours.
[0]: https://twitter.com/SarahJamieLewis/status/13848760502079406...
Since the Linux kernel is installed on many millions of computers, it is obviously pretty important that it doesn't have bugs in it. Certainly not malicious bugs. And if all it takes is a couple grad students and an assistant prof to get them in...well, that reflects very poorly on the state of kernel maintenance, to me. Which seems far more important and deserving of attention, than endlessly arraigning three clueless guys at some university.
I'm not in a position to be more specific about what should be fixed. But, what would your answer be to your query? Apparently, do nothing, and assume that everyone in the world is honest, while writing self-indulgent "public letters" about it? How is that going to help when the CCP tries to insert surveillance into the kernel? Or when Russian hackers try to get exploits and ransomware in there?
There is no such assumption and it has been well known for a long time that such an assumption would be harmful.
> if all it takes is a couple grad students and an assistant prof to get them in
There were 0 malicious commits that made it through the review process (since the paper was incompetent as well as unethical.)
You seem to be missing some basic facts here. Filling in those gap would help you partipate more productively in the conversation.
It doesn't. They've been on the lookout since before 2003: https://lwn.net/Articles/57135/ (there are other examples, this is just the earliest I know of)
> Apparently, do nothing, and assume that everyone in the world is honest, while writing self-indulgent "public letters" about it?
This sounds overly dramatic which makes discussion difficult. My answer would be that the kernel maintainers have known about this threat vector for a very long time and seem to be doing a reasonable job of repelling it.
It's not a bare assumption of honestly, it's an established relationship of trust. If you have zero trust then you cannot have any collaboration with other humans; it would be definition take as much or more effort than any creation to verify that the creation is fully safe in an current and future potential contexts.
That trust with the university was broken, and in doing so their work has been reviewed and oft rejected.