11 ms·

Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review

by gregkh 5y ago

Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point in time: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

Cpoll 5y ago
A lot of people are talking about the ethical aspects, but could you talk about the security implications of this attack? From a different thread: https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3NcPu=17qyVyEEtVMVR_g51Ma6Q@mail.gmail.com/ https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... > A lot of these have already reached the stable trees. Apologies in advance if my questions are off the mark, but what does this mean in practice? 1. If UNM hadn't brought any attention to these, would they have been caught, or would they have eventually wound up in distros? 'stable' is the "production" branch? 2. What are the implications of this? Is it possible that other malicious actors have done things like this without being caught? 3. Will there be a post-mortem for this attack/attempted attack?
- deleted 5y ago
  [deleted]
- cutemonster 5y ago
  I wonder about this me too. To me, seems to indicate that nation state supported evil hacker org (maybe posing as an individual) could place their own exploits in the kernel. Let's say they contribute 99.9% useful code, solve real problems, build trust over some years, and only rarely write an evil hard to notice exploit bug. And then, everyone thinks that obviously it was just an ordinary bug. Maybe they can pose as 10 different people, in case some of them gets banned.
  - Spooky23 5y ago
    You're still in a better position with open source. The same thing happens in closed source companies. See: https://www.reuters.com/article/us-usa-security-siliconvalley/strong-ties-bind-spy-agencies-and-silicon-valley-idUSBRE96214I20130703 https://www.reuters.com/article/us-usa-security-siliconvalle... "As U.S. intelligence agencies accelerate efforts to acquire new technology and fund research on cybersecurity, they have invested in start-up companies, encouraged firms to put more military and intelligence veterans on company boards, and nurtured a broad network of personal relationships with top technology executives." Foreign countries do the same thing. There are numerous public accounts of Chinese nationals or folks with vulnerable family in China engaging in espionage.
    - hanselot 5y ago
      Plus, wouldn't it be much easier to do this under the guise of equality with some quickly thought up trash contract enforced on all developers? One might even say that while this useless attack is taking place, actual people with lifelong commitment to open source software and user freedom get taken out by the "NaN" flavour "NaN" koolaid of the week. Soon all that is left that is legal to say is whatever is approved by the "NaN" board. Eventually the number 0 will be found to be exclusionary or accused of "NaN" and we will all be stuck coding unary again.
    - varjag 5y ago
      The principal researches appear to be alumni of mainland China schools.
  - baby 5y ago
    Read into the socat diffie-hellman backdoor, I found it fascinating at the time.
    - throwaway2037 5y ago
      Woah. I Googled that! Nice reference. This is a good explanation with more links: https://github.com/AllThing/socat_backdoor https://github.com/AllThing/socat_backdoor
  - TheSpiceIsLife 5y ago
    Isn't what you've described pretty much the very definition of advanced persistent threat? It's difficult to protect against trusted parties whom you assume, with good reason, and good-faith actors.
    - ethbr0 5y ago
      The fundamental tension is between efficiency and security. Trust permits efficiency, at the cost of security (if that trust is found to be misplaced). A perfectly security system is only realized by a perfectly inefficient development process. We can get better at lessening the efficiency tax of a given security level (through tooling, tests, audits, etc), but for a given state of tooling, there's still a trade-off. Different release trains seem the sanest solution to this problem. If you want bleeding-edge, you're going to pull in less-tested (and also less-audited) code. If you want maximum security, you're going to have to deal with 4.4.
- mk89 5y ago
  I have the same questions. So far we have focused on how bad these "guys" are. Sure, they could have done it differently, etc. However, they proved a big point: how "easy" it is to manipulate the most used piece of software on the planet. How to solve this "issue" without putting too much process around it? That's the challenge.
  - corty 5y ago
    They proved nothing that wasn't already obvious. A malicious actor can get in vulnerabilities the same way a careless programmer can. Quick, call the press! And as for the solutions, their contribution is nil. No suggestions that haven't been suggested, tried and done or rejected a thousand times over.
    - deleted 5y ago
      [deleted]
    - dumpsterdiver 5y ago
      Agreed. So many security vulnerabilities have been created not by malicious actors, but by people who just weren't up to task. Buggy software and exhausted maintainers is nothing new.
      - dcow 5y ago
        What this proves to me is that perhaps lightweight contributions to the kernel should be done in safe languages that prevent memory leaks and with tooling that actively highlights memory safety issues like use after free. Broader rust adoption in the kernel cant come soon enough. I also consider Greg’s response just as much a test of UMN’s internal processes as the researcher’s attempt at testing kernel development processes. Hopefully there will be lessons learned on both sides and this benign incident makes the world better. Nobody was hurt here.
        deleted 5y ago
        [deleted]
- WmyEE0UsWAwC2i 5y ago
  I agree with the sentiment. For a project of this magnitude maybe it comes to develop some kind of static analysis along with refactoring the code to make the former possible. As per the attack surface described in the paper (section IV). Because (III, the acceptance process) is a manpower issue.
  - spullara 5y ago
    Ironically, one of their attempts were submitting changes that were allegedly recommended by a static analysis tool.
    - rjmunro 5y ago
      It's possible that they are developing a static analysis tool that is designed to find places where vulnerabilities can be inserted without looking suspicious. That's kind of scary. Have they submitted patches to any projects other than the kernel?
      - spullara 5y ago
        Guess we have to wait for their next paper to find out.
- neoflame 5y ago
  I don't think the attack described in the paper actually succeeded at all, and in fact the paper doesn't seem to claim that it did. Specifically, I think the three malicious patches described in the paper are: - UAF case 1, Fig. 11 => crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions, https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.ubuntu@gmail.com/ https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.... The day after this patch was merged into a driver tree, the author suggested calling dev_err() before pci_disable_device(), which presumably was their attempt at maintainer notification; however, the code as merged doesn't actually appear to constitute a vulnerability because pci_disable_device() doesn't appear to free the struct pci_dev. - UAF case 2, Fig. 9 => tty/vt: fix a memory leak in con_insert_unipair, https://lore.kernel.org/lkml/20200809221453.10235-1-jameslouisebond@gmail.com/ https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou... This patch was not accepted. - UAF case 3, Fig. 10 => rapidio: fix get device imbalance on error, https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com/ https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.... Same author as case 1. This patch was not accepted. This is not to say that open-source security is not a concern, but IMO the paper is deliberately misleading in an attempt to overstate its contributions. edit: wording tweak for clarity
  - ununoctium87 5y ago
    > the paper is deliberately misleading in an attempt to overstate its contributions. Welcome to academia. Where a large number of students are doing it just for the credentials
    - DSingularity 5y ago
      What else do you expect? The incentive structure in academia pushes students to do this. Immigrant graduate students with uncertain future if they fail? Check. Vulnerable students whose livelihood is at mercy of their advisor? Check. Advisor whose career depends on a large number of publication bullet points in their CV? Check. Students who cheat their way through to publish? Duh.
      - 5y ago
- jnxx 5y ago
  What would be the security implications of these things: * a black hat writes malware that proves to be capable of taking out a nation's electrical grid. We know that such malware is feasible. * a group of teenagers is observed to drop heavy stones from a bridge onto a motorway. * another teenager pointing a relatively powerful laser at the cockpit of a passenger jet which is about to land at night. * an organic chemist is demonstrating that you can poison 100,000 people by throwing certain chemicals into a drinking water reservoir. * a secret service subverting software of a big industrial automation company in order to destroy uranium enrichment plants in another country. * somebody hacking a car's control software in order to kill its driver What are the security implications of this? That more money should be spent on security? That we should stop to drive on motorways? That we should spent more money on war gear? Are you aware how vulnerable all modern infrastructure is? And would demonstrating that any of these can practically be done be worth an academic paper? Aren't several of these really a kind of military research? The Linux kernel community does spend a lot of effort on security and correctness of the kernel. They have a policy of maximum transparency which is good, and known to enhance security. But their project is neither a lab in order to experiment with humans, nor a computer war game. I guess if companies want to have even more security, for running things like nuclear power plants or trains on Linux, they should pay for the (legally required) audits by experts.
tcelvis 5y ago
Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process. Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person have got in is high, it means that an unknown attacker deliberately concerting complex kernel loop hole would have a even higher chance got patches in. While I think the researcher's actions are out of line for sure. This "I will ban you and revert all your stuff" retaliation seems emotional overaction.
- tcelvis 5y ago
  I guess what I am trying to get at is that this researcher's action does have its merit. This event does rise awareness of what sophisticated attacker group might try to do to kernel community. Admitting this would be the first step to hardening the kernel review process to prevent this kind of harm from happening again. What I strongly disapprove of the researcher is that apparently no steps are taken to prevent real world consequences of malicious patches getting into kernel, I think the researcher should: - Notify the kernel community promptly once malicious patches got past all review processes. - Time these actions well such that malicious patches won't not get into a stable branch before they could be reverted. ---------------- Edit: reading the paper provided above, it seems that they did do both actions above. From the paper: > Ensuring the safety of the experiment. In the experiment, we aim to demonstrate the practicality of stealthily introducing vulnerabilities through hypocrite commits. Our goal is not to introduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code. In addition to the minor patches that introduce UAF conditions, we also prepare the correct patches for fixing the minor issues. We send the minor patches to the Linux community through email to seek their feedback. Fortunately, there is a time window between the confirmation of a patch and the merging of the patch. Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our correct patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches. Therefore, we ensured that none of our introduced UAF bugs was ever merged into any branch of the Linux kernel, and none of the Linux users would be affected. So, unless the kernel maintenance team have another side of the story. The questions of ethics could only go as far as "wasting kernel community's time" rather than creating real world loop holes.
inglor 5y ago
Just wanted to say thanks for your work! As an OSS maintainer (Node.js and a bunch of popular JS libs with millions of weekly downloads) - I feel how _tempting_ it is to trust people and assume good faith. Often since people took the time to contribute you want to be "on their side" and help them "make it". Identifying and then standing up to bad-faith actors is extremely important and thankless work. Especially ones that apparently seem to think it's fine to experiment on humans without consent. So thanks. Keep it up.
- emteycz 5y ago
  How could resilience be verified after asking for consent?
  - kemotep 5y ago
    Same way an employer trains employees on phishing campaigns or an auditor or penetration tester tests resilience or compliance.
    - emteycz 5y ago
      Yes, employers often send out fake phishing e-mails to test resilience and organizational penetration testing is done on the field with unsuspecting people.
      - iR5ugfXGAE 5y ago
        Ah. I never replied to the e-mails sent out by my employer about registering for a training in phishing detection. I just assumed those e-mails were phishing e-mails.
        thaeli 5y ago
        I assume that so many official emails from my employer are phishing.. it's a mess.
      - 5y ago
turndown 5y ago
Just wanted you to know that I think you're an amazing programmer
saghm 5y ago
Thank you for all your excellent work!
fossuser 5y ago
I hope they take this bad publicity and stop (rather than escalating stupidity by using non university emails). What a joke - not sure how they can rationalize this as valuable behavior.
- nomel 5y ago
  It was a real world penetration test that showed some serious security holes in the code analysis/review process. Penetration tests are always only as valuable as your response to them. If they chose to do nothing about their code review/analysis process, with these vulnerabilities that made it in (intentional or not), then yes, the exercise probably wasn't valuable. Personally, I think all contributors should be considered "bad actors" in open source software. NSA, some university mail address, etc. I consider myself a bad actor, whenever I write code with security in mind. This is why I use fuzzing and code analysis tools. Banning them was probably the correct action, but not finding value requires intentionally ignoring the very real result of the exercise.
  - ben0x539 5y ago
    A real world penetration test is coordinated with the entity being tested.
    - fossuser 5y ago
      Yeah - and usually stops short of causing actual damage. You don't get to rob a bank and then when caught say "you should thank us for showing your security weaknesses". In this case they merged actual bugs and now they have to revert that stuff which depending on how connected those commits are to other things could cost a lot of time. If they were doing this in good faith, they could have stopped short of actually letting the PRs merge (even then it's rude to waste their time this way). This just comes across to me as an unethical academic with no real valuable work to do.
      - dragonwriter 5y ago
        > You don't get to rob a bank and then when caught say "you should thank us for showing your security weaknesses". Yeah, there’s a reason the US response to 9/11 wasn’t to name Osama bin Laden “Airline security researcher of the Millenium”, and it isn’t that “2001 was too early to make that judgement”.
nwelna 5y ago
As an Alumni of the University of Minnesota's program I am appalled this was even greenlit. It reflects poorly on all graduates of the program, even those uninvolved. I am planning to email the department head with my disapproval as an alumni, and I am deeply sorry for the harm this caused.
- deleted 5y ago
  [deleted]
- anp 5y ago
  Based on my time in a university department you might want to cc whoever chairs the IRB or at least oversees its decisions for the CS department. Seems like multiple incentives and controls failed here, good on you for applying the leverage available to you.
  - tw04 5y ago
    I'm genuinely curious how this was positioned to the IRB and if they were clear that what they were actually trying to accomplish was social engineering/manipulation. Being a public university, I hope at some point they address this publicly as well as list the steps they are (hopefully) taking to ensure something like this doesn't happen again. I'm also not sure how they can continue to employ the prof in question and expect the open source community to ever trust them to act in good faith going forward.
    - detaro 5y ago
      first statement + commentary from their associate department head: https://twitter.com/lorenterveen/status/1384954220705722369 https://twitter.com/lorenterveen/status/1384954220705722369
      - woofie11 5y ago
        Wow. Total sleazeball. This appears to not be his first time with using unintentional research subjects. Source: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C22&q=Loren+Terveen+wikipedia&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C22&q=Lor... This is quite literally the first point of the Nuremberg code research ethics are based on: https://en.wikipedia.org/wiki/Nuremberg_Code#The_ten_points_of_the_Nuremberg_Code https://en.wikipedia.org/wiki/Nuremberg_Code#The_ten_points_... This isn't an individual failing. This is an institutional failing. This is the sort of thing which someone ought to raise with OMB. He literally points to how Wikipedia needed to respond when he broke the rules: https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not#Wikipedia_is_not_a_laboratory https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_no...
g42gregory 5y ago
My deepest thanks for all your work, as well as for keeping the standards high and the integrity of the project intact!
devit 5y ago
Well, you or whoever was the responsible maintainer completely failed in reviewing these patches, which is your whole job as a maintainer. Just reverting those patches (which may well be correct) makes no sense, you and/or other maintainers need to properly review them after your previous abject failure at doing so, and properly determine whether they are correct or not, and if they aren't how they got merged anyway and how you will stop this happening again. Or I suppose step down as maintainers, which may be appropriate after a fiasco of this magnitude.
- lacker 5y ago
  On the contrary, it would be the easy, lazy way out for a maintainer to say “well this incident was a shame now let’s forget about it.” The extra work the kernel devs are putting in here should be commended. In general, it is the wrong attitude to say, oh we had a security problem. What a fiasco! Everyone involved should be fired! With a culture like that, all you guarantee is that people cover up the security issues that inevitably occur. Perhaps this incident actually does indicate that kernel code review procedures should be changed in some way. I don’t know, I’m not a kernel expert. But the right way to do that is with a calm postmortem after appropriate immediate actions are taken. Rolling back changes made by malicious actors is a very reasonable immediate action to take. After emotions have cooled, then it’s the right time to figure out if any processes should be changed in the future. And kernel devs putting in extra work to handle security incidents should be appreciated, not criticized for their imperfection.
- RogerL 5y ago
  Greg explicitly stated "Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix....I will be working with some other kernel developers to determine if any of these reverts were actually valid changes, were actually valid, and if so, will resubmit them properly later. For now, it's better to be safe."
de6u99er 5y ago
I would be interested how many committers actually work at private and state intelligence?
- hnedeotes 5y ago
  you know what they say, curiosity killed the cat
dumpsterdiver 5y ago
I would implore you to maintain the ban, no matter how hard the university tries to make ammends. You sent a very clear message that this type of behavior will not be tolerated, and organizations should take serious measures to prevent malicious activities taking place under their purview. I commend you for that. Thanks for your hard work and diligence.
- trashtester 5y ago
  Looks like the authors have Chinese names [1]. Should they ban anyone with Chinese names, too, for good measure? Or maybe collective punishment is not such a good idea? [1] https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
- jfim 5y ago
  I'd disagree. Organizations are collections of actors, some of which may have malicious intents. As long as the organization itself does not condone this type of behavior, has mechanisms in place to prevent such behavior, and has actual consequences for malicious actors, then the blame should be placed on the individual, not the organization. In the case of research, universities are required to have an ethics board that reviews research proposals before actual research is conducted. Conducting research without an approval or misrepresenting the research project to the ethics board are pretty serious offenses. Typically for research that involves people, participants in the research require having a consent form that is signed by participants, alongside a reminder for participants that they can withdraw that consent at any time without any penalties. It's pretty interesting that in this case, there seemed to have been no real consent required, and it would be interesting to know whether there has been an oversight by the ethics board or a misrepresentation of the research by the researchers. It will be interesting to see whether the university applies a penalty to the professor (removal of tenure, termination, suspension, etc.) or not. The latter would imply that they're okay with unethical or misrepresented research being associated with their university, which would be pretty surprising. In any case, it's a good thing that the Linux kernel maintainers decided that experimenting on them isn't acceptable and disrespectful of their contributions. Subjecting participants to experiments without their consent is a severe breach of ethical duty, and I hope that the university will apply the correct sanctions to the researchers and instigators.
cookiengineer 5y ago
Thanks for your important work, Greg! I'm currently wondering how much of these patches could've been flagged in an automated manner, in the sense of fuzzing specific parts that have been modified (and a fuzzer that is memory/binary aware). Would a project like this be unfeasible due to the sheer amount of commits/day?
haecceity 5y ago
This might not be on purpose. If you look at their article they're studying how to introduce bugs that are hard to detect not ones that are easy to detect.
yellowyacht 5y ago
> Thanks for the support. THANK YOU! After reading the email chain, I have a much greater appreciation for the work you do for the community!
nialv7 5y ago
I have to ask: were they not properly reviewed when they were first merged? Also to assume _all_ commits made by UMN, beyond what's been disclosed in the paper, are malicious feels a bit like an overreaction.
oauea 5y ago
> should be aware that future submissions from anyone with a umn.edu address should be by default-rejected Are you not concerned these malicious "researches" will simply start using throwaway gmail addresses?
- Aperocky 5y ago
  Are throwaway gmail addresses nearly as 'trusted'?
- dahart 5y ago
  That’s not likely to work after a high profile incident like this, in the short term or the long term. Publication is, by design, a de-anonymizing process.

by gregkh 5y ago

Cpoll 5y ago

A lot of people are talking about the ethical aspects, but could you talk about the security implications of this attack? From a different thread: https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3NcPu=17qyVyEEtVMVR_g51Ma6Q@mail.gmail.com/ https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... > A lot of these have already reached the stable trees. Apologies in advance if my questions are off the mark, but what does this mean in practice? 1. If UNM hadn't brought any attention to these, would they have been caught, or would they have eventually wound up in distros? 'stable' is the "production" branch? 2. What are the implications of this? Is it possible that other malicious actors have done things like this without being caught? 3. Will there be a post-mortem for this attack/attempted attack?

deleted 5y ago
[deleted]
cutemonster 5y ago
I wonder about this me too. To me, seems to indicate that nation state supported evil hacker org (maybe posing as an individual) could place their own exploits in the kernel. Let's say they contribute 99.9% useful code, solve real problems, build trust over some years, and only rarely write an evil hard to notice exploit bug. And then, everyone thinks that obviously it was just an ordinary bug. Maybe they can pose as 10 different people, in case some of them gets banned.
- Spooky23 5y ago
  You're still in a better position with open source. The same thing happens in closed source companies. See: https://www.reuters.com/article/us-usa-security-siliconvalley/strong-ties-bind-spy-agencies-and-silicon-valley-idUSBRE96214I20130703 https://www.reuters.com/article/us-usa-security-siliconvalle... "As U.S. intelligence agencies accelerate efforts to acquire new technology and fund research on cybersecurity, they have invested in start-up companies, encouraged firms to put more military and intelligence veterans on company boards, and nurtured a broad network of personal relationships with top technology executives." Foreign countries do the same thing. There are numerous public accounts of Chinese nationals or folks with vulnerable family in China engaging in espionage.
  - hanselot 5y ago
    Plus, wouldn't it be much easier to do this under the guise of equality with some quickly thought up trash contract enforced on all developers? One might even say that while this useless attack is taking place, actual people with lifelong commitment to open source software and user freedom get taken out by the "NaN" flavour "NaN" koolaid of the week. Soon all that is left that is legal to say is whatever is approved by the "NaN" board. Eventually the number 0 will be found to be exclusionary or accused of "NaN" and we will all be stuck coding unary again.
  - varjag 5y ago
    The principal researches appear to be alumni of mainland China schools.
- baby 5y ago
  Read into the socat diffie-hellman backdoor, I found it fascinating at the time.
  - throwaway2037 5y ago
    Woah. I Googled that! Nice reference. This is a good explanation with more links: https://github.com/AllThing/socat_backdoor https://github.com/AllThing/socat_backdoor
- TheSpiceIsLife 5y ago
  Isn't what you've described pretty much the very definition of advanced persistent threat? It's difficult to protect against trusted parties whom you assume, with good reason, and good-faith actors.
  - ethbr0 5y ago
    The fundamental tension is between efficiency and security. Trust permits efficiency, at the cost of security (if that trust is found to be misplaced). A perfectly security system is only realized by a perfectly inefficient development process. We can get better at lessening the efficiency tax of a given security level (through tooling, tests, audits, etc), but for a given state of tooling, there's still a trade-off. Different release trains seem the sanest solution to this problem. If you want bleeding-edge, you're going to pull in less-tested (and also less-audited) code. If you want maximum security, you're going to have to deal with 4.4.
mk89 5y ago
I have the same questions. So far we have focused on how bad these "guys" are. Sure, they could have done it differently, etc. However, they proved a big point: how "easy" it is to manipulate the most used piece of software on the planet. How to solve this "issue" without putting too much process around it? That's the challenge.
- corty 5y ago
  They proved nothing that wasn't already obvious. A malicious actor can get in vulnerabilities the same way a careless programmer can. Quick, call the press! And as for the solutions, their contribution is nil. No suggestions that haven't been suggested, tried and done or rejected a thousand times over.
  - deleted 5y ago
    [deleted]
  - dumpsterdiver 5y ago
    Agreed. So many security vulnerabilities have been created not by malicious actors, but by people who just weren't up to task. Buggy software and exhausted maintainers is nothing new.
    - dcow 5y ago
      What this proves to me is that perhaps lightweight contributions to the kernel should be done in safe languages that prevent memory leaks and with tooling that actively highlights memory safety issues like use after free. Broader rust adoption in the kernel cant come soon enough. I also consider Greg’s response just as much a test of UMN’s internal processes as the researcher’s attempt at testing kernel development processes. Hopefully there will be lessons learned on both sides and this benign incident makes the world better. Nobody was hurt here.
      - deleted 5y ago
        [deleted]
WmyEE0UsWAwC2i 5y ago
I agree with the sentiment. For a project of this magnitude maybe it comes to develop some kind of static analysis along with refactoring the code to make the former possible. As per the attack surface described in the paper (section IV). Because (III, the acceptance process) is a manpower issue.
- spullara 5y ago
  Ironically, one of their attempts were submitting changes that were allegedly recommended by a static analysis tool.
  - rjmunro 5y ago
    It's possible that they are developing a static analysis tool that is designed to find places where vulnerabilities can be inserted without looking suspicious. That's kind of scary. Have they submitted patches to any projects other than the kernel?
    - spullara 5y ago
      Guess we have to wait for their next paper to find out.
neoflame 5y ago
I don't think the attack described in the paper actually succeeded at all, and in fact the paper doesn't seem to claim that it did. Specifically, I think the three malicious patches described in the paper are: - UAF case 1, Fig. 11 => crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions, https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.ubuntu@gmail.com/ https://lore.kernel.org/lkml/20200821031209.21279-1-acostag.... The day after this patch was merged into a driver tree, the author suggested calling dev_err() before pci_disable_device(), which presumably was their attempt at maintainer notification; however, the code as merged doesn't actually appear to constitute a vulnerability because pci_disable_device() doesn't appear to free the struct pci_dev. - UAF case 2, Fig. 9 => tty/vt: fix a memory leak in con_insert_unipair, https://lore.kernel.org/lkml/20200809221453.10235-1-jameslouisebond@gmail.com/ https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou... This patch was not accepted. - UAF case 3, Fig. 10 => rapidio: fix get device imbalance on error, https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.ubuntu@gmail.com/ https://lore.kernel.org/lkml/20200821034458.22472-1-acostag.... Same author as case 1. This patch was not accepted. This is not to say that open-source security is not a concern, but IMO the paper is deliberately misleading in an attempt to overstate its contributions. edit: wording tweak for clarity
- ununoctium87 5y ago
  > the paper is deliberately misleading in an attempt to overstate its contributions. Welcome to academia. Where a large number of students are doing it just for the credentials
  - DSingularity 5y ago
    What else do you expect? The incentive structure in academia pushes students to do this. Immigrant graduate students with uncertain future if they fail? Check. Vulnerable students whose livelihood is at mercy of their advisor? Check. Advisor whose career depends on a large number of publication bullet points in their CV? Check. Students who cheat their way through to publish? Duh.
    - 5y ago
jnxx 5y ago
What would be the security implications of these things: * a black hat writes malware that proves to be capable of taking out a nation's electrical grid. We know that such malware is feasible. * a group of teenagers is observed to drop heavy stones from a bridge onto a motorway. * another teenager pointing a relatively powerful laser at the cockpit of a passenger jet which is about to land at night. * an organic chemist is demonstrating that you can poison 100,000 people by throwing certain chemicals into a drinking water reservoir. * a secret service subverting software of a big industrial automation company in order to destroy uranium enrichment plants in another country. * somebody hacking a car's control software in order to kill its driver What are the security implications of this? That more money should be spent on security? That we should stop to drive on motorways? That we should spent more money on war gear? Are you aware how vulnerable all modern infrastructure is? And would demonstrating that any of these can practically be done be worth an academic paper? Aren't several of these really a kind of military research? The Linux kernel community does spend a lot of effort on security and correctness of the kernel. They have a policy of maximum transparency which is good, and known to enhance security. But their project is neither a lab in order to experiment with humans, nor a computer war game. I guess if companies want to have even more security, for running things like nuclear power plants or trains on Linux, they should pay for the (legally required) audits by experts.

tcelvis 5y ago

Putting the ethical question of the researcher aside, the fact you want to "properly review them at a later point in time" seems to suggest a lack of confidence in the kernel review process. Since this researcher is apparently not an established figure in the kernel community, my expectation is the patches have gone through the most rigorous review process. If you think the risk of malicious patches from this person have got in is high, it means that an unknown attacker deliberately concerting complex kernel loop hole would have a even higher chance got patches in. While I think the researcher's actions are out of line for sure. This "I will ban you and revert all your stuff" retaliation seems emotional overaction.

tcelvis 5y ago
I guess what I am trying to get at is that this researcher's action does have its merit. This event does rise awareness of what sophisticated attacker group might try to do to kernel community. Admitting this would be the first step to hardening the kernel review process to prevent this kind of harm from happening again. What I strongly disapprove of the researcher is that apparently no steps are taken to prevent real world consequences of malicious patches getting into kernel, I think the researcher should: - Notify the kernel community promptly once malicious patches got past all review processes. - Time these actions well such that malicious patches won't not get into a stable branch before they could be reverted. ---------------- Edit: reading the paper provided above, it seems that they did do both actions above. From the paper: > Ensuring the safety of the experiment. In the experiment, we aim to demonstrate the practicality of stealthily introducing vulnerabilities through hypocrite commits. Our goal is not to introduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code. In addition to the minor patches that introduce UAF conditions, we also prepare the correct patches for fixing the minor issues. We send the minor patches to the Linux community through email to seek their feedback. Fortunately, there is a time window between the confirmation of a patch and the merging of the patch. Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our correct patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches. Therefore, we ensured that none of our introduced UAF bugs was ever merged into any branch of the Linux kernel, and none of the Linux users would be affected. So, unless the kernel maintenance team have another side of the story. The questions of ethics could only go as far as "wasting kernel community's time" rather than creating real world loop holes.

inglor 5y ago

Just wanted to say thanks for your work! As an OSS maintainer (Node.js and a bunch of popular JS libs with millions of weekly downloads) - I feel how _tempting_ it is to trust people and assume good faith. Often since people took the time to contribute you want to be "on their side" and help them "make it". Identifying and then standing up to bad-faith actors is extremely important and thankless work. Especially ones that apparently seem to think it's fine to experiment on humans without consent. So thanks. Keep it up.

emteycz 5y ago
How could resilience be verified after asking for consent?
- kemotep 5y ago
  Same way an employer trains employees on phishing campaigns or an auditor or penetration tester tests resilience or compliance.
  - emteycz 5y ago
    Yes, employers often send out fake phishing e-mails to test resilience and organizational penetration testing is done on the field with unsuspecting people.
    - iR5ugfXGAE 5y ago
      Ah. I never replied to the e-mails sent out by my employer about registering for a training in phishing detection. I just assumed those e-mails were phishing e-mails.
      - thaeli 5y ago
        I assume that so many official emails from my employer are phishing.. it's a mess.
    - 5y ago

turndown 5y ago

Just wanted you to know that I think you're an amazing programmer

saghm 5y ago

Thank you for all your excellent work!

fossuser 5y ago

I hope they take this bad publicity and stop (rather than escalating stupidity by using non university emails). What a joke - not sure how they can rationalize this as valuable behavior.

nomel 5y ago
It was a real world penetration test that showed some serious security holes in the code analysis/review process. Penetration tests are always only as valuable as your response to them. If they chose to do nothing about their code review/analysis process, with these vulnerabilities that made it in (intentional or not), then yes, the exercise probably wasn't valuable. Personally, I think all contributors should be considered "bad actors" in open source software. NSA, some university mail address, etc. I consider myself a bad actor, whenever I write code with security in mind. This is why I use fuzzing and code analysis tools. Banning them was probably the correct action, but not finding value requires intentionally ignoring the very real result of the exercise.
- ben0x539 5y ago
  A real world penetration test is coordinated with the entity being tested.
  - fossuser 5y ago
    Yeah - and usually stops short of causing actual damage. You don't get to rob a bank and then when caught say "you should thank us for showing your security weaknesses". In this case they merged actual bugs and now they have to revert that stuff which depending on how connected those commits are to other things could cost a lot of time. If they were doing this in good faith, they could have stopped short of actually letting the PRs merge (even then it's rude to waste their time this way). This just comes across to me as an unethical academic with no real valuable work to do.
    - dragonwriter 5y ago
      > You don't get to rob a bank and then when caught say "you should thank us for showing your security weaknesses". Yeah, there’s a reason the US response to 9/11 wasn’t to name Osama bin Laden “Airline security researcher of the Millenium”, and it isn’t that “2001 was too early to make that judgement”.

nwelna 5y ago

As an Alumni of the University of Minnesota's program I am appalled this was even greenlit. It reflects poorly on all graduates of the program, even those uninvolved. I am planning to email the department head with my disapproval as an alumni, and I am deeply sorry for the harm this caused.

deleted 5y ago
[deleted]
anp 5y ago
Based on my time in a university department you might want to cc whoever chairs the IRB or at least oversees its decisions for the CS department. Seems like multiple incentives and controls failed here, good on you for applying the leverage available to you.
- tw04 5y ago
  I'm genuinely curious how this was positioned to the IRB and if they were clear that what they were actually trying to accomplish was social engineering/manipulation. Being a public university, I hope at some point they address this publicly as well as list the steps they are (hopefully) taking to ensure something like this doesn't happen again. I'm also not sure how they can continue to employ the prof in question and expect the open source community to ever trust them to act in good faith going forward.
  - detaro 5y ago
    first statement + commentary from their associate department head: https://twitter.com/lorenterveen/status/1384954220705722369 https://twitter.com/lorenterveen/status/1384954220705722369
    - woofie11 5y ago
      Wow. Total sleazeball. This appears to not be his first time with using unintentional research subjects. Source: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C22&q=Loren+Terveen+wikipedia&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C22&q=Lor... This is quite literally the first point of the Nuremberg code research ethics are based on: https://en.wikipedia.org/wiki/Nuremberg_Code#The_ten_points_of_the_Nuremberg_Code https://en.wikipedia.org/wiki/Nuremberg_Code#The_ten_points_... This isn't an individual failing. This is an institutional failing. This is the sort of thing which someone ought to raise with OMB. He literally points to how Wikipedia needed to respond when he broke the rules: https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not#Wikipedia_is_not_a_laboratory https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_no...

g42gregory 5y ago

My deepest thanks for all your work, as well as for keeping the standards high and the integrity of the project intact!

devit 5y ago

Well, you or whoever was the responsible maintainer completely failed in reviewing these patches, which is your whole job as a maintainer. Just reverting those patches (which may well be correct) makes no sense, you and/or other maintainers need to properly review them after your previous abject failure at doing so, and properly determine whether they are correct or not, and if they aren't how they got merged anyway and how you will stop this happening again. Or I suppose step down as maintainers, which may be appropriate after a fiasco of this magnitude.

lacker 5y ago
On the contrary, it would be the easy, lazy way out for a maintainer to say “well this incident was a shame now let’s forget about it.” The extra work the kernel devs are putting in here should be commended. In general, it is the wrong attitude to say, oh we had a security problem. What a fiasco! Everyone involved should be fired! With a culture like that, all you guarantee is that people cover up the security issues that inevitably occur. Perhaps this incident actually does indicate that kernel code review procedures should be changed in some way. I don’t know, I’m not a kernel expert. But the right way to do that is with a calm postmortem after appropriate immediate actions are taken. Rolling back changes made by malicious actors is a very reasonable immediate action to take. After emotions have cooled, then it’s the right time to figure out if any processes should be changed in the future. And kernel devs putting in extra work to handle security incidents should be appreciated, not criticized for their imperfection.
RogerL 5y ago
Greg explicitly stated "Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix....I will be working with some other kernel developers to determine if any of these reverts were actually valid changes, were actually valid, and if so, will resubmit them properly later. For now, it's better to be safe."

de6u99er 5y ago

I would be interested how many committers actually work at private and state intelligence?

hnedeotes 5y ago
you know what they say, curiosity killed the cat

dumpsterdiver 5y ago

I would implore you to maintain the ban, no matter how hard the university tries to make ammends. You sent a very clear message that this type of behavior will not be tolerated, and organizations should take serious measures to prevent malicious activities taking place under their purview. I commend you for that. Thanks for your hard work and diligence.

trashtester 5y ago
Looks like the authors have Chinese names [1]. Should they ban anyone with Chinese names, too, for good measure? Or maybe collective punishment is not such a good idea? [1] https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
jfim 5y ago
I'd disagree. Organizations are collections of actors, some of which may have malicious intents. As long as the organization itself does not condone this type of behavior, has mechanisms in place to prevent such behavior, and has actual consequences for malicious actors, then the blame should be placed on the individual, not the organization. In the case of research, universities are required to have an ethics board that reviews research proposals before actual research is conducted. Conducting research without an approval or misrepresenting the research project to the ethics board are pretty serious offenses. Typically for research that involves people, participants in the research require having a consent form that is signed by participants, alongside a reminder for participants that they can withdraw that consent at any time without any penalties. It's pretty interesting that in this case, there seemed to have been no real consent required, and it would be interesting to know whether there has been an oversight by the ethics board or a misrepresentation of the research by the researchers. It will be interesting to see whether the university applies a penalty to the professor (removal of tenure, termination, suspension, etc.) or not. The latter would imply that they're okay with unethical or misrepresented research being associated with their university, which would be pretty surprising. In any case, it's a good thing that the Linux kernel maintainers decided that experimenting on them isn't acceptable and disrespectful of their contributions. Subjecting participants to experiments without their consent is a severe breach of ethical duty, and I hope that the university will apply the correct sanctions to the researchers and instigators.

cookiengineer 5y ago

Thanks for your important work, Greg! I'm currently wondering how much of these patches could've been flagged in an automated manner, in the sense of fuzzing specific parts that have been modified (and a fuzzer that is memory/binary aware). Would a project like this be unfeasible due to the sheer amount of commits/day?

haecceity 5y ago

This might not be on purpose. If you look at their article they're studying how to introduce bugs that are hard to detect not ones that are easy to detect.

yellowyacht 5y ago

> Thanks for the support. THANK YOU! After reading the email chain, I have a much greater appreciation for the work you do for the community!

nialv7 5y ago

I have to ask: were they not properly reviewed when they were first merged? Also to assume _all_ commits made by UMN, beyond what's been disclosed in the paper, are malicious feels a bit like an overreaction.

oauea 5y ago

> should be aware that future submissions from anyone with a umn.edu address should be by default-rejected Are you not concerned these malicious "researches" will simply start using throwaway gmail addresses?

Aperocky 5y ago
Are throwaway gmail addresses nearly as 'trusted'?
dahart 5y ago
That’s not likely to work after a high profile incident like this, in the short term or the long term. Publication is, by design, a de-anonymizing process.