52 ms·

“They introduce kernel bugs on purpose”

• jc2it 5y ago
  After reading many of the comments I agree with the decision to ban the University. Why? You are free to choose your actions. You are not free to choose the consequences of your actions.
• kleiba 5y ago
  This is bullshit research. I mean, what they have actually found out through their experiments is that you can maliciously introduce bugs into the linux kernel. But, did anyone have doubts about this being possible prior to this "research"? Obviously, bugs gets introduced into all software projects all the time. And the bugs don't know whether they've been put there intentionally or accidentally. Alls bugs that ever appeared in the linux kernel obviously made it through the review process. Even when no-one actively tried to introduce them. So, why should it not be possible to intentionally insert bugs if it already "works" unintentionally? What is the insight gained from this innovative "research"?
• nemoniac 5y ago
  Who funds this? They acknowledge funding from the NSF but you could imagine that it would benefit some other large players to sow uncertainty and doubt about Open Source Software.
• hola1234asdf 5y ago
  asdfadsfsdfd
• kdbg 5y ago
  I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... That said the current incident seems to have gone beyond the limits of that one and is a new incident. I just thought it would be fair to include their "side"
  • kstenerud 5y ago
    From their explanation: (3). We send the incorrect minor patches to the Linux community through email to seek their feedback. (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug 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 proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux. ------------------------ But this shows a distinct lack of understanding of the problem: > This is not ok, it is wasting our time, and we will have to report this, > AGAIN, to your university... ------------------------ You do not experiment on people without their consent. This is in fact the very FIRST point of the Nuremberg code: 1. The voluntary consent of the human subject is absolutely essential.
    • chenzhekl 5y ago
      Yeah, it is a bit disrespectful for kernel maintainers without gaining their approvals ahead of time.
      • moron4hire 5y ago
        Disrespecting some programmers on the internet is, while not nice, also not a high crime.
    • throwawaybbq1 5y ago
      Holy cow!! I'm a researcher and don't understand how they thought it would be okay to not do an IRB, and how an IRB would not catch this. The linked PDF by the parent post is quite illustrative. The first few paras seem to be downplaying the severity of what they did (did not introduce actual bugs into the kernel) but that is not the bloody problem. They experimented on people (maintainers) without consent and wasted their time (maybe other effects too .. e.g. making them vary of future commits from universities)! I'm appalled.
• Metacelsus 5y ago
  Yikes, and what are they hoping to accomplish with this "research"?
  • pikzel 5y ago
    Why don't you read the article to find out? https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
    • Igorvelky 5y ago
      They are sending BUGS, and wasting time of people approving patches, in useless and idiotic manner
  • Macuyiko 5y ago
    What any researcher needs to accomplish: more publications
    • Ma8ee 5y ago
      That’s about as useful as to answer the question “what is this company doing?” with “trying to make money”.
      • xwolfi 5y ago
        But that question is as deep and important to answer as yours :D What can anyone hope to accomplish by doing fake research ? Progress, wealth, peer approval, mating, pleasure ? So answering that they hope to get more material for papers, which is the only goal of researchers (and their main KPI), is quite deeper an answer than the question required.
        • guipsp 5y ago
          I wouldn't call this fake research. Maybe unethical, but they did do research, and they did obtain data,and they did (attempt?) to publish it.
• toxik 5y ago
  The problem here is really that they’re wasting time of the maintainers without their approval. Any ethics board would require prior consent to this. It wouldn’t even be hard to do.
  • InsomniacL 5y ago
    1) They identified vulnerabilities with a process 2) They contributed the correct code after showing the maintainer the security vulnerability they missed. 3) Getting the consent of the people behind the process would invalidate the results.
    • waihtis 5y ago
      Go hack a random organization without a vulnerability disclosure program in place and see how much goodwill you have. There is a very established best practice in how to do responsible disclosure and this is far from it.
      • XorNot 5y ago
        Also by and large reputation is a good first step in a security process. While any USB stick might have malware on it if it's ever been out of your sight, that one you found in the parking lot is a much bigger problem.
      • Avamander 5y ago
        Propose a way to test this without invalidating the results.
        • waihtis 5y ago
          1) Contact a single maintainer and explore feasibility of the study 2) Create a group of maintainers who know the experiment is going to happen, but leave a certain portion of the org out of it 3) Orchestrate it so that someone outside of the knowledge group approves one or more of these patches 4) Interfere before any further damage is done Besides, are you arguing that ends justify the means if the intent behind the research is valid?
• gnfargbl 5y ago
  From 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. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.
  • st_goliath 5y ago
    I tangentially followed the debacle unfold for a while and this particular thread now has lead to heated debates on some IRC channels I'm on. While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best. Two messages down in the same thread, it more or less culminates with the university e-mail suffix being banned from several kernel mailing lists and associated patches being removed[1], which might be an appropriate response to discourage others from similar stunts "for science". [1] https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...
    • gspr 5y ago
      > While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best. I agree. I would say this is kind of a "human process" analog of your typical computer security research, and that this behavior is akin to black hats exploiting a vulnerability. Totally not OK as research, and totally reckless!
      • gnfargbl 5y ago
        Yep. To take a physical-world analogy: Would it be okay to try and prove the vulnerability of a country's water supply by intentionally introducing a "harmless" chemical into the treatment works, without the consent of the works owners? Or would that be a go directly to jail sort of an experiment? I share the researchers' intellectual curiosity about whether this would work, but I don't see how a properly-informed ethics board could ever have passed it.
• ENOTTY 5y ago
  Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In the commit traffic[2], I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018. In 2018, Wenwen Wang was submitting patches; during this time he was a postdoc at UMN and co-authored a paper with Liu[4]. Prior to 2018, commits involving UMN folks appeared in 2014, 2013, and 2008. None of these people appear to be associated with Liu in any significant way. [1]: https://github.com/torvalds/linux/search?q=%22umn.edu%22 https://github.com/torvalds/linux/search?q=%22umn.edu%22 [2]: https://github.com/torvalds/linux/search?q=%22umn.edu%22&type=commits https://github.com/torvalds/linux/search?q=%22umn.edu%22&typ... [3]: https://www-users.cs.umn.edu/~kjlu/ https://www-users.cs.umn.edu/~kjlu/ [4]: http://cobweb.cs.uga.edu/~wenwen/ http://cobweb.cs.uga.edu/~wenwen/
  • henearkr 5y ago
    Not a big loss: these professors likely hate open source. [edit: they do not. See child comments.] They are conducting research to demonstrate that it is easy to introduce bugs in open source... (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards) [removed this ranting that does not apply since they are contributing a lot to the kernel in good ways too]
    • throwaway823882 5y ago
      > the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards That's not true at all. There are many internet-critical projects with tons of holes that are not found for decades, because nobody except the core team ever looks at the code. You have to actually write tests, do fuzzing, static/memory analysis, etc to find bugs/security holes. Most open source projects don't even have tests. Assuming people are always looking for bugs in FOSS projects is like assuming people are always looking for code violations in skyscrapers, just because a lot of people walk around them.
• Quarrelsome 5y ago
  This is ridiculously unethical research. Despite the positive underlying reasons treating someone as a lab rat (in this case maintainers reviewing PRs) feels almost sociopathic.
  • jnxx 5y ago
    > Despite the positive underlying reasons I think that is thinking too kind of them. Sociopaths are often very well-versed to give "reasons" about what they do, but at the core it is powerplay.
  • Quarrelsome 5y ago
    how do I deserve -4 for this?
• lamp987 5y ago
  Unethical and harmful.
• seanieb 5y ago
  Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review. Whats being done to address those issues?
  • st_goliath 5y ago
    > non-existent... static analysis .... Whats being done to address those issues? Static analysis is being done[1][2], in addition, there are also CI test farms[3][4], fuzzing farms[5], etc. Linux is a project that enough large companies have a stake in that there are some willing to throw resources like this at it. Human review is supposed to be done through the mailing list submission process. How well this works depends in my experience from ML to ML. [1] https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.html https://www.kernel.org/doc/html/v4.15/dev-tools/coccinelle.h... [2] https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux [3] https://cki-project.org/ https://cki-project.org/ [4] https://bottest.wiki.kernel.org/ https://bottest.wiki.kernel.org/ [5] https://syzkaller.appspot.com/upstream https://syzkaller.appspot.com/upstream
  • deleted 5y ago
    [deleted]
  • viraptor 5y ago
    Not sure why you think they proved that. Human review was done on the same day the patch was submitted and pointed out that it's wrong: https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fieldses.org/ https://lore.kernel.org/linux-nfs/20210407153458.GA28924@fie...
    • meitham 5y ago
      Human review was done after the patch was merged into stable, hence reverting was necessary. I’m confused why these patches don’t get treated as merge requests and get reviewed prior to merging!
      • rcxdude 5y ago
• InsomniacL 5y ago
  Seems to me they exposed a vulnerability in the way code is contributed. If this was Facebook and their response was: > ~"stop wasting our time" > ~"we'll report you" the responses here would be very different.
• deleted 5y ago
  [deleted]
• waihtis 5y ago
  Should've at least sought approval from the maintainer party, and perhaps tried to orchestrate it so that the patch approver didn't have information about it, but some part of the org did. In a network security analogy, this is just unsolicited hacking VS being a penetration test which it claims more so to be.
  • wang_li 5y ago
    This is no better. All it does is increase the size of the research team. You’re still doing research on non-consenting participants.
• LordN00b 5y ago
  * plonk * Was a very nice touch.
  • barrkel 5y ago
    It's an acronym - Person Leaving Our Newsgroup; Kill-filed.
• jedimastert 5y ago
  Out of curiosity, what would be an actually good way to poke at the pipeline like this? Just ask if they'd OK a patch w/o actually submitting it? A survey?
  • roca 5y ago
    Ask Linus to approve it.
    • throwawaybbq1 5y ago
      No .. Linus can approve it on himself. Linus cannot approve such a thing on behalf of other maintainers.
      • mafuy 5y ago
        Agree. Since these researchers did not even ask him, they did not fulfill even the most basic requirement. If, and only if, he approves, then we can talk about who else needs to be in the know, etc.
      • roca 5y ago
        That's fair, but asking for and getting Linus' approval would have at least put them in a much stronger position. They didn't even do that. (And I doubt Linus would have even given his approval, in which case they wouldn't be in this mess.)
  • throwawaybbq1 5y ago
    This is a good question. You would recruit actual maintainers, [edit: or whoever is your intended subject pool] (who would provide consent, perhaps be compensated for their time). You could then give them a series of patches to approve (some being bug free and others having vulnerabilities). [edit: specifying the population of a study is pretty important. Getting random students from the University to approve your security patch doesn't make sense. Picking students who successfully completed a computer security course and got a high grade is better than that but again, may not generalize to the real world. One of the most impressive ways I have seen this being done by grad students was a user study by John Ousterhout and others on Paxos vs. Raft. IIRC, they wanted to claim that Raft was more understandable or led to fewer bugs. Their study design was excellent. See here for an example: https://www.youtube.com/watch?v=YbZ3zDzDnrw&ab_channel=DiegoOngaro https://www.youtube.com/watch?v=YbZ3zDzDnrw&ab_channel=Diego... ]
• bbarnett 5y ago
  I know this is going to be contentious, but a quick Google shows that * both originated in China (both attended early university there) * one appears to be on a student VISA (undergraduate BA in China, now working on PhD at UoM) China doesn't allow its brightest and best to leave, without cause. When I see research like this, it also makes me think of how "foolish" China sometimes views the West, and the rest of the world. Both for political reasons, eg to keep the masses under control, and due to a legitimate belief we all have in "we are right". Frankly, whilst I have no personal animosity against someone working on behalf of what they see as right, for example, forwarding what they believe to be in the best interests of their country, and fellow citizens? I must still struggle against goals which are contrary to the same for my country, and my citizens. Why all of the above? Well, such things have been know for decades. And while things are heating up: https://www.cbc.ca/news/politics/china-canada-universities-research-waterloo-military-technology-1.5723846 https://www.cbc.ca/news/politics/china-canada-universities-r... "including the claim that some of the core technology behind China's surveillance network was developed in Canadian universities." When one thinks of the concept? That a foreign power, uses your own research funding, research networks, resources, capabilities, to research weaponry and tools to destroy you? Maybe China should scoff at The West. And this sort of research is like pen testing, without direct political ramifications for China itself. Yes, 100%, these two could have just been working within their own personal sphere. They also could be working on research for China. Like how easily one can affect the kernel source code, in plain sight. And even, once caught, how to regain confidence of those "tricked". dang: This post does not deserve to be flagged. Downvote? Sure! Flagged? I've seen far more contentious things stated, when referring to the NSA. And all I'm doing here is providing context, and pointing to the possible motivations of those involved. Others kept stating "Why would the do this?!" and "Why would they be so stupid?". Further, at the end I additionally validate that I am postulating, that 100% it certainly may not be the case. Only that I am speculating on a possible motivation. Are we now not allowed to speculate on motive? If so, I wonder, how many other posts should be flagged. For I see LOADS of people saying "They did this for reason $x". Lastly, anyone believing that China is not a major security concern to the West, must be living under a rock. There are literally hundreds of thousands of news articles, reports, of the Chinese government doing just this. Yet to mention it as a potential cause of someone's actions is.. to receive a flag?
• traveler01 5y ago
  So, for "research" you're screwing around the development of one of the most widely used components in the computer world. Worse, introducing security holes that could reach production environments... That's a really stupid behavior ...
• throwawayffffas 5y ago
  As a user of the linux kernel, I feel legal action against the "researchers" should be pursued.
  • Avamander 5y ago
    Your feelings do not invalidate the results unfortunately.
    • AntiImperialist 5y ago
      In a fairer country, they would be hanged.
  • jnxx 5y ago
    I feel somewhat similar. Since I am using Linux, they ultimately were trying to break the security of my computers. If I do that with any company without their consent, I can easily end up in jail.
    • foobar33333 5y ago
      >they ultimately were trying to break the security of my computers. No they weren't. They made sure the bad code never made it in. They are only guilty of wasting peoples time.
      • azernik 5y ago
        Except, from that email chain, it turns out that some of the bad code did make it into the stable branch. Clearly, they weren't keeping very close tabs on their bad code's progress through the system.
        • x86ARMsRace 5y ago
          At minimum, the argument could be made that they were grossly negligent in how they conducted the experiment.
    • 5y ago
• devit 5y ago
  The project is interesting, but how can they be so dumb as to post these patches under an @umn.edu address instead of using a new pseudonymous identity for each patch?!? I mean, sneakily introducing vulnerabilities obviously only works if you don't start your messages by announcing you are one of the guys known to be trying to do so...
  • EamonnMR 5y ago
    That's kind of the rub. They used a university email to exploit the trust afforded to them as academics and then violated that trust. As a result that trust was revoked. If they want to submit future patches they'll need to do it with random email addresses and will be subject to the scrutiny afforded random email addresses.
    • devit 5y ago
      I doubt an university e-mail gives you significantly increased trust in the kernel community, since those are given to all students in all majors (most of which are of course much less competent at kernel development than the average kernel developer).
      • acd10j 5y ago
        University students could be naive and could be rapped by community if they unintentionally commit harmful patches, but if they send intentionally harmful patches, maintainers can report them to university and they risk getting expelled. In this particular case the research was approved and encouraged by university and hence, and in this process they broke trust placed on university.
      • azernik 5y ago
        There are two different kinds of trust: trust that you're a legitimate person with good intentions, and trust that you're competent. A university or corporate e-mail address helps with the former: even if the individual doesn't put their real name into their email address, the institution still maintains that mapping. The possibility of professional, legal, or social consequences attaching to your real-world identity (as is likely to happen here) is a generally-effective deterrent.
• tester34 5y ago
  Researcher(s) shows that it's relatively not hard to introduce bugs in kernel HN: let's hate researcher(s) instead of process Wow. Assume good faith, I guess?
  • saagarjha 5y ago
    Wasting the time of random open source maintainers who have not consented to your experiment to try to get your paper published is highly unethical; I don't see why this is a bad faith interpretation.
    • tester34 5y ago
      State-level actors / Nation wide actors (fancy terms lately, heh) will not ask anyone for consent
      • saagarjha 5y ago
        This is also unethical.
  • jeroenhd 5y ago
    The concept of the research is quite good. The way this research was carried out, is downright unethical. By submitting their bad code to the actual Linux mailing list, they have made Linux kernel developers part of their research without their knowledge or consent. Some of this vandalism has made it down into the Linux kernel already. These researchers have sabotaged other people's software for their personal gain, another paper to boast about. Had this been done with the developers' consent and with a way to pull out the patches before they actually hit the stable branches, then this could have been a valuable research. It's the way that the research was carried out that's the problem, and that's why everybody is hating on the researches (rather than the research matter itself).
    • mratsim 5y ago
      To provide some parallel on how the research was carried about: I see it as similar to - allowing recording of people without their consent (or warrant), - experimenting on PTSD by inducing PTSD without people consent, - or medical experimentation without the subject consent. And the arguments about not having anyone know: Try to introduce yourself in the White House and when you get caught tell them "I was just testing your security procedures".
• yosito 5y ago
  Can someone explain what the kernel bugs were that were introduced, in general terms?
  • Avamander 5y ago
    None.
  • slenk 5y ago
    Does it matter? They intentionally used their position as a university to push patches with malicious intent through.
    • yosito 5y ago
      It matters for the sake of understanding what was going on, and why the issues weren't caught in review.
• cblconfederate 5y ago
  I guess someone had to do this unethical experiment, but otoh, what is the value here? There's a high chance someone would later find these "intentional bugs" , it's how open source works anyway. They just proved that OSS is not military-grade , but nobody thought so anyway
  • Avamander 5y ago
    > but nobody thought so anyway A lot of people claim that there's a lot of eyes on the code and thus introducing vulnerabilities is unlikely. This research clearly has bruised some egos bad.
    • varispeed 5y ago
      Nothing is perfect, but is it better than not having any eyes? If anything, this shows that more eyes is needed.
      • oefrha 5y ago
        The argument isn’t having no eyes is better than some eyes. Rather, it’s commonly argued that open source is better for security because there are more eyes on it. What this research demonstrates is that you can quite easily slip back doors into an open contribution (which is often but not always associated with open source) project with supposedly the most eyes on it. That’s not true for any closed source project which is definitely not open contribution. (You can go for an open source supply chain attack, but that’s again a problem for open source.)
        • goodpoint 5y ago
          > it’s commonly argued that open source is better for security because there are more eyes on it. > What this research demonstrates is that you can quite easily slip back doors into an open contribution To make a fair comparison you should contrast it with companies or employees placing a backdoors into their own closed source software. It's extremely easy to do and equally difficult to spot for end users.
• perfunctory 5y ago
  I don't quite understand the outrage. Quite sure most HN readers were doing/involved in similar experiments one way or another. Isn't A/B testing an experiment on consumers (people) without their consent?
  • 1_player 5y ago
    There is a sea of difference between A/B testing your own property, and maliciously introducing a bug on a critical piece of software that's running on billions of devices.
    • InsomniacL 5y ago
      >> https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... "We did not introduce or intend to introduce any bug or vulnerability in the Linux kernel. All the bug-introducing patches stayed only in the email exchanges, without being adopted or merged into any Linux branch, which was explicitly confirmed by maintainers. Therefore, the bug-introducing patches in the email did not even become a Git commit in any Linux branch. None of the Linux users would be affected."
      • _djo_ 5y ago
        That's a false claim, though. There's evidence that at least one of the students involved did not do anything to alert kernel maintainers or prevent their code from reaching stable. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.15&qt=author&q=pakki001%40umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
      • DetroitThrow 5y ago
        That seems to directly contradict gkh and others (including the researchers) in the email exchange in the original post - these vulnerable patches reached stable trees and maintainers had to revert them. They may not have been included in a release, but should gkh not have intervened *this would have reached users*, especially if the researchers weren't apparently aware their commits were reaching stable.
• maccard 5y ago
  Is there a more readable version of this available somewhere? I really struggle to follow the unformatted mailing list format.
  • Synaesthesia 5y ago
    Just keep hitting the "next" link to follow the thread.
    • maccard 5y ago
      The next link is one hyperlink buried in the middle of the wall of text, and simply appends the new message to the existing one. It also differentiates between prev and parent? It's super unclear.
      • azernik 5y ago
        Scroll down a bit farther to see the full comment tree. "Next" goes approximately down the tree in the order it's displayed on the page, by depth-first search. "Prev" just reverses the same process as "Next". "Parent" differs from "prev" in that it goes to the parent e-mail even if this email has earlier siblings. (Generally, I just scroll down to the tree view and click around manually.)
      • scbrg 5y ago
        The page has four sections, divided by <hr> tags; 1) The email message, with a few headers included 2) A thread overview, with all emails in the thread 3) Instructions on how to reply 4) Information about how to access the list archives. You need only care about (1) and (2). The difference between prev and parent is indicated by the tree view in (2). The previous one is the previous one in the tree, which might not necessarily be the parent if the parent has spawned earlier replies.
  • Seirdy 5y ago
    Scroll down to the "thread overview". There you can see the thread summarized in a tree layout, which makes more sense since asynchronous discussion isn't typically linear. The current message in the tree is highlighted with the indicator "[this message]"; you can see replies branch out below it and parent messages above it.
• noxer 5y ago
  Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Sure it would be nice to ask but at the same time it renders the testing useless. They wanted to see how the review goes if they aren't aware that someone is testing them. You cant do this with consent. The wasting time argument is nonsense too its not like they did this thousands of times and beside that, reviewing a intentional bad code is not wasting time is just as productive as reviewing "good" code and together with the patch-patch it should be even more valuable work. It not only or adds a patch it also make the reviewer better. Yeah it aint fun if people trick you or point out you did not succeed in what you tried to do. But instead of playing the victim an play the unethical human experiment card maybe focus on improving.
  • francasso 5y ago
    Agreed, in fact the review process worked and now they are going to ban all contributions from that university, as it should be. I think it all worked out perfectly
    • noxer 5y ago
      Pathetic, it did not work at all, they told em whenever they missed a planted bug.
  • Chilinot 5y ago
    > Someone does voluntary work and people think that gives them some ethical privilege to be asked before someone puts their work to the test? Yes. Someone sees the work provided to the community for free and thinks that gives them some ethical privilege to put that work to the test?
    • noxer 5y ago
      I have no clue what you try to say, sorry.
  • rcxdude 5y ago
    Or you could cease to do the voluntary work for them, because they clearly are not contributing to your goals. This is what the kernel maintainers have chosen and they have just as much right to do so. And you can perfectly well do this with consent, there's a wealth of knowledge from psychology and sociology on how you can run tests on people with consent and without invalidating the test.
• nspattak 5y ago
  WTF? They are experimenting with people without their consent? And they haven't been kicked out of the academic community????
• ilammy 5y ago
  So many comments here refrain, “They should have asked for consent first”. But would not that be detrimental to the research subject? Specifically, stealthily introducing security vulnerabilities. How should a consent request look to preserve the surprise factor? A university approaches you and says, “Would it be okay for us to submit some patches with vulnerabilities for review, and you try and guess which ones are good and which ones have bugs?” Of course you would be extra careful when reviewing those specific patches. But real malicious actors would be so kind and ethical as to announce their intentions beforehand.
  • hn8788 5y ago
    It could have been done similar to how typosquatting research was done for ruby and python packages. The owners of the package repositories were contacted, and the researchers waited for approval before starting. I wasn't a fan of that experiment either for other reasons, but hiding it from everyone isn't the only option. Also, "you wouldn't have allowed me to experiment on you if I'd asked first" is a pretty disgusting attitude to have.
    • DetroitThrow 5y ago
      "you wouldn't have allowed me to experiment on you if I'd asked first" I'm shocked the researchers thought this wasn't textbook a violation of research ethics - we talk about the effects of the Tuskegee Study on the perception of the greater scientific community today. This is a smaller transgression that hasn't resulted in deaths, but when it's not difficult to have researched ethically AND we now spend the time to educate on the importance of ethics, it's perhaps more frustrating.
  • enneff 5y ago
    Well, yeah, but the priority here shouldn't be to allow the researchers to do their work. If they can't do their research ethically then they just can't do it; too bad for them.
  • DetroitThrow 5y ago
    >So many comments here refrain, “They should have asked for consent first”. The Linux kernel is a very large space with many maintainers. It would be possible to reach out to the leadership of the project to ask for approval without notifying maintainers and have the leadership announce "Hey, we're going to start allowing experiments on the contribution process, please let us know if you'd like to opt out", or at least work towards creating such a process to allow experiments on maintainers/commit approval process while also under the overall expectation that experiments may happen but that *they will be reverted before they reach stable trees*. The way they did their work could impact more than just the maintainers and affect the reputation of the Linux project, and to me it's very hard to see how it couldn't have been done in a way that meets standards for ethical research.
• jl2718 5y ago
  I would check their ties to nation-state actors. In closed source, nobody would even check. Modern DevOps has essentially replaced manual code review with unit tests.
  • jnxx 5y ago
    That gives me goose bumps.
  • JohnWhigham 5y ago
    I don't understand why this isn't a more widely-held sentiment. There's been instance after instance of corporate espionage in Western companies involving Chinese actors in the past 2 decades.
  • goldenManatee 5y ago
    Yeah, state-actor scale sabotage was one of my first thoughts. And it gives me no joy to contemplate it. Secondly, the researcher’s attitude sounds high and mighty - making process improvement suggestions when their own ethical compass is in question. Their “experiment” was “what would happen if...”. Well, bans happen. If one starts a fight don’t get indignant over a bloody nose, lol
• pypie 5y ago
  I was expecting this to be about introducing strange bugs and then claiming to fix them in order to get a publication. But the publication is titled "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits"! So I guess it's less feasible than they imagined, at least in this instance.
• gjvc 5y ago
  I hope USENIX et al ban this student / professor / school / university associated with this work from submitting anything to any of their conferences for 10 years. This was his clarification https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... ...in which they have the nerve to say that this is not considered "human research". It most definitely is, given that their attack vector is the same one many people would be keen on using for submitting legitimate requests for getting involved. If anything, this "research" highlights the notion that coding is but a small proportion of programming and delivery of a product, feature, or bugfix from start-to-finish is a much bigger job than many people like to admit to themselves or others.
• readme 5y ago
  these people have no ethics
• kome 5y ago
  Does the University of Minnesota have an ethical review board or research ethics board? They need to be contacted ASAP.
  • parrellel 5y ago
    Apparently, they were and did not care.
    • maze-le 5y ago
      It's possible that they didn't knew what they were doing ( approving of this project) -- not sure if this is better or worse.
• causality0 5y ago
  I respectfully ask you to cease and desist from making wild accusations that are bordering on slander. Responding properly to that statement would require someone to step out of the HN community guidelines.
• moron4hire 5y ago
  It's funny. When someone like RMS or ESR or (formerly) Torvalds is "disrespectful" to open source maintainers, this is called "tough love", but when someone else does it, it's screamed about like it's some kind of high crime, with calls to permanently cancel access for all people even loosely related to the original offender.
  • ajuc 5y ago
    https://www.youtube.com/watch?v=I7Umw70Yulw https://www.youtube.com/watch?v=I7Umw70Yulw
  • mafuy 5y ago
    I don't see how this is related. Being rude in tone, and wasting someone's time, are different things. You make it sound like they are the same. But the opposite of what you propose is true. The maintainers are annoyed by others wasting their time in other cases as well as in this case - it's coherent behavior. And in my opinion, it's sensible to be annoyed when someone wasted your time - be it by lazily made patches or by intentionally broken patches.
    • moron4hire 5y ago
      I'm not the one who is making them sound like the same thing. There are literally people in this thread, saying that "wasting time" is being "disrespectful" to the maintainers.
• svarog-run 5y ago
  I feel like q lot of people here did not interpret this correctly. As far as it's known, garbage code was not introduced into kernel.It was caught in the review process literally on the same day. However, there has been merged code from the same people, which is not necessarily vulnerable. As a precaution the older commits are also being reverted, as these people have been identified as bad actors
  • mort96 5y ago
    Note that the commits which have been merged previously have also been intentionally garbage and misleading code, just without any obvious way to exploit them. For example, https://lore.kernel.org/lkml/20210407000913.2207831-1-pakki001@umn.edu/ https://lore.kernel.org/lkml/20210407000913.2207831-1-pakki0... has been accepted since April 7, and it's an obviously a commit meant to _look_ like a bug fix while having no actual effect. (The line `rm = NULL;` and the line `if (was_on_sock && rm)` operate on different variables called `rm`.) That means that the researchers got bogus code into the kernel, got it accepted, and then said nothing for two weeks as the bogus commit spread through the Linux development process and ended up in the stable tree, and, potentially, in forks.
• deleted 5y ago
  [deleted]
• duerra 5y ago
  I'll give you one guess nation states do.
• TacticalCoder 5y ago
  Or some enemy state pawn(s) trying to add backdoors and then use the excuse of "university research paper" should they get caught?
• ansible 5y ago
  I still don't get the point of this "research". You're just testing the review ability of particular Linux kernel maintainers at a particular point in time. How does that generalize to the extent needed for it to be valid research on open source software development in general? You would need to run this "experiment" hundreds or thousands of times across most major open source projects.
  • scoutt 5y ago
    >the point of this "research". I think it's mostly "finger pointing": you need one exception to break a rule. If the rule is "open source is more secure than closed source because community/auditing/etc.", now with a paper demonstrating that this rule is not always true you can write a nice Medium article for your closed-source product, quoting said paper, claiming that your closed-source product is more secure than the open competitor.
    • UncleMeat 5y ago
      I don't think this is correct. The authors have contributed a large number of legitimate bugfixes to the kernel. I think they really did believe that process changes can make the kernel safer and that by doing this research they can encourage that change and make the community better. They were grossly wrong, of course. The work is extremely unethical. But I don't believe that their other actions are consistent with a "we hate OSS and want to prove it is bad" ethos.
      • deleted 5y ago
        [deleted]
  • fouric 5y ago
    The Linux kernel is one of the largest open-source projects in existence, so my guess is that they were aiming to show that "because the Linux kernel review process doesn't protect against these attacks, most open-source project will also be vulnerable" - "the best can't stop it, so neither will the rest".
• deleted 5y ago
  [deleted]
• lfc07 5y ago
  Their research could have been an advisory email or a blogpost for the maintainers without the nasty experiments. If they really cared for OSS they would have have collaborated with the maintainers and persuaded them to use their software tools for patch work. There is research for good of all and there is research for selfish gains. I am convinced this is the later.
• metalliqaz 5y ago
  Wow, shocking and completely unethical by that professor.
• rzwitserloot 5y ago
  The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pakki, writes a reply taking offense at the 'slander' and indicating that the commit was in good faith[1]. Greg KH then immediately calls bullshit on this, and then proceeds to ban the entire university from making commits [2]. The thread then gets down to business and starts coordinating revert patches for everything committed by University of Minnesota email addresses. As was noted, this obviously has a bunch of collateral damage, but such drastic measures seem like a balanced response, considering that this university decided to _experiment_ on the kernel team and then lie about it when confronted (presumably, that lie is simply continuing their experiment of 'what would someone intentionally trying to add malicious code to the kernel do')? * Abhi Shelat also chimes in with links to UMN's Institutional Review Board along with documentation on the UMN policies for ethical review. [3] [1]: Message has since been deleted, so I'm going by the content of it as quoted in Greg KH's followup, see footnote 2 [2]: https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah... [3]: https://lore.kernel.org/linux-nfs/3B9A54F7-6A61-4A34-9EAC-95332709BAE7@northeastern.edu/#t https://lore.kernel.org/linux-nfs/3B9A54F7-6A61-4A34-9EAC-95...
  • gher-shyu3i 5y ago
    > The thread then gets down to business and starts coordinating revert patches for everything committed by University of Minnesota email addresses. What's preventing those bad actors from not using a UMN email address?
    • mcdonje 5y ago
      How would you catch those?
    • Avamander 5y ago
      Literally nothing. Instead of actual actions to improve the process it's only feel-good actions without any actual benefit to the kernel's security.
• darau1 5y ago
  So FOSS is insecure if maintainers are lazy? This would hold true for any piece of software, wouldn't it? The difference here is that even though the "hypocrite commits" /were/ accepted, they were spotted soon after. Something that might not have happened quite as quickly in a closed source project.
• crazypython 5y ago
  Trust is currency. Trust is an asset.
• devillius 5y ago
  An appropriate place to make a report: https://compliance.umn.edu/ https://compliance.umn.edu/
• bigbillheck 5y ago
  So how does this differ from the Sokal hoax thing?
  • cblconfederate 5y ago
    Sokal didn't try to pass harmful ideas, just nonsense.
    • sltkr 5y ago
      The patch in the posted mail thread is mostly harmless nonsense too. It's a no-op change that doesn't introduce a bug; at worst it makes the code slightly less readable.
      • cblconfederate 5y ago
        then the title of this post is false, but given their previous paper they probably wanted to inject more serious bugs. if only noop code can pass, then if anything it's good for linux (this is not really noop, it would add some slight delay)
• jokoon 5y ago
  I'm pretty confident the NSA has been doing this for at least two decades, it's not a crazy enough conspiracy theory. Inserting backdoors in the form of bugs is not difficult. Just hijack the machine of a maintainer, insert a well placed semicolon, done! Do you remember the quote of Linus Torvalds ? "Given enough eye balls, all bugs are shallow." ? Do you really believe the Linux source code is being reviewed for bugs? By the way, how do you write tests for a kernel? I like open source, but security implies a lot of different problems and open source is not always better for security.
• autoconfig 5y ago
  A lot of people seem to consider this meaningless and a waste of time. If we disregard the the problems with the patches reaching stable branches for a second (which clearly is problematic), what is the difference between this and companies conducting red team exercises? It seems to me a potentially real and dangerous attack vector has been put under the spotlight here. Increasing awareness around this can't be all bad, particularly in a time where state sponsored cyber attacks are getting ever more severe.
• segmondy 5y ago
  Uhhh, I just read the paper, I stopped reading when I read what I pasted below. You attempt to introduce severe security bugs into the kernel and this is your solution? To mitigate the risks, we make several suggestions. First, OSS projects would be suggested to update the code of conduct by adding a code like "By submitting the patch, I agree to not intend to introduce bugs."
  • asddubs 5y ago
    that'll solve it!
• mryalamanchi 5y ago
  They just wasted the community's time. No wonder Linus Trovalds goes batshit crazy on these kind of people!
• LanceH 5y ago
  Committing a non-volunteer of your experiment to work, and attempting to destroy their product of their work surely isn't ethical research.
• ficiek 5y ago
  Is introducing bugs into computer systems on purpose like this in some way illegal in the USA? I understand that Linux is run by a ton of government agencies as well, would they take interest in this?
• deleted 5y ago
  [deleted]
• nabla9 5y ago
  If it was up to me, I would 1) send ethics complaint to the University of Minnesota, and 2) report this to FBI cyber crime division.
• kingsuper20 5y ago
  Since there is bound to be a sort of trust hierarchy in these commits, is it possible that bonafide name-brand university people/email addresses come with an imprimatur that has now been damaged generally? Given the size and complexity of the Linux (/GNU) codeworld, I have to wonder if they are coming up against (or already did) the practical limits of assuring safety and quality using the current model of development.
• liendolucas 5y ago
  Could have this happened also on other open source projects like FreeBSD, OpenBSD, etc or other popular open source software?
  • twic 5y ago
    This is a really important question, and the way to answer it is for someone to try it.
• deleted 5y ago
  [deleted]
• Aissen 5y ago
  Greg does not joke around: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... [PATCH 000/190] Revertion of all of the umn.edu commits
  • sesuximo 5y ago
    How does the kernel still run after reverting like this?
    • dcchambers 5y ago
      I was wondering the same thing. From the Patch itself: > This patchset has the "easy" reverts, there are 68 remaining ones that need to be manually reviewed. Some of them are not able to be reverted as they already have been reverted, or fixed up with follow-on patches as they were determined to be invalid. Proof that these submissions were almost universally wrong.
    • deleted 5y ago
      [deleted]
    • finnthehuman 5y ago
      The answer is somewhere between "it's 'only' 190 patches" and "Greg posting this patch series doesn't mean it's applied to stable yet"
    • nousermane 5y ago
      In all likelihood, it'll run just fine. Skimming through subject lines of 190 commits being reverted here, every single one of them is along the lines of "add refcount/NULL/etc check and conditionally do (or do not) de-allocate memory before error-path return". I.e. worst case - this will reintroduce some rare memory leak or memory lifecycle bug. Also, all of patches in question are in drivers. So depending on hardware used, any given system's user is likely to only have to worry about 2-3, maybe 5 of the patches, not all 190.
  • de6u99er 5y ago
    >Some of them are not able to be reverted as they already have been reverted, or fixed up with follow-on patches as they were determined to be invalid. Proof that these submissions were almost universally wrong.
• uglygoblin 5y ago
  If the researchers desired outcome is more vigilance during patches and contributions I guess they might achieve that outcome?
• arua442 5y ago
  Disgusting.
• dcchambers 5y ago
  So I won't lie, this seems like an interesting experiment and I can understand why the professor/research students at UMN wanted to do it, but my god the collateral damage against the University is massive. Banning all contributions from a major University is no joke. I also completely understand the scorched earth response from Greg. Fascinating.
• WaitWaitWha 5y ago
  There is so much disdain for unethical, ivory tower thinking in universities, this is not helping. But, allow me to pull a different thread. How liable is the professor, the IRB, and the university if there is any calamity caused by the known code? What is the high level difference between their action, and spreading malware intentionally?
• omginternets 5y ago
  I did my Ph.D in cognitive neuroscience, where I conducted experiments on human subjects. Running these kinds of experiments required approval from an ethics committee, which for all their faults (and there are many), are quite good at catching this kind of shenanigans. Is there not some sort of equivalent in this field?
  • angry_octet 5y ago
    It seems they lied to the ethics committee. But I'm not holding my breath for the University to sanction them or withdraw/EoC their papers, because Universities prefer to have these things swept under the carpet.
    • forgotpwd16 5y ago
      >they lied to the ethics committee That'll be a fraud, no?
      • angry_octet 5y ago
        Depends on the history of UMN CS submissions for ethics review, how they were advised to complete the exemption request, whether they made false statements or omitted something, whether they intended to deceive, etc. The requirements arising from US Govt grant funding may well be more strict than UMN.
    • mlindner 5y ago
      There's no evidence of that. It appears to be purely a rumor being spread around there with no facts to back it up.
• biffstallion 5y ago
  Ahh Minnesota... land of out-of-control and local government-supported rioting... so I guess shenanigans are expected.
• rincebrain 5y ago
  Prior discussion: https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670
  • alexfromapex 5y ago
    Here's the research article linked there, for those interested: https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...
    • amir734jj 5y ago
      Please correct me if I'm wrong. So he (PhD student) was introducing bad code as part of research? And publishes a paper to show how he successfully introduced bad code.
      • alexfromapex 5y ago
        It seems that Aditya Pakki was the one introducing shady code to the kernel and was caught. He is listed as an author on several other very similar papers (https://scholar.google.com/citations?user=O9WEZuoAAAAJ&hl=en https://scholar.google.com/citations?user=O9WEZuoAAAAJ&hl=en) with authors Wu and Lu about automatically detecting "missing-check bugs" and other security issues which they purport to want to fix but this research paper explicitly discusses submitting "fixes" that have latent security bugs in them.
  • dang 5y ago
    Merging them now...
• treesknees 5y ago
  The full title is "Linux bans University of Minnesota for sending buggy patches in the name of research" and it seems to justify the ban. It's not as though these students were just bad programmers, they were intentionally introducing bugs, performing unethical experimentation on volunteers and members of another organization without their consent. Unfortunately even if the latest submissions were sent with good intentions and have nothing to do with the bug research, the University has certainly lost the trust of the kernel maintainers.
  • xibalba 5y ago
    From the looks of the dialogue, it was all of the above with the addition of lying about what they were up to when confronted. I would think all of this constitutes a serious violation of any real university's research ethics standards.
  • xroche 5y ago
    The full titre should actually be "Linux bans University of Minnesota for sending buggy patches in the name of research and thinking they can add insult to injury by playing the victims" > I respectfully ask you to cease and desist from making wild accusations that are bordering on slander. > These patches were sent as part of a new static analyzer that I wrote and it's sensitivity is obviously not great. I sent patches on the hopes to get feedback. We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear. > Obviously, it is a wrong step but your preconceived biases are so strong that you make allegations without merit nor give us any benefit of doubt. I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. This idiot should be banned from the University, not from the linux kernel.
    • nyolfen 5y ago
      His department presumably allowed this to proceed
• incrudible 5y ago
  From an infosec perspective, I think this is a knee-jerk response to someone attempting a penetration test in good faith and failing. The system appears to have worked, so that's good news for Linux. On the other hand, now that the university has been banned, they won't be able to find holes in the process that may remain, that's bad news for Linux.
  • slenk 5y ago
    Is it in good faith when they were already told explicitly to not continue? That's the point where it becomes intentionally malicious IMO
• donatj 5y ago
  I wish the title were clearer. Linux bans University of Minnesota for sending buggy patches on purpose.
  • SAI_Peregrinus 5y ago
    Or just "Linux bans University of Minnesota for sending malicious patches."
  • ajross 5y ago
    The term of art for an intentional bug that deliberately introduces a security flaw is a "trojan" (from "Trojan Horse", of course). UMN trojaned the kernel. This is indeed just wildly irresponsible.
• random5634 5y ago
  How does something like this get through IRB - I always felt IRB was over the top - and then they approve something like this? UMN looks pretty shoddy - the response from the researcher saying these were automated by a tool looks like a potential lie.
  • deleted 5y ago
    [deleted]
  • thaeli 5y ago
    They obtained an "IRB-exempt letter" because their IRB found that this was not human research. It's quite likely that the IRB made this finding based on a misrepresentation of the research during that initial stage; once they had an exemption letter the IRB wouldn't be looking any closer.
    • lbarrow 5y ago
      My understanding is that it's pretty common for CS departments to get IRB exemption even when human participants are tangentially involved in studies.
      • lmkg 5y ago
        I've seen from a distance one CS department struggle with IRB to get approval for using Amazon Mechanical Turk to label pictures for computer vision datasets. I believe the resolution was creating a specialized approval process for that family of tasks.
      • waheoo 5y ago
        That sounds like a disconnect from reality.
        • WORLD_ENDS_SOON 5y ago
          I think it is because many labs in CS departments do very little research involving human subjects (e.g. a machine learning lab or a theory lab), so within those labs there isn't really an expectation that everything goes through IRB. Many CS graduate students likely never have to interact with IRB at all, so they probably don't even know when it is necessary to involve IRB. The rules for what requires IRB involvement are also somewhat open to interpretation. For example, surveys are often exempt depending on what the survey is asking about.
• kleiba 5y ago
  How is such a ban going to be effective? The "researchers" could easily continue their experiments using different credentials, right?
  • NtrllyIntrstd 5y ago
    I think it is more of a message than a solution
  • krig 5y ago
    Thus moving from merely unethical to actually fraudulent? Although from the email exchanges it seems they are already making fraudulent statements... At least it might prompt the University to take action against the researchers.
  • rrmm 5y ago
    The ban is aimed more at the UMN dept overseeing the reserach than at preventing continued "experiments." I imagine it would also make continued experiments even more unethical.
  • unmole 5y ago
    Any data collected from such "research" would be unpublishable and therefore worthless.
  • notyourday 5y ago
    > How is such a ban going to be effective? It trashes University of Minnesota in the press. What is going to happen is that the president of the university now is going to hear about it, so will the provost and so will people in charge of doling money. That will rapidly fix the professor problem. While people may think that tenure professors get to do what they want, they never win in a war with a president and a provost. That professor is toast. And so are his researchers
    • chaosite 5y ago
      The professor's site says that he is an assistant professor, i.e., he doesn't actually have tenure yet.
• deleted 5y ago
  [deleted]
• Taylor_OD 5y ago
  The professor is going to give a ted talk in about a year talking about how he got banned from open source development and the five things he learned from it.
• macspoofing 5y ago
  Linux maintainers should log a complaint with the University's ethics board. You can't just experiment on people without consent.
  • hn8788 5y ago
    One of the other emails in the chain says they already did. > This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university...
  • s_dev 5y ago
    I'm not sure it is experimenting people without consent. Though it's certainly shitty and opportunitstic of UoM to do this. Linux Bug fixes are open to the public. The experiment isn't on people but on bugs. I would be like filing different customer support complaints to change the behavior of a company -- you're not experimenting on people but the process of how that company interfaces with the public. I see no wrong here including the Linux maintainers banning submissions from UoM which is completely justified as time wasting.
    • HPsquared 5y ago
      It's experimenting with how specific people manage bugs.
    • garyfirestorm 5y ago
      UoM generally refers to University of Michigan. You probably meant UMN.
    • koheripbal 5y ago
      I'm not sure which form of ethical violation this is, but it's malicious and should be reported.
    • travisjungroth 5y ago
      I assure you that customer support reps and Linux maintainers are in fact people.
  • 5y ago
• WrtCdEvrydy 5y ago
  I just want you to know that this is extremely unethical to create a paper where you attempt to discredit others by just using your university's reputation to try to create vulnerabilities on purpose. I back your decision and fuck these people. I will additionally be sending a strongly worded email to this person, their advisor and their whoever's in charge of this joke of a computer science school. Sometimes I wish we had the ABA equivalent for computer science.
  • incrudible 5y ago
    I completely disagree with this framing. A real malicious actor is going to be planted in some reputable institution, creating errors that look like honest mistakes. How do you test if the process catches such vulnerabilities? You do it the just the way that these researchers did. Yes, it creates extra homework for some people with certain responsibilities, that doesn't mean it's unethical. Don't shoot the messenger.
    • hctaw 5y ago
      These are real malicious actors.
      • incrudible 5y ago
        You don't know that, but that's also irrelevant. There's always plausible deniability with such bugs. The point is that you need to catch the errors no matter where they come from, because you can't trust anyone.
        • WrtCdEvrydy 5y ago
          But that's the point, you're a security researcher wanting to get the honors of getting a PhD, not a petty criminal, so you're supposed to have a strong ethical background. A security researcher doesn't just delete a whole hard drive's worth of data to prove they have the rights to delete things, they are trusted for this reason.
        • 5y ago
• qalmakka 5y ago
  Well, they had it coming. They abused the community's trust once in order to gain data for their research, and now it's understandable GKH has very little regard for them. Any action has consequences.
• WrtCdEvrydy 5y ago
  Yes, and robbing a bank to show that the security is lax is totally fine because the real criminals don't notify you before they rob a bank. Do you understand how dumb that sounds?
  • incrudible 5y ago
    > Do you understand how dumb that sounds? If you make a dumb analogy, that's on you.
    • WrtCdEvrydy 5y ago
      Same analogy... there's a vulnerability and you want to test it? Go set up a test, and notify the people. You really think the Linux kernel guys would change their process if you did this? They'd still do the same things they do.
      • incrudible 5y ago
        > Go set up a test, and notify the people. The vulnerability is in the process, and this was the test. > You really think the Linux kernel guys would change their process if you did this? They'd still do the same things they do. If they're vulnerable to accepting patches with exploits because the review process fails, then the process is broken. Linux isn't some toy, it's critical infrastructure.
        • WrtCdEvrydy 5y ago
          You can test the process without pushing exploits to the real kernel.
          • incrudible 5y ago
            > You can test the process without pushing exploits to the real kernel. No, you can't, because that is the test! If you manage to push exploits to the real kernel, the test failed. If you get caught, the test passes. They did get caught.
• nitinreddy88 5y ago
  Can anyone enlighten me why these were not caught in review process itself?
• javier10e6 5y ago
  The researched yielded non surprising results: Stealthy patches without a proper smoke screen to provide a veil of legitimacy will cause the the purveyor of the patches to become black listed....DUH!
• LegitShady 5y ago
  They should be reported to the authorities for attempting to introduce security vulnerabilities into software intentionally. This is not ok.
  • farisjarrah 5y ago
    What these researchers did was clearly and obviously wrong, but is it actually illegal?
    • deleted 5y ago
      [deleted]
    • LegitShady 5y ago
      It should be reported anyways. This might be only some small part of the malfeasance they're getting up to.
  • chews 5y ago
    Maybe it was those very authorities who wanted them there. Lot's of things have gotten patched and the backdoors don't work as well as they used to... gotta get clever.
  • ActorNightly 5y ago
    The fact that both of the researchers seem to be of Chinese origin should definitely raise some questions. Not the first time things like this have been tried.
    • jlduan 5y ago
      this is classic national origin discrimination. racists are coming out.
      • ActorNightly 5y ago
        Id have the same suspicion if they were Russian. Nothing to do with race, everything to do with national affiliation.
• motohagiography 5y ago
  This isn't friendly pen-testing in a community, this is an attack on critical infrastructure using a university as cover. The foundation should sue the responsible profs personally and seek criminal prosecution. I remember a bunch of U.S. contractors said they did the same thing to one of the openbsd vpn library projects about 15 years ago as well. What this professor is proving out is that open source and (likely, other) high trust networks cannot survive really mendacious participants, but perhaps by mistake, he's showing how important it is to make very harsh and public examples of said actors and their mendacity. I wonder if some of these or other bug contributors have also complained that the culture of the project governance is too aggressive, that project leads can create an unsafe environment, and discourage people from contributing? If counter-intelligence prosecutors pull on this thread, I have no doubt it will lead to unravelling a much broader effort.
  • frombody 5y ago
    I am not knowledgeable enough to know if this intent is provable, but if someone can frame the issue appropriately, it feels like it could be good to report this to the FBI tip line so it is at least on their radar.
  • eatbitseveryday 5y ago
    > The foundation should sue the responsible profs personally and seek criminal prosecution. This is overkill and uncalled for.
    • motohagiography 5y ago
      Organizing an effort, with a written mandate, to knowingly introduce kernel vulnerabilities, through deception, that will spread downstream into other Linux distributions, likely including firmware images, which may not be patched or reverted for months or years - does not warrant a criminal investigation? The foundation should use recourse to the law to signal they are handling it, if only to prevent these profs from being mobbed.
      • 5y ago
• robrtsql 5y ago
  Very embarrassed to see my alma mater in the news today. I was hoping these were just some grad students going rogue but it even looks like the IRB allowed this 'research' to happen.
  • deelowe 5y ago
    It's very likely the IRB was mislead. Don't feel too bad. I saw in one of the comments that the IRB was told that the researchers would be "sending emails," which seems to be an intentionally obtuse phrasing for them submitting malformed kernel patches.
• rubyn00bie 5y ago
  This is supremely fucked up and I’d say is borderline criminal. It’s really lucky asshole researchers like this haven’t caused a bug that cost billions of dollars, or killed someone, because eventually shit like this will... and holy shit will “it was just research” do nothing to save them.
  • goatinaboat 5y ago
    It’s just a shame there is no mechanism in the license to withdraw permission for this so-called university to use Linux at all
    • SuchAnonMuchWow 5y ago
      It is by design, not having these mechanism is one of the goals of free software: free for everyone, no exceptions. See JSON.org License which says it "shall be used for Good, not Evil" and is not considered free software.
      • ar_lan 5y ago
        "Free" being the confusing word here, because it has two meanings, and often are used without context in open source software. Typically, OSS is both definitions at the same time - free monetarily, and "free" as in "freedom" to use. JSON is an interesting case of "free" monetarily but not totally "free for use".
    • malka 5y ago
      A shame today, a godsent another day.
    • andrewzah 5y ago
      That is expressly the opposite goal of open source. If you arbitrarily say foo user cannot use your software, then it is NOT open source. That's more like source-available. Nobody would continue to use linux if they randomly banned people from using it, regardless of the reason. [side note] This is why I despise the term "open source". It obscures the important part of user freedom. The term "Free/libre software" is not perfect, but it doesn't obscure this.
• deleted 5y ago
  [deleted]
• coward76 5y ago
  Make an ethics complaint with the state and get their certification and charter pulled.
  • dylan604 5y ago
    That's a worse death sentence than SMU's for paying players. Even the NCAA didn't kill the school, just the guilty sport program. You're asking the state to pull entire university's charter for a rogue department? Sure, pull the CS department, but I'm sure the other schools at the university had absolutely zero culpibility.
    • bluGill 5y ago
      As a graduate of the UMN, other departments have had their share of issues as well. When I was there they were trying to figure out how to deal with a professor selling medical drugs without FDA permission (the permission did exist in the past, and the drug probably was helpful, but FDA approval was not obtained). I suspect that all of the issues I'm aware of are within normal bounds for any university of that size. That is if kill the UMN you also need to kill Berkley, MIT, and Harvard for their issues of similar magnitude that we just by chance haven't heard about. This is a guess though, I don't know how bad things are.
      • dylan604 5y ago
        That was the same thing said of the SMU punishment. They were not the only school doing it. They were just the ones that got caught.
        • bluGill 5y ago
          Which is probably true. Doesn't excuse it. Note, that I'm not trying to excuse the UMN either.
• beshrkayali 5y ago
  This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.
  • EthanHeilman 5y ago
    >I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. My personal observation is that infosec/cybersecurity academia has been steadily moving to higher ethical standards in research. That doesn't mean that all academics follow this trend, but that unethical research is more likely to get your paper rejected from conferences. Submitting bugs to an open source project is the sort of stunt hackers would have done in 1990 and then presented at a defcon talk.
    • roblabla 5y ago
      > I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. IEEE seems to have no problem with this paper though. >>> On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits Qiushi Wu, and Kangjie Lu. To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. from https://www-users.cs.umn.edu/~kjlu/ https://www-users.cs.umn.edu/~kjlu/
      • neatze 5y ago
        "To appear"
        • JadeNB 5y ago
          "To appear" has a technical meaning in academia, though—it doesn't mean "I hope"; it means "it's been formally accepted but hasn't actually been put in 'print' yet." That doesn't stop someone from lying about it, but it's not a casual claim, and doing so would probably bring community censure (as well as being easily falsifiable after time).
• im3w1l 5y ago
  I can't help but think of the Sokal affair. But I'll leave the comparison to someone more knowledgeable about them both.
  • whatshisface 5y ago
    I'd bet that it was inspired by the Sokal affair. The difference in reaction is probably because people think the purity of Linux is important but the purity of obscure academic journals isn't. (They're probably right, because one fault in Linux will make the whole system insecure, whereas one dumb paper would go in next to the other dumb papers and leave the good papers unharmed.) The similarities are that reviewers can get sleepy no matter what they're reviewing. Troll doll QC staff get sleepy. Nuclear reactor operators get sleepy too.
    • BugsJustFindMe 5y ago
      > The similarities are that reviewers can Most people in the outgroup who know about the Sokal Affair but who know nothing about the journal they submitted to aren't aware of this, but Social Text was known to be not peer reviewed at the time. It's not that reviewers failed some test; there explicitly and publicly wasn't a review process. Everyone reading Social Text at the time would have known that and interpreted contents accordingly, so Sokal didn't demonstrate anything of value and was just being a jackass.
• foolfoolz 5y ago
  how can i see these prs?
  • jessaustin 5y ago
    A search on the linked mailing list seems to include a lot of this junk: https://lore.kernel.org/linux-nfs/?q=@umn.edu&x=t https://lore.kernel.org/linux-nfs/?q=@umn.edu&x=t
• neatze 5y ago
  Interesting, if they provided to NSF human subject research section, to me this is potential research ethics issue. Imagine, saying we would like to test how fire department responds to fire, by setting buildings on fire in NYC.
  • andi999 5y ago
    Well, just a small fire which you promise to extinguish yourself if they dont show up on time. Of course nobody can blame you if you didnt manage to extinguish it... Also the buildings are not random, but safety critical infrastructure, but this is good, you can advise later:'put a "please do not ignite" sign on the building'.
• arkh 5y ago
  > I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.
  • john-radio 5y ago
    But G. K-H's correspondence here is completely cordial and professional, and still gets all the results that were needed?
  • colechristensen 5y ago
    I think so. With a large project I think a realist attitude that raises to the level of mean when there’s bullshit around is somewhat necessary to prevent decay. If not you get cluttered up with bad code and people there for the experience. Like how stackoverflow is lost to rule zealots there for the game not for the purpose. Something big and important should be intimidating and isn’t a public service babysitter...
    • ethbr0 5y ago
      It feels like a corollary of memetic assholery in online communities. Essentially the R0 [0] of being a dick. If I have a community, bombarded by a random number of transient bad actors at random times, then if R0 > some threshold, my community inevitably trends to a cesspool, as each bad actor creates more negative members. If I take steps to decrease R0, one of which may indeed be "blunt- and harshness to new contributors", then my community may survive in the face of equivalent pressures. It's a valid point, and seems to have historical support via evidence of many egalitarian / welcoming communities collapsing due to the accumulation of bad faith participants. The key distinction is probably "Are you being blunt / harsh in the service of the primary goal, or ancillary to the mission?" [0] https://en.m.wikipedia.org/wiki/Basic_reproduction_number https://en.m.wikipedia.org/wiki/Basic_reproduction_number
      • depressedpanda 5y ago
        > It's a valid point, and seems to have historical support via evidence of many egalitarian / welcoming communities collapsing due to the accumulation of bad faith participants. Could you provide references to some of this historical support?
• mort96 5y ago
  The previous discussion seems to have suddenly disappeared from the front page: https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670
  • zulban 5y ago
    Thanks for pointing that out. 4 hours old, 1000+ points, it seems to have been hit with an invisible penalty.
    • speedgoose 5y ago
      From what I understood, when a new post has a lot of comments, it disappears from the frontpage.
      • slumpt_ 5y ago
        Absolutely absurd and illogical
        • thatguy0900 5y ago
          It's also related to the up votes. A post with a bad comment to up vote ratio usually means that a flame war is going on
          • krapp 5y ago
            >A post with a bad comment to up vote ratio usually means that a flame war is going on. No it doesn't, not unless most comments typicaly get upvoted, which seems counterintuitive to me. A bad comment to downvote ratio indicates a flamewar, since there are no flamewars without downvotes, but more comments than upvotes just means high comment velocity (which can go either way) or just that no one is saying anything particularly interesting, which isn't implicitly harmful. A flamewar detector that hides popular threads to suppress engagement just in case there might be a flamewar is working at cross purposes with the goal of a forum, which is engagement.
• Radle 5y ago
  @gregkh These patches look like bombs under bridges to me. Do you believe that some open source projects should have legal protection against such actors? The Linux Kernel is pretty much a piece of infrastructure that keeps the internet going.
• veltas 5y ago
  Regardless of whether consent (which was not given) was required, worth pointing out the emails sent to the mailing list were also intentionally misleading, or fraudulent, so some kind of ethic has obviously been violated there.
• duxup 5y ago
  I don't like this university ban approach. Universities are places with lots of different students, professors, and different people with different ideas, and inevitably people who make bad choices. Universities don't often act with a single purpose or intent. That's what makes them interesting. Prone to failure and bad ideas, but also new ideas that you can't do at corporate HQ because you've got a CEO breathing down your neck. At the University of Minnesota there's 50k+ students at the Twin Cities campus alone, 3k plus instructors. Even more at other University of Minnesota campuses. None of those people did anything wrong. Putting the onus on them to effect change to me seems unfair. The people banned didn't do anything wrong. Now the kernel doesn't 'need' any of their contributions, but I think this is a bad method / standard to set to penalize / discourage everyone under an umbrella when they've taken no bad actions themselves. Although I can't put my finger on why, this ban on whole swaths of people in some ways seems very not open source. The folks who did the thing were wrong to do so, but the vast majority of people now impacted by this ban didn't do the thing.
  • formerly_proven 5y ago
    > The people banned didn't do anything wrong. There are ways to do research like this (involve top-level maintainers, prevent patches going further upstream etc.), just sending in buggy code on purpose, then lying about where it came from, is not the way. It very much is wrong in my opinion. And like some other people pointed out, it could quite possibly be a criminal offense in several jurisdictions.
    • dev_tty01 5y ago
      >There are ways to do research like this (involve top-level maintainers, prevent patches going further upstream etc.) This is what I can't grok. Why would you not contact GKH and work together to put a process in place to do this in an ethical and safe manner? If nothing else, it is just basic courtesy. There is perhaps some merit to better understanding and avoiding the introduction of security flaws but this was not the way to do it. Boggles the mind that this group felt that this was appropriate behavior. Disappointing. As far as banning the University, that is precisely the right action. This will force the institution to respond. UMN will have to make changes to address the issue and then the ban can be lifted. It is really the only effective response the maintainers have available to them.
• eecc 5y ago
  > I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Woah, this attempt to incite wokes and cancellers is particularly pernicious.
  • person101x 5y ago
    Cancel Linux! Anyone?
    • laurent92 5y ago
      One may wonder whether the repetitive attacks against Linus on the tone he’s using, until he had to take a break, isn’t a way to cut down Linux’ ability to perform by cutting its head, which would be absolutely excellent for closed-source companies and Amazon. Imagine: If Linux loses its agility, we may have to either “Use Windows because it has continued upgrades” or “purchase Amazon’s version of Linux” which would be the only ones properly maintained and thus certified for, say, government purpose or GDPR purpose. (I’m paying Debian but I’m afraid that might not be enough).
      • bluGill 5y ago
        There are always the BSDs if something happens. Not quite as popular, but the major ones are good enough that to take over completely. (as in if you thought someone would kill you for using Linux you can replace all your linux with some BSD by the end of the day and in a month forget about it) Don't take that as better - that is a different discussion, but they are good enough to substitute and move on for the most part.
• francoisp 5y ago
  Me thinks that If you hold a degree from the University of Minnesota it would be a good idea to let your university know what you think of this.
  • bluGill 5y ago
    I'm trying to figure out how to do that. How can I get my degree changed? Will the university of (anyplace) look at my transcript and let me say I have a degree from them without much effort? I learned a lot, and I generally think my degree is about as good as any other university. (though who knows what has changed since then) I'm glad I never contributed again as an alumni...
    • francoisp 5y ago
      If it would be my univ, I'd send a personal email to the dean. https://cse.umn.edu/college/office-dean#:~:text=Dean%20Mostafa%20(Mos)%20Kaveh&text=As%20dean%2C%20Kaveh%20is%20chief,academic%20programs%20in%20the%20country https://cse.umn.edu/college/office-dean#:~:text=Dean%20Mosta.... If enough grads do that, I would expect the university will do something about it, and that would send a message. It's about where the money comes from in the end; (tuition, grants, research partnerships etc) IMO none of these sources would be very happy about what might amount to defacement of public property and waste of the time of people that are working for the good of mankind by providing free tools(bicycle of the mind) to future generations. There is no novelty in this research; bad actors have been trying to introduce bad patches for as long as open source has been open.
      • WkndTriathlete 5y ago
        That's my univ, and I just did exactly that. Mos Kaveh happened to be head of the EE department when I was there for EE. He's a good guy and had a good way of managing stressed-out upper-division honors EE students, so I'm hopeful that he will take action on this.
  • McGlockenshire 5y ago
    > it would be a good idea to let your university know what you think of this. Unless there's something particularly different about University of Minnesota compared to other universities, something tells me that they won't give a crap unless you're a donor.
• wuxb 5y ago
  Sending those patches is just disgraceful. I guess they're using the edu emails so banning the university is a very effective action so someone will respond to it. Otherwise, the researchers will just quietly switch to other communities such as Apache or GNU. Who want buggy patches?
  • danielbot 5y ago
    They used gmail.
• mosselman 5y ago
  The tone of Aditya Pakki's message makes me think they would be very well served by reading 'How to Win Friends & Influence People' by Dale Carnegie. This is obviously the complete opposite of how you should be communicating with someone in most situations let alone when you want something from them. I have sure been there though so if anything, take this as a book recommendation for 'How to Win Friends & Influence People'.
  • runeks 5y ago
    I’ve seen this book mentioned a couple of times on HN now. I’m curious: did you learn about this book from the fourth season of the Fargo? This is where I encountered it first.
    • jacobsenscott 5y ago
      The book is very famous - it launched the "self help" genra. I've never read it, but I've heard it is fairly shallow guide on manipulating people to get what you want out of them.
      • inimino 5y ago
        "genre" > I've never read it, but If you've never read it, maybe just leave it at that. > manipulating people You mean "influencing people", like it says right in the title? It's a book that has helped millions, which is why it continues to be widely recommended. It's not for everyone. The advice seems obvious to some, which of course is why it can be so valuable for others.
      • op00to 5y ago
        It's more like: "ask people about themselves, they like talking about themselves", than secret jedi mind tricks. Not really nefarious.
      • mosselman 5y ago
        You are totally right that the title makes it seem that way, I thought so too at first. Now I am happy that I have proven myself wrong by reading it. It is more like what I’d have liked my parents had taught me about social situations and empathy. Most of the points in the book are about sincere empathy for others. Just have a go at it, it costs less than a euro as an e-book and it read so easily that you’ll be done in no time.
• angry_octet 5y ago
  Research without ethics is research without value. Unbelievable that this could have passed ethics review, so I'd bet it was never reviewed. Big black eye for University of Minnesota. Imagine if you are another doctoral student is CS/EE and this tool has ruined your ability to participate in Linux.
  • gruez 5y ago
    > Research without ethics is research without value. didn't we learn a lot from nazi/japanese experiments from ww2?
    • gambiting 5y ago
      From my understanding - no, actually. We learnt a bit, on the very extreme scale of things, but most of the "experiments" were not conducted in any kind of way that would yield usable data.
      • db48x 5y ago
        Yes and no. It’s my understanding that the Germans pioneered the field of implanted medical prostheses (like titanium pins to stabilize broken bones). A lot of that research was done on prisoners, and they were even kind enough to extend the benefits of the medical treatments that they developed to prisoners of war (no sarcasm intended).
    • bluGill 5y ago
      We did. Often we wish they could have got more decimal points in a measurement, or had known how to check for some factor. Despite all the gains and potential breakthroughs lost nobody is willing to repeat them or anything like them. I know just enough medically people given 2 weeks to live who were still around 10 years latter that I can't think of any situation where I'd make an exception. Though what a lot is is also open to question. Much of what we learned isn't that useful to real world problems. However some has been important.
      • 5y ago
• CTDOCodebases 5y ago
  Fair. You are either part of the solution, part of the problem or just part of the landscape.
• returningfory2 5y ago
  Commenters have been reasonably accusing the researchers of bad practice, but I think there's another possible take here based on Hanlon's razor: "never attribute to malice that which is adequately explained by stupidity". If you look at the website of the PhD student involved [1], they seem to be writing mostly legitimate papers about, for example, using static analysis to find bugs. In this kind of research, having a good reputation in the kernel community is probably pretty valuable because it allows you to develop and apply research to the kernel and get some publications/publicity out of that. But now, by participating in this separate unethical research about OSS process, they've damaged their professional reputation and probably setback their career somewhat. In this interpretation, their other changes were made in good faith, but now have been tainted by the controversial paper. [1] https://qiushiwu.github.io/ https://qiushiwu.github.io/
  • MattGaiser 5y ago
    I suppose it depends on what you make of Greg's opinion (I am only vaguely familiar with this topic, so I have none). > They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? Greg didn't think that the static analysis excuse could be legitimate as the quality was garbage.
    • slenk 5y ago
      I know this is old, but got a link? That LMKL thread is long
  • qiqing 5y ago
    That looks like a different person from the name in the article.
• Dumbdo 5y ago
  In the follow up chain it was stated that some of their patches made it to stable: https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.c... Can someone who's more invested into kernel devel find them and analyze their impact? That sounds pretty interesting to me. Edit: This is the patch reverting all commits from that mail domain: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... Edit 2: Now that the first responses to the reversion are trickling in, some merged patched were indeed discovered to be malicious, like the following. Most of them seem to be fine though or at least non malicious. https://lore.kernel.org/lkml/78ac6ee8-8e7c-bd4c-a3a7-5a90c7ccb399@roeck-us.net/ https://lore.kernel.org/lkml/78ac6ee8-8e7c-bd4c-a3a7-5a90c7c...
• f46f7ab7de71 5y ago
  Chink spies
• devwastaken 5y ago
  this is not surprising to me given the quality of minnesotta universities. U of M should be banned from existence. I remember vividly how they'd break their budgets redesigning cafeterias, hiring low quality 'professors' that refused to make paper assignments digitized. (They didnt know how). Artificially inflated dorm costs without access to affordable cooking. (Meal plans only). They have bankrupted plenty of students that were forced to drop out due to their policies on mental health. It's essentially against policy to be depressed or suicidal. They predate on kids in high school who don't at all know what they're signing up for. Defund federal student loans. Make these universities stand on their own two feet or be replaced by something better.
• booleandilemma 5y ago
  The UMN had worked on a research paper dubbed "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits". I guess it's not as feasible as they thought.
• resoluteteeth 5y ago
  I suspect the university will take some sort of action now that this has turned into incredibly bad press (although they really should have done something earlier).
• ltfish 5y ago
  Some clarifications since they are unclear in the original report. - Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper. - According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kernel. The three attempts did not even become Git commits. Greg has all reasons to be unhappy since they were unknowingly experimented on and used as lab rats. However, the round of patches that triggered his anger *are very likely* to have nothing to do with the three intentionally incorrect patch attempts leading to the paper. Many people on HN do not seem to know this. [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
  • hpoe 5y ago
    It doesn't matter. I think this is totally appropriate. A group of students are submitting purposely buggy patches? It isn't the kernels team to sift through and distinguish they come down and nuke the entire university. This sends a message to any other University thinking of a similar stunt you try this bull hockey you and your entire university are going to get caught in the blast radius. In short "f** around, find out"
    • shadowgovt 5y ago
      On the plus side, I guess they get a hell of a result for that research paper they were working on. "We sought to probe vulnerabilities of the open-source public-development process, and our results include a methodology for getting an entire university's email domain banned from contributing."
      • the_duke 5y ago
        Which will (hopefully) not be accepted by any reputable journal.
      • mirchibajji 5y ago
        Given the attitude of "the researchers" and an earlier paper [1] so far, somehow I doubt they will act in good faith this time. For instance: "D. Feedback of the Linux Community. We summarized our findings and suggestions, and reported them to the Linux community. Here we briefly present their feedback. First, the Linux community mentioned that they will not accept preventive patches and will fix code only when it goes wrong. They hope kernel hardening features like KASLR can mitigate impacts from unfixed vulnerabilities. Second, they believed that the great Linux community is built upon trust. That is, they aim to treat everyone equally and would not assume that some contributors might be malicious. Third, they mentioned that bug-introducing patches is a known problem in the community. They also admitted that the patch review is largely manual and may make mistakes. However, they would do their best to review the patches. Forth, they stated that Linux and many companies are continually running bug-finding tools to prevent security bugs from hurting the world. Last, they mentioned that raising the awareness of the risks would be hard because the community is too large." [1] https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.io/main/papers/OpenSourceInsecurity.pdf https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i...
• dsr12 5y ago
  Plonk is a Usenet jargon term for adding a particular poster to one's kill file so that poster's future postings are completely ignored. Link: https://en.wikipedia.org/wiki/Plonk_(Usenet) https://en.wikipedia.org/wiki/Plonk_(Usenet)
• andi999 5y ago
  Somebody should have told them that since microsoft is now pro-open source this wouldnt land any of them a cushy position after the blowup at uni.
• shadowgovt 5y ago
  Academic reputation has always mattered, but I can't recall the last time I've seen an example as stark as "I attend a university that is forbidden from submitting patches to the Linux kernel."
• hardsoftnfloppy 5y ago
  Remember, the university of Minnesota was number 8 for top .edu addresses dumped in the Ashley Madison hack. Scum of the earth.
• enz 5y ago
  I wonder if they can be sued (by the Linux Foundation, maybe) for that...
• theflyinghorse 5y ago
  "It's just a prank, bro!" Incredible that the university researches decided this was a good idea. Has noone in the university voiced concern that perhaps this is a bad idea?
• mabbo 5y ago
  I think Greg KH would have been wise to add a time limit on this ban. Make it a 10-year block, for example, rather than one with no specific end-date. Imagine what happens 25 years from now as some ground-breaking security research is being done at Minnesota, and they all groan: "Right, shoot, back in 2021 some dumb prof got us banned forever from submitting patches". Is there a mechanism for University of Minnesota to appeal, someday? Even murders have parole hearings, eventually.
  • thedanbob 5y ago
    Presumably they could just talk to the maintainers at that time and have a reasonable discussion.
  • bluGill 5y ago
    It isn't hard to get a gmail type address and submit from there.
• fefe23 5y ago
  Reminds me of the Tuskegee Symphilis Study. Sure we infected you with Syphilis without asking for permission first, but we did it for science!
• tsujp 5y ago
  This is categorically unethical behaviour. Attempting to get malicious code into an open source project that powers a large set of the worlds infrastructure — or even a small project — should be punished in my view. Actors are known, its been stated by the actors as intentional. I think the Linux Foundation should make an example of this.
• mfringel 5y ago
  When James O' Keefe tries to run a fake witness scam on the Washington Post, and the newspaper successfully detects it, the community responds with "Well played!" When a university submits intentionally buggy patches to the Linux Kernel, and the maintainers successfully detect it, the community responds with "That was an incredibly scummy thing to do." I sense a teachable moment, here.
  • noofen 5y ago
    Being a Linux Kernel maintainer is a thankless job. Being a Washington Post journalist is nothing more than doing Bezos' bidding and dividing the country in the name of profit.
  • loeg 5y ago
    I think O'Keefe is scummy, too.
• francoisp 5y ago
  I fail to see how this does not amount to vandalism of public property. https://www.shouselaw.com/ca/defense/penal-code/594/ https://www.shouselaw.com/ca/defense/penal-code/594/
• endisneigh 5y ago
  Though I disagree with the research in general, if you did want to research "hypocrite commits" in an actual OSS setting, there isn't really any other way to do it other than actually introducing bugs per their proposal. That being said, I think it would've made more sense for them to have created some dummy complex project for a class and have say 80% of the class introduce "good code", 10% of the class review all code and 10% of the class introduce these "hypocrite" commits. That way you could do similar research without having to potentially break legit code in use. I say this since the crux of what they're trying to discover is: 1. In OSS anyone can commit. 2. Though people are incentivized to reject bad code, complexities of modern projects make 100% rejection of bad code unlikely, if not impossible. 3. Malicious actors can take advantage of (1) and (2) to introduce code that does both good and bad things such that an objective of theirs is met (presumably putting in a back-door).
  • sigstoat 5y ago
    > Though I disagree with the research in general, if you did want to research "hypocrite commits" in an actual OSS setting, there isn't really any other way to do it other than actually introducing bugs per their proposal. they could've done the much harder work of studying all of the incoming patches looking for bugs, and then just not reporting their findings until the kernel team accepts the patch. the kernel has a steady stream of incoming patches, and surely a number of bugs in them to work with. yeah it would've cost more, but would've also generated significant value for the kernel.
    • endisneigh 5y ago
      The point of the research isn't to study bugs, it's to study hypocrite commits. Given that a hypocrite commit requires intention, there's no other way except to submit commits yourself as the submitter would obviously know their own intention.
      • cgriswald 5y ago
        In what way does a hypocrite commit differ from a commit which unintentionally has the same effect?
• forgotpwd16 5y ago
  Not wanting to play the devil's advocate here but though scummy, they still successfully introduced vulnerabilities to the kernel. Suppose the paper hadn't been released or an adversary had done it. How long they'll be lingering around if they're ever removed? The paper makes a case that FOSS projects shouldn't merely trust authority for security (neither the ones submitting or the ones reviewing) but utilize tools to find potential vulnerabilities for every commit.
  • rrss 5y ago
    > utilize tools to find potential vulnerabilities for every commit. The paper doesn't actually have concrete suggestions for tools, just hand-waving about "use static analysis tools, better than the ones you already use" and "use fuzzers, better than those that already exist." The work was a stunt to draw attention to the problem of malicious committers. In that regard, it was perhaps successful. The authors' first recommendation is for the kernel community to increase accountability and liability for malicious committers, and GregKH is doing a fantastic job at that by holding umn.edu accountable.
  • bombcar 5y ago
    Coverity found at least one: vvv CID 1503716: Null pointer dereferences (REVERSE_INULL) vvv Null-checking "rm" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. and tools are useful, but given the resources and the know-how of those who compete in the IOCC I think we'd have to assume they'd be able to get something through. It'd have an even higher chance of success if it could be built to target a particular hardware combination (of a desired victim) as you could make the exploit dependent on multiple parts of the code (and likely nobody would ever determine the extent, as they'd find parts of it and fix them independently).
• stakkur 5y ago
  When you test in production...
• djohnston 5y ago
  Wow this "researcher" is a complete disaster. Who nurtures such a toxic attitude of entitlement and disregard for others time and resources? Not to mention the possible real world consequences of introducing bugs into this OS. He and his group need to be brought before an IRB.
  • bgorman 5y ago
    Victim mentality is being cultivated on campuses all over the US. This will not be the last incident like this.
• francoisp 5y ago
  (I posted this on another entry that dropped out of the first page of HN? sorry for the dupe) I fail to see how this does not amount to vandalism of public property. https://www.shouselaw.com/ca/defense/penal-code/594/ https://www.shouselaw.com/ca/defense/penal-code/594/
• Apofis 5y ago
  Minnesota being Minnesota.
• HelloNurse 5y ago
  They seem to be teaching social engineering. Using a young, possibly foreign student as a front is a classy touch.
  • oraged 5y ago
    The author of the patches, Aditya Pakki, is a second year PHD student as per his website https://adityapakki.github.io/about/ https://adityapakki.github.io/about/ He himself is to blame for submitting these kind of patches and claiming innocence. If a person as old as him can't figure out what's ethical and what's not, then that person deserves what comes out of actions like these.
• davidkuhta 5y ago
  I think the root of the problem can be traced back to the researcher's erroneous claim that "This was not human research".
• darksaints 5y ago
  As a side note to all of the discussion here, it would be really nice if we could find ways to take all of the incredible linux infrastructure, and repurpose it for SeL4. It is pretty scary that we've got ~30M lines of code in the kernel and the primary process we have to catch major security bugs is to rely on the experienced eyes of Greg KH or similar. They're awesome, but they're also human. It would be much better to rely on capabilities and process isolation.
• jrm4 5y ago
  Sure. And we are well past the time in which we need to develop real legal action and/or policy -- with consequences against this sort of thing. We have an established legal framework to do this. It's called "tort law," and we need to learn how to point it at people who negligently or maliciously create and or mess with software. What makes it difficult, of course, is that not only should it be pointed at jerk researchers, but anyone who works on software, provably knows the harm their actions can or do cause, and does it anyway. This describes "black hat hackers," but also quite a few "establishment" sources of software production.
• unanswered 5y ago
  Presumably the next step is an attempt to cancel the kernel maintainers on account of some politically powerful - oops, I mean, some politically protected characteristics of the researchers.
• gumby 5y ago
  This is the kind of study (unusual for CS) that requires IRB approval. I wonder if they thought to seek approval, and if they received it?
• b0rsuk 5y ago
  Think of potential downstream effects of a vulnerable patch being introduced into Linux kernel. Buggy software in mobile devices, servers, street lights... this is like someone introducing a bug into university grading system. Someone should look into who sponsored this research. Was there a state agent?
• karsinkk 5y ago
  Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >Once any maintainer of the community responds to the email,indicating “looks good”,we immediately point out the introduced bug 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 proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux. I haven't been able to find out what the 3 patches which the reference are, but the discussions on Greg's UMN Revert patch [2] does indicate that some of the fixes have indeed been merged to Stable and are actually Bogus. [1] : https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... [2] : https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...
  • notdang 5y ago
    The main issue here is that it wastes the time of the reviewers and they did not address it in their reply.
    • alanning 5y ago
      To help clarify for purposes of continuing the discussion the original research did address the issue of minimizing the time of the reviewers [1] [2]. Seems the maintainers were OK with that as no actions were taken other than an implied request to stop that kind of research. Now a different researcher from UMN, Aditya Pakki, has submitted a patch which contains bugs that seems to be attempting to do the same type of pen testing although the PhD student denied it. 1. Section IV.A of the paper, as pointed out by user MzxgckZtNqX5i in this comment: https://news.ycombinator.com/item?id=26890872 https://news.ycombinator.com/item?id=26890872 > Honoring maintainer efforts. The OSS communities are understaffed, and maintainers are mainly volunteers. We respect OSS volunteers and honor their efforts. Unfortunately, this experiment will take certain time of maintainers in reviewing the patches. To minimize the efforts, (1) we make the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we find three real minor issues (i.e., missing an error message, a memory leak, and a refcount bug), and our patches will ultimately contribute to fixing them. 2. Clarifications on the “hypocrite commit” work (FAQ) https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... "* Does this project waste certain efforts of maintainers? Unfortunately, yes. We would like to sincerely apologize to the maintainers involved in the corresponding patch review process; this work indeed wasted their precious time. We had carefully considered this issue, but could not figure out a better solution in this study. However, to minimize the wasted time, (1) we made the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we tried hard to find three real bugs, and the patches ultimately contributed to fixing them."
• knz_ 5y ago
  The bad actors here should be expelled and deported. The nationalities involved make it clear this is likely a backfired foreign intelligence operation and not just 'research'. They were almost certainly expecting an obvious bad patch to be reverted while trying to sneak by a less obvious one.
• Luker88 5y ago
  The discussion points link to the github of the research https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap... It has yet to be published (due next month) How about opening few bug reports to correctly report the final response of the community and the actual impact? Not asking to harass them: if anyone should do it, it would be the kernel devs, and I'm not one of them
• nwsm 5y ago
  I would say the research was a success. They found that when a bad actor submits malicious patches they are appropriately banned from the project.
  • slenk 5y ago
    It does seem like ultimately they played themselves by getting permanently banned from participating.
• closeparen 5y ago
  This is a community that thinks it’s gross negligence if something with a real name on it fails to be airgapped. Social shame and reputation damage may be useful defense mechanisms in general, but in a hacker culture where the right to make up arbitrarily many secret identities is a moral imperative, people who burn their identities can just get new ones. Banning or shaming is not going to work against someone with actual malicious intent.
  • calf 5y ago
    It seems to be reacting and solving the wrong problem, and won't deter actual malicious attempts.
• devpbrilius 5y ago
  Weirdly enough
• charonn0 5y ago
  It seems like this debacle has created a lot of extra work for the kernel maintainers. Perhaps they should ask the university to compensate them.
• psim1 5y ago
  UMN is still sore that http took off and gopher didn't.
• deleted 5y ago
  [deleted]
• devmunchies 5y ago
  Aditya: I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Greg: You can't quit, you're fired.
• unanswered 5y ago
  I am concerned that the kernel maintainers might be falling into another trap: it is possible that some patches were designed such that they are legitimate fixes, and moreover such that reverting them amounts to introducing a difficult-to-detect malicious bug. Maybe I'm just too cynical and paranoid though.
• GNOMES 5y ago
  Am I missing how these patches were caught/flagged? Was it an automated process or physically looking at the pull requests?
• dghlsakjg 5y ago
  Like all research institutions, University of Minnesota has an ethics committee. https://integrity.umn.edu/ethics https://integrity.umn.edu/ethics Feel free to write to them
• BTCOG 5y ago
  Now I'm not one for cancel culture, but fuck these guys. Put their fuckin' names out there to get blackballed. Bunch of clowns.
• shiyoon 5y ago
  https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... Seemed to have posted some clarifications around this. worth a read
• shiyoon 5y ago
  https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... posted some clarifications around this, worth a read
• atleta 5y ago
  It's already being discussed on HN [1] but for some reason it's down to the 3rd page despite having ~1200 upvotes at the moment and ~600 comments, including from Greg KH. (And the submission is only 5 hours old.) [1] https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670
  • bitcharmer 5y ago
    This is another example of HN's front page submission getting aggressively moderated for no good reason. It's been happening a lot lately.
    • dang 5y ago
      Perhaps you've been seeing it more for some reason, or it has seemed more aggressive to you for some reason, but I can tell you that the way we moderate HN's front page hasn't changed in many years. It's clear to me now that this case was a moderation mistake. We make them sometimes (alas), but that's also been true for many years. Moderation is guesswork. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20guesswork&sort=byDate&type=story&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
      • jdsully 5y ago
        It would be nice to have transparency on mod actions like we have with user actions (aka showdead). People are rightfully more nervous as other platforms are switching to heavy handed moderation.
  • dang 5y ago
    Sorry, we got that wrong. Fixed now. Edit: turns out it was just that there were two different threads on the frontpage about this story and a moderator downweighted the earlier one. That's standard moderation. Usually we merge the threads (and I've since done so) but I'm the only mod who currently does that and I wasn't online yet.
    • 5y ago
• qwertox 5y ago
  How is this any different to littering in order to research if it gets cleaned up properly? Or like dumping hard objects onto a highway to research if they cause harm before authorities notice it? I mean, the Kernel is now starting to run in cars and even on Mars, and getting those bugs into stable is definitely no achievement one should be proud of.
• tiziniano 5y ago
  Unsurprising given the current open sores model of software
• MR4D 5y ago
  Looks like vandalism masquerading as “research”. Greg’s response is totally right.
• atleta 5y ago
  Now one of the problems with research in general is that negative results don't get published. While in this case it probably resolved itself automatically, if they have any ethical standards then they'll write a paper about how it ended. Something like "our assumption was that it's relatively easy to deliberately sneak in bugs into the Linux kernel but it turns out we were wrong. We managed to get our whole university banned and all former patches from all contributors from our university, including from those outside of your our research team, reversed." Also, while their assumption is interesting, there sure had to be an ethical and safe way to conduct this. Especially without allowing their bugs to slip into release.
• eatbitseveryday 5y ago
  Clarification from their work that was posted on the professor's website: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
• shadowgovt 5y ago
  Is banning an entire university's domain from submitting to a project due to the actions of a few of its members an example of cancel culture?
  • Minor49er 5y ago
    If the university itself is actively promoting unethical behavior, then no, it isn't "cancel culture". That term is reserved for people or groups who hold unpopular opinions, and this is not that.
• kevinventullo 5y ago
  Here’s a (perhaps naively) optimistic take: by publishing this research and showing it to lawmakers and industry leaders, it will sound alarms on a serious vulnerability in what is critical infrastructure for much of the tech industry and public sector. This could then lead to investment in mitigations for the vulnerability, e.g. directly funding work to proactively improve security issues in the kernel.
• icedchai 5y ago
  Seems like completely pointless "research." Clearly it wasted the maintainers' time, but also the "researchers" investigating something that is so obviously possible. Weren't there any real projects to work on?
• deleted 5y ago
  [deleted]
• PHDchump 5y ago
  lol this is also how Russia does their research with Solarwinds. Do not try to attack supply chain or do security research without permission. They should be investigated by FBI for doing recon to a supply chain to make sure they weren't trying to do something worse. Minnesota leads the way in USA embarrassment once again.
• rurban 5y ago
  I'd really like to review now similar patches in FreeRTOS, FreeBSD and such. Their messages and fixes all follow a certain scheme, which should be easy to detect. At least both of them they are free from such @umn.edu commits with fantasy names.
• kwdc 5y ago
  It would be fascinating to see the ethics committee exemption. I sense there was none. Or is this kind of experiment deemed fair game? Red vs blue team kind of thing? Penetration testing. But if it was me in this situation, I'd ban them for ethics violation as well. Acting like a Evil doer means you might get caught... and punished. I found the email about cease and desist particularly bad behavior. If that student was lying then that university will have to take real action. Reputation damage and all that. Surely a academic reprimand. I'm sure there's plenty of drama and context we don't know about.
  • kwdc 5y ago
    I didn't read this bit: "The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter" Um. Ok.
    • steelframe 5y ago
      Some people are questioning whether banning the entire university is an appropriate response. It sounds to me like there are systemic institutional issues that they need to address, and perhaps banning them until they can sort those out wouldn't be an entirely unreasonable thing to do.
      • kwdc 5y ago
        I think banning them for now is appropriate. Its a shot across their bow to let them know they have done something wrong. Moving forward if it was me I'd later re-evaluate such a wide ban because of the collateral damage. But at the same time, there needs to be redress for wrongdoing since they were actually caught. I'd definitely not re-evaluate until apology and some kind of "we won't waste time like this again" agreement or at least agreed-upon understanding is in place. Whatever shape that needs to be. As for systematic issues, I'm not sure. But moving forward they'd want to confirm there aren't glaring omissions to let this happen again. Giving them suitable Benefit-of-doubt niceties might imply these are isolated cases. (But both of them?! Perhaps isolated to a small group of academics.) Messy situation.
• matheusmoreira 5y ago
  It's okay to run experiments on humans without their explicit informed consent now?
• ineedasername 5y ago
  I don't know how their IRB approved this, although we also don't know what details the researchers gave the IRB. It had a high human component because it was humans making many decisions in this process. In particular, there was the potential to cause maintainers personal embarrassment or professional censure by letting through a bugged patch. If the researchers even considered this possibility, I doubt the IRB would have approved this experimental protocol if laid out in those terms.
• freewizard 5y ago
  Using faked identity and faked papers to expose loopholes and issues in an institution is not news in science community. Kernel community may not be immune to some common challenges for any sizable institution I assume, so some ethical hacking here seems reasonable. However, doing it repeatedly with real names seems not helpful to the community and indicates a questionable motivation.
• deleted 5y ago
  [deleted]
• aisio 5y ago
  One reviewers comments to a patch of theirs from 2 weeks ago "Plainly put, the patch demonstrates either complete lack of understanding or somebody not acting in good faith. If it's the latter[1], may I suggest the esteemed sociologists to fuck off and stop testing the reviewers with deliberately spewed excrements?" https://lore.kernel.org/lkml/YH4Aa1zFAWkITsNK@zeniv-ca.linux.org.uk/ https://lore.kernel.org/lkml/YH4Aa1zFAWkITsNK@zeniv-ca.linux...
  • bombcar 5y ago
    Interesting - follow that thread and you find https://lore.kernel.org/linux-next/202104081640.1A09A99900@keescook/ https://lore.kernel.org/linux-next/202104081640.1A09A99900@k... where coverity-bot says "this is bullshit": vvv CID 1503716: Null pointer dereferences (REVERSE_INULL) vvv Null-checking "rm" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
    • slenk 5y ago
      It also says if this is a false positive to let the "experimental semi-automated" bot know...
• protomyth 5y ago
  FYI The IRB for University of Minnesota https://research.umn.edu/units/irb https://research.umn.edu/units/irb has a Human Research Protection Program https://research.umn.edu/units/hrpp https://research.umn.edu/units/hrpp where I cannot find anything on research on people without their permission. There is a Participant's Bill of Rights https://research.umn.edu/units/hrpp/research-participants/participant-bill-rights https://research.umn.edu/units/hrpp/research-participants/pa... that would seem to indicate uninformed research is not allowed. I would be curious how doing research on the reactions of people to test stimulus in a non-controlled environment is not human research.
• rurban 5y ago
  This is the big revert, a good overview of all the damage they did. Some were good, most were malicious, most author names were fantasy. https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...
• dawnbreez 5y ago
  logged into my ancient hn account just to tell all of you that pentesting without permission from higher-ups is a bad idea yes, this is pentesting
• kml 5y ago
  Aditya Pakki should be banned from any open source projects. Open source depends on contributors who collectively try to do the right thing. People who purposely try to veer projects off course should face real consequences.
• soheil 5y ago
  First thing that comes to mind is The Underhanded C Contest [0] where contestants try to introduce code that looks harmless, but actually is malicious and even if caught should look like an innocent bug at worse. [0] http://www.underhanded-c.org http://www.underhanded-c.org
• wglb 5y ago
  While it is easy to consider this a unsportsmanlike, one might view this as a supply chain attack. I don't particularly support this approach, but consider for a moment that as a defender (in the security team sense), you need to be aware of all possible modes of attack and compromise. While the motives of this class are clear, ascribing to attackers any particular motive is likely to miss. To the supply chain type of attacks, there isn't an easy answer. Classical methods left both the SolarWinds and Codecov attacks in place for way too many days.
• fellellor 5y ago
  What an effing idiot! And then turn around and claiming bullying! At this point I’m not even surprised. Claiming victimhood is now a very effective move in the US academia these days.
• tediousdemise 5y ago
  This not only erodes trust in the University of Minnesota, but also erodes trust in the Linux kernel. Imagine how downstream consumers of the kernel could be affected. The kernel is used for some extremely serious applications, in environments where updates are nonexistent. These bad patches could remain permanently in situ for mission-critical applications. The University of Minnesota should be held liable for any damages or loss of life incurred by their reckless decision making.
• omar12 5y ago
  This raises the question: "has there been state-sponsored efforts to overwhelm open source maintainers with the intent of sneaking in vulnerabilities to software applications?"
• dynm 5y ago
  I'd be interested if there's a more ethical way to do this kind of research, that wouldn't involve actually shipping bugs to users. There certainly is some value in kind of "penetration testing" things to see how well bad actors could get away with this kind of stuff. We basically have to assume that more sophisticated actors are doing this without detection...
• mycologos 5y ago
  I agree with most commenters here that this crosses the line of ethical research, and I agree that the IRB dropped the ball on this. However, zooming out a little, I think it's kind of useful to look at this as an example of the incentives at play for a regulatory bureaucracy. Comments bemoaning such bureaucracies are pretty common on HN (myself included!), with specific examples ranging from the huge timescale of public works construction in American cities to the FDA's slow approval of COVID vaccines. A common request is: can't these regulators be a little less conservative? Well, this story is an example of why said regulators might avoid that -- one mistake here, and there are multiple people in this thread promising to email the UMN IRB and give them a piece of their mind. One mistake! And when one mistake gets punished with public opprobrium, it seems very rational to become conservative and reject anything close to borderline to avoid another mistake. And then we end up with the cautious bureaucracies that we like to complain about. Now, in a nicer world, maybe those emails complaining to the IRB would be considered valid feedback for the people working there, but unfortunately it seems plausible that it's the kind of job where the only good feedback is no feedback.
• anarticle 5y ago
  Ah yes, showing those highly paid linux kernel developers how broken their system of trust and connection is! Great work. Now if we can only find more open source developers to punish for trusting contributors! Enjoy your ban. Sorry if this comment seems off base, this research feels like a low blow to people trying to do good for a largely thankless job. I would say they are violating some ideas of Ken Thompson: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
• LudwigNagasena 5y ago
  I am honestly surprised anything like this can pass the ethic committee. The reputational risk seems huge. For example, in economics departments there is usually a ban on lying to experiment participants. Many of them even explicitly explain to participants that this is a difference between economics and psychology experiments. The reason is that studying preferences is very important to economists, and if participants don’t believe that the experiment conditions are reliable, it will screw the research.
• bloat 5y ago
  It's been a long time since I saw this usage of the word "plonk". Brought back some memories. https://en.wikipedia.org/wiki/Plonk_(Usenet) https://en.wikipedia.org/wiki/Plonk_(Usenet)
• dboreham 5y ago
  The replies here have been fascinating to read. Yes it's bad that subterfuge was engaged in vs kernel devs. But don't the many comments here expressing outrage at the actions of these researchers sound exactly like the kind of outrage commonly expressed by those in power when their misdeeds are exposed? e.g. Republican politicians outraged at a "leaker" who has leaked details of their illegal activity. It honestly looks to me like the tables have been turned here. Surely the fact that the commonly touted security advantages of OSS have been shown to be potentially fictitious, is at least as worrying as the researchers' ethics breaches?
  • not2b 5y ago
    One very good security practice is that if you find that you have a malicious contributor, you fire that contributor. The "misdeeds" were committed by the UMN researchers, not by the Linux maintainers.
  • mratsim 5y ago
    Vulnerabilities in OSS are fixed over time. They are fixed by people running the code and contributing back, by fuzzing efforts, by testing a release candidate. The difference between OSS and closed source is not the number of reviewers for the initial commit, it's the number of reviewers over years of usage.
• ajarmst 5y ago
  I used to sit on a research ethics board. This absolutely would not have passed such a review. Not a 'revise and resubmit' but a hard pass accompanied with 'what the eff were you thinking?. And, yes, this should have had a REB review: testing the vulnerabilities of a system that includes people is experimenting on human subjects. Doing so without their knowledge absolutely requires a strict human subject review and these "studies" would not pass the first sniff test. I don't think it's even legal in most jurisdictions.
  • neatze 5y ago
    This is my understanding as well, but then, how such paper was accepted by IEEE ?
    • ajarmst 5y ago
      Not sure. I expect that editors at such journals tend to assume that studies with an institutional sponsor will be held to professional standards by the sponsor, or take the authors' assertions at face value. I suspect that reviewers might have assumed that the study was done with the knowledge and permission of GNU project managers, even if not the line programmers (as in the case of ethical pen testing). That would make it less of an obvious ethical breach.
• FrameworkFred 5y ago
  This feels like the kind of thing that "white hat" hackers have been doing forever. UMN may have introduced useful knowledge into the world in the same way some random hacker is potentially "helping" a company by pointing out that they've left a security hole exposed in their system. With that said, kernel developers and companies with servers on the internet are busy doing work that's important to them. This sort of thing is always an unwelcome distraction. And, if my neighbors walks in my door at 3 a.m. to let me know I left it unlocked, I'm going to treat them the same way UMN is getting treated in this situation. Or worse.
  • mort96 5y ago
    Your analogy doesn't work. A true "white hat" hacker would hack a system to expose a security vulnerability, then immediately inform the owners of the system, all without using their unintended system access for anything malicious. In this case, the "researchers" submitted bogus patches, got them accepted and merged, then said nothing, and pushed back against accusations that they've been malicious, all for personal gain. EDIT: Also, even if you do no harm and immediately inform your victim, this sort of stuff might rather be categorized as grey-hat. Maybe a "true" white-hat would only hack a system with explicit consent from the owner. These terms are fuzzy. But my point is, attacking a system for personal gain without notifying your victim afterwards and leaving behind malicious code is certainly not white-hat by any definition.
    • qw3rty01 5y ago
      That's gray-hat, a white-hat wouldn't have touched the system without permission from the owners in the first place.
      • mort96 5y ago
        Haha, I just realized that and added an edit right as you commented.
    • FrameworkFred 5y ago
      You make a fair point. I'm just saying that, while it might ultimately be interesting and useful to someone or even lots of someones, it remains a crappy thing to do and the consequences that UMN is facing as a result is predictable and makes perfect sense to me, a guy who has had to rebuild a few servers and databases over the years because of intrusions and a couple of those have come with messages about how we should consult with the intruder who had less-than-helpfully found some security issue for us.
• balozi 5y ago
  Uff da! I really do hope the administrators at University of Minnesota truly understand the gravity of this F* up. I doubt they will though.
• ddingus 5y ago
  plonk Aaaaand into the kill file they go. Been a while since I last saw a proper plonk.
  • burnished 5y ago
    Can you link to any others? Personal curiosity.
    • ddingus 5y ago
      USENET is filled with them. People would reach a point where further conversation makes no sense. So, one would make a kill file entry, and plonk basically communicated that smack the carriage return, enter key with gratifying authority to the user who had earned their place in the kill file, not to be heard from again. The conversation is over, sort of like a block works today. Edit: See in the definition I linked where plonk is the sound of some poor soul hitting the bottom of a kill file? I think that is debatable, depending on perspective. The peeps who mentored me onto the net at the beginning explained it as that gratifying press of the CR/LF [ENTER] key. The sentiment is the same though. --- plonk /excl.,vt./ [Usenet: possibly influenced by British slang `plonk' for cheap booze, or `plonker' for someone behaving stupidly (latter is lit. equivalent to Yiddish `schmuck')] The sound a newbie makes as he falls to the bottom of a kill file. While it originated in the newsgroup talk.bizarre, this term (usually written "plonk") is now (1994) widespread on Usenet as a form of public ridicule. ---- This particular plonk is proper, not just as an insult, which is the general use case, because the person who earned the "plonking" did so in spectacularly stupid fashion, in the opinion of the "plonker." Total classic! On some older TTY's, the two asterisks denoted bold text too, here HN uses it for italics. Plain text would show the asterisks as the linked exchange showed to us.
• dumbDev 5y ago
  What is this? A "science" way of saying it's a prank bro?
• deleted 5y ago
  [deleted]
• kemonocode 5y ago
  I have to question the true motivations behind this. Just a "mere" research paper? Or is it there an ulterior motive, such as undermining Linux kernel development, taking advantage of the perceived hostility of the LKML to make a big show of it; castigate and denounce those elitist Linux kernel devs? So I hear tinfoil is on sale, mayhaps I should stock up.
• philsnow 5y ago
  This seems like wanton endangerment. Kernels get baked into medical devices and never, ever updated. I would be livid if I found that code from these "researchers" was running in a medical device that a family member relied upon.
• jcun4128 5y ago
  huh I never knew of plonk I bet I've been plonked before
• mnouquet 5y ago
  In other news: the three little pigs ban wolves after wolves exposed the dubious engineering of the straw house by blowing on it for a research paper.
  • burnished 5y ago
    So if an identifiable group messes with a project, but says "its for research!", then its OK? I'm just confused by your comment because it seems like you are upset with the maintainers for protecting their time from sources of known bad patches. And just... why? Where does the entitlement come from?
    • mnouquet 5y ago
      Being a maintainer is being a gate-keeper, by definition. Don't get me started about their "time", most of these guys are paid to work on the linux kernel, eg. Greg Kroah-Hartman is paid by the Linux Foundation. it's literally his job. Linus has balls, I'm afraid Greg KH is a Karen compared to him. Other than that, they got caught red-handed accepting shit patch and complain about ethical issues when the fault is entirely on their side for not doing their job properly. This whole thing points to a single question: how many times did they accept patch from black hat individuals who did not disclose their intention ? This question the Linux development security model and highlight it being insecure to such social engineering attacks and they still manage to play victims. That's pitiful... Own it, say you fucked up accepting the patch, don't blame other for your own incompetence.
      • burnished 5y ago
        There is zero blaming happening and I defy you to point to an example. But if some one you encounter is consistently playing tricks on you, why associate with them?
        • mnouquet 5y ago
          > But if some one you encounter is consistently playing tricks on you, why associate with them? Do you mean that when a small minority commit an abuse (edit: questionable here), the whole group should be condemned ? Me-think HN is as hypocrite as can be on this subject...
• 1970-01-01 5y ago
  So be it. Greg is a very trusted member, and has overwhelming support from the community for swinging the banhammer. We have a living kernel to maintain. Minnesota is free to fork the kernel, build their own, recreate the patch process, and send suggestions from there.
• ilamont 5y ago
  Reminded me of story more than a decade ago about an academic who conducted a series of "breaching experiments" in City of Heroes/City of Villains to study group behavior, basically breaking the social rules (but not the game rules) without other participants' or the game studio's knowledge. It was discussed on HN in 2009 (https://news.ycombinator.com/item?id=690551 https://news.ycombinator.com/item?id=690551) Here's how the professor (a sociologist) described his methodology: These three sets of behaviors – rigidly competitive pvp tactics (e. g., droning), steadfastly uncooperative social play outside the game context (e. g., refusing to cooperate with zone farmers), and steadfastly uncooperative social play within the game context (e. g., playing solo and refusing team invitations) – marked Twixt’s play from the play of all others within RV. Translation: He killed other players in situations that were allowed by the game's creators but frowned upon by the majority of real-life participants. For instance, "villains" and "heroes" aren't supposed to fraternize, but they do anyway. When "Twixt" happened upon these and other situations -- such as players building points by taking on easy missions against computer-generated enemies -- he would ruin them, often by "teleporting" players into unwinnable killzones. The other players would either die or have their social relations disrupted. Further, "Twixt" would rub it in by posting messages like: Yay, heroes. Go good team. Vills lose again. The reaction to the experiment and to the paper was what you would expect. The author later said it wasn't an experiment in the academic sense, claiming: ... this study is not really an experiment. I label it as a “breaching experiment” in reference to analogous methods of Garfinkel, but, in fact, neither his nor my methods are experimental in any truly scientific sense. This should be obvious in that experimental methods require some sort of control group and there was none in this case. Likewise, experimental methods are characterized by the manipulation of a treatment variable and, likewise, there was none in this case. Links: http://www.nola.com/news/index.ssf/2009/07/loyola_university_professor_be.html http://www.nola.com/news/index.ssf/2009/07/loyola_university... https://www.ilamont.com/2009/07/academic-gets-rise-from-breaching.html https://www.ilamont.com/2009/07/academic-gets-rise-from-brea...
• znpy 5y ago
  I think it's a fair measure, albeit drastic. What happens if any of that patches ends up in a kernel release? It's like setting random houses on fire just to test the responsiveness of local firefighters.
  • x86ARMsRace 5y ago
    More like replacing random locks with junk in banks and seeing how long until they're discovered.
• AshamedCaptain 5y ago
  Researcher sends bogus papers to journal/conference, gets them reviewed and approved, uses that to point how ridiculous the review process of the journal is => GREAT JOB, PEER REVIEW SUCKS! Researcher sends bogus patches to bazaar-style project, gets them reviewed and approved, uses that to point how ridiculous the review process of the project is => DON'T DO THAT! BAD RESEARCHER, BAD!
  • snazz 5y ago
    One potentially misleads readers of the journal, the other introduces security vulnerabilities into the world’s most popular operating system kernel.
    • AshamedCaptain 5y ago
      "Misleading readers of a journal" might actually cause more damages to all of humanity (see https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt https://en.wikipedia.org/wiki/Growth_in_a_Time_of_Debt) than inserting a security vulnerability (that is likely not even exploitable) in a driver that no one actually enables (which is likely why no one cares about reviewing patches to it, either). Thought to be fair, it is also the case that only the most irrelevant journals are likely to accept the most bogus papers. But in both cases I see no reason not to point it out. The two situations are much more closer than what you think. The only difference I see is in the level of bogusness.
  • Rantenki 5y ago
    OK? If somebody else does something ethically dubious, does that make all ethically dubious behaviours acceptable somehow? How does a totally separate instance of ethical misconduct impact this situation?
• Klwohu 5y ago
  Whoa this is some heavy DC, a Chinese spy got busted trying to poison the Linux kernel. And then he came up with an excuse.
  • jlduan 5y ago
    just because they chose to use Chinese names, doesnt make them less American. Are you suggesting non-Chinese Americans cant be spies?
    • Klwohu 5y ago
      Are you saying, in this particular case, that the Chinese researcher is an American citizen? That's a very bold claim. Source?
      • burnished 5y ago
        > a Chinese spy got busted trying to poison the Linux kernel this you?
        • Klwohu 5y ago
          Are you going to pretend that Chinese penetration of academia isn't real? There've been some recent high level prosecutions which prove it's a big problem.
      • jlduan 5y ago
        so, just based on the names (are not Amercian to you), you are assuming they are not?
  • dang 5y ago
    What evidence do you have that this is a spy? If you have evidence, you need to say what is in order to make a substantive post. If you have no evidence, then this comment is a smear and breaks the site guidelines badly. In that case please read https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules. Edit: you've posted this sort of flamebait at least once before: https://news.ycombinator.com/item?id=26643049 https://news.ycombinator.com/item?id=26643049. This will get you banned here—we don't want this site to become nationalistic flamewar hell. No more of this please.
• dumpsterdiver 5y ago
  Could someone clarify: this made it to the stable branch, so does that mean that it made it out into the wild? Is there action required here?
• largehotcoffee 5y ago
  This was absolutely the right move. Smells really fishy given the history. I imagine this is happening in other parts of the community (attempting to add malicious code), albeit under a different context.
• thayne 5y ago
  After they successfully got buggy patches in, did they submit patches to fix the bugs? And were they careful to make sure their buggy patches didn't make it into stable releases? If not, then they risked causing real damage, and is at least toeing the line of being genuinely malicious.
• honeybutt 5y ago
  Very unethical and extremely inconsiderate of the maintainers time to say the least.
• redmattred 5y ago
  I thought there were ethical standards for research where a good study should not knowingly do harm or at the very least make those involved aware of their participation
• CountSessine 5y ago
  I have to wonder what's going to happen to the advisor who oversaw this research. This knee-caps the whole department when conducting OS research and collaboration. If this isn't considered a big deal in the department, it should be. I certainly wouldn't pursue a graduate degree there in OS research now.
• johncessna 5y ago
  As a user of linux, I want to see this ban go further. Nothing from the University of MN, it's teaching staff, or it's current or past post-grad students. Once they clean out the garbage in the Comp Sci department and their research committee that approved this experiment, we can talk.
• limaoscarjuliet 5y ago
  To me it was akin to spotting volunteers cleaning up streets and, right after they passed, dumping more trash on the same street to see if they come and clean it up again. Low blow if you ask me.
• williesleg 5y ago
  Fucking Chiners
• deleted 5y ago
  [deleted]
• jtdev 5y ago
  University of Minnesota is involved with the Confucius Institute... what could go wrong when a U.S. university accepts significant funding from a hostile foreign power? https://experts.umn.edu/en/organisations/confucius-institute https://experts.umn.edu/en/organisations/confucius-institute
• hzzhang 5y ago
  This type of research just looks like: let’s prove people will die if being killed, by really killing someone.
• wolverine876 5y ago
  I don't see the difference between these and other 'hackers', white-hat, black-hat etc. The difference I see is the institution tested, Linux, is beloved here. Usually people are admired here for finding vulnerabilities in all sorts of systems and processes. For example, when someone submits a false paper to a peer-reviewed journal, people around here root for them; I don't see complaints about wasting the time and violating the trust of the journal. But should one of our beloved institutions be tested - now it's an outrage?
  • ahepp 5y ago
    The outrage and does seem out of place to me. I think it's fair (even reasonable) for the kernel maintainers to ban those responsible, but I'm not sure why everyone here is getting so offended about fairly abstract harms like "wasting the time of the maintainers"
  • shultays 5y ago
    I don't think what has been done here is comparable to other forms of "finding vulnerabilities". Linux and everyone else would be happy if people find vulnerabilities in their code and report them back. And it is not like linux team is unaware of this "vulnerability" This is more comparable to DDOS ing a web server to test their capabilities of handling DDOS. And they are aware of the issue. And they told you to not do it when you did it before. You just don't waste other people's time/money like that unless they give you the permission.
• ArcturianDeath 5y ago
  See also, https://boards.4chan.org/pol/thread/317988167 https://boards.4chan.org/pol/thread/317988167
• ogre_codes 5y ago
  If the university was doing research then they should publish their findings on this most recent follow up experiment. Suggested title: “Linux Kernel developers found to reject nonsense patches from known bad actors”
• mikaeluman 5y ago
  Usually I am very skeptical of "soft" subjects like the humanities; but clearly this is unethical research. In addition to wasting people's time, you are potentially messing with software that runs the world.
  • NationalPark 5y ago
    Considering how often you post about free speech and censorship, maybe you would find some interesting perspectives within the humanities.
• leeuw01 5y ago
  In a follow-up [1], the author suggests: OSS projects would be suggested to update the code of conduct, something like “By submitting the patch, I agree to not intend to introduce bugs” How can one be so short-sighted?... [1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
• g42gregory 5y ago
  Reading this email exchange, I worry about the state of our education system, including computer science departments. Instead of making coherent arguments, this PhD student speaks about "preconceived biases". I loved Greg's response. The spirit of Linus lives within the Kernel! These UMN people should be nowhere near the kernel. I guess they got the answer to their research on what would happen if you keep submitting stealth malicious patches to the kernel: you will get found out and banned. Made my day.
  • Igelau 5y ago
    The tone of Pakki's reply made me cringe: > Attitude that is not only unwelcome but also intimidating to newbies and non experts Between that and the "Clarifications" document suggesting they handle it by updating their Code of Conduct, they're clearly trying really hard to frame all of this as some kind of toxic culture in kernel development. That's a hideous defense. It's like a bad MMA fight where one fighter refuses to stand up because he insists on keeping it a ground fight. Maybe it works sometimes, but it's shameful.
• kerng 5y ago
  What I dont get... why not ask the board of the Linux foundation if they could attempt social engineering attacks and get authorization. If Linux foundation sees value they'd approve it and who knows maybe such tests (hiring pentesters to do social engineering) are done anyway by the Linux foundation.
• kerng 5y ago
  Where does such "research" end... sending phishing mails to all US citizens to see how many passwords can be stolen?
• hn3147 5y ago
  This would have been way more fun if they had a Black trans Womxn submit the bogus patches. The blowback to the White maintainer’s reply would have been hilarious * popcorn *
• dang 5y ago
  This thread is paginated, so to see the rest of the comments you need to click More at the bottom of the page, or like this: https://news.ycombinator.com/item?id=26887670&p=2 https://news.ycombinator.com/item?id=26887670&p=2 https://news.ycombinator.com/item?id=26887670&p=3 https://news.ycombinator.com/item?id=26887670&p=3 https://news.ycombinator.com/item?id=26887670&p=4 https://news.ycombinator.com/item?id=26887670&p=4 https://news.ycombinator.com/item?id=26887670&p=5 https://news.ycombinator.com/item?id=26887670&p=5 https://news.ycombinator.com/item?id=26887670&p=6 https://news.ycombinator.com/item?id=26887670&p=6 https://news.ycombinator.com/item?id=26887670&p=7 https://news.ycombinator.com/item?id=26887670&p=7 (Posts like this will go away once we turn off pagination. It's a workaround for performance, which we're working on fixing.) Also, https://www.neowin.net/news/linux-bans-university-of-minnesota-for-sending-buggy-patches-in-the-name-of-research/ https://www.neowin.net/news/linux-bans-university-of-minneso... gives a bit of an overview. (It was posted at https://news.ycombinator.com/item?id=26889677 https://news.ycombinator.com/item?id=26889677, but we've merged that thread hither.) Edit: related ongoing thread: UMN CS&E Statement on Linux Kernel Research - https://news.ycombinator.com/item?id=26895510 https://news.ycombinator.com/item?id=26895510 - April 2021 (205 comments and counting)
• davidkuhta 5y ago
  Anyone else find the claim that "This was not human research" as erroneous as I do?
• nickysielicki 5y ago
  UMN has some egg on their face, surely, but I think the IEEE should be equally embarrassed that they accepted this paper.
• pushcx 5y ago
  CS researchers at the University of Chicago did a similar experiment on me and other maintainers a couple years ago: https://github.com/lobsters/lobsters/issues/517 https://github.com/lobsters/lobsters/issues/517 And similarly to U Minn, their IRB covered for them: https://lobste.rs/s/3qgyzp/they_introduce_kernel_bugs_on_purpose#c_bxb4rk https://lobste.rs/s/3qgyzp/they_introduce_kernel_bugs_on_pur... My experience felt really shitty, and I'm sorry to see I'm not alone. If anyone is organizing a broad response to redress previous abuses or prevent future abuse, I'd appreciate hearing about it, my email's on my profile.
• slaw_pr 5y ago
  It seems we hit another level of "progressive" stupidity and that has to be the most "woke" IT univ if they allow such BS to happen. Of course they deserve the ban. To be that stupid, self-centered and despise someone else's work to this extent, then play a victim - you need to be brainwashed by some university professor. Not to mention they confuse being friendly to beginners with tolerance for brainless parasites. They exploited authority of educational institution and everyone SANE who is studying there to intentionally break someone's else work for their own profit. Not sure what's severity of this attack but if these "patches" got into critical parts of kernel like NFS they should not only be expelled but prosecuted. Becase what's next? Another bunch of MORONS will launch attacks on medical equipement to see if they're able to kill someone and then cry if they fail?
  • otde 5y ago
    This seems like a stretch. While the main culprit is couching their accusations of slander in accessibility-oriented language as a way to deflect, there’s little to suggest “wokeness” is at play here in any respect, and to imply otherwise kind of gives away that you’ve already settled on a “culture war” lens, regardless of how well that maps to the story’s context.
    • the_only_law 5y ago
      Five hour old account posting flamebait, guess this is what HN is becoming.
• DonHopkins 5y ago
  Shouldn't the university researchers compensate their human guinea pigs with some nice lettuce?
• squarefoot 5y ago
  "Yesterday, I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes"." Sorry for being the paranoid one here, but reading this raises a lot of warning flags.
• djhaskin987 5y ago
  Interesting tidbit from the prof's CV where he lists the paper, interpret from it what you will[1]: > On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits > Qiushi Wu, and Kangjie Lu. > To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. > Note: The experiment did not introduce any bug or bug-introducing commit into OSS. It demonstrated weaknesses in the patching process in a safe way. No user was affected, and IRB exempt was issued. The experiment actually fixed three real bugs. Please see the clarifications[2]. 1: https://www-users.cs.umn.edu/~kjlu/ https://www-users.cs.umn.edu/~kjlu/ 2: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....
• grae_QED 5y ago
  This is insulting. The whole premise behind the paper is that open source developers aren't able to parse comits for malicious code. From a security standpoint, sure, I'm sure a bad actor could attempt to do this. But the fact that he tried this on the linux kernel, an almost sacred piece of software IMO, and expected it to work takes me aback. This guy either has a huge ego or knows very little about those devs.
• libpcap 5y ago
  Their action needs to be reported to the FBI.
• whack 5y ago
  Let me play devil's advocate here. Such pen-testing is absolutely essential to the safety of our tech ecosystem. Countries like Russia, China and USA are without a doubt, doing exactly the same thing that this UMN professor is doing. Except that instead of writing a paper about it, they are going to abuse the vulnerabilities for their own nefarious purposes. Conducting such pen-tests, and then publishing the results openly, helps raise awareness about the need to assume-bad-faith in all OSS contributions. If some random grad student was able to successfully inject 4 vulnerabilities before finally getting caught, I shudder to think how many vulnerabilities were successfully injected, and hidden, by various nation-states. In order to better protect ourselves from cyberwarfare, we need to be far more vigilant in maintaining OSS. Ideally, such research projects should gain prior approval from the project maintainers. But even though they didn't, this paper is still a net-positive contribution to society, by highlighting the need to take security more seriously when accepting OSS patches.
  • MeinBlutIstBlau 5y ago
    Then do it through pen testing companies. Not official channels masquerading as research.
  • dm319 5y ago
    The world works better without everyone being untrusting of everyone else, and this is especially true of large collaborative projects. The same goes in science - it has been shown over and over again that if researchers submit deliberately fraudulent work, it is unlikely to be picked up by peer review. Instead, it is simply deemed as fraud, and researchers that do that face heavy consequences, including jail time. Without trust, these projects will fail. Research has shown that even in the presence of untrustworthy actors, trusting is usually still beneficial [1][2]. Instead, trust until you have reason to believe you shouldn't has been found to be an optimal strategy [2], so G K-H is responding exactly appropriately here. The linux community trusted them until they didn't, and now they are unlikely to trust them going forward. [1] https://www.nature.com/articles/s41598-019-55384-4#Sec13 https://www.nature.com/articles/s41598-019-55384-4#Sec13 [2] https://medium.com/greater-than-experience-design/game-theory-and-the-evolution-of-trust-6da95b33407a https://medium.com/greater-than-experience-design/game-theor...
• gjvc 5y ago
  see also https://twitter.com/UMNComputerSci/status/1384948683821694976 https://twitter.com/UMNComputerSci/status/138494868382169497...
• jvanderbot 5y ago
  The most recent possible-double-free was from a bad static analyzer wasn't it? That could have been a good-faith commit, which is unfortunate given the deliberate bad-faith commits prior.
• freewilly1040 5y ago
  Is there some tool that provides a nicer view of these types of threads? I find them hard to navigate and read.
• francoisp 5y ago
  those that can't do teach, and those that can't teach troll open source devs?
• alkonaut 5y ago
  If you really wanted to research how to get malicious code into the highest-profile projects like Linux, the social engineering bit would be the most Whether some unknown contributor can submit a bad patch isn't so interesting for this type of project. Knowing the payouts for exploits, the question is: how much money would one bad reviewer want to let one past?
• Fordec 5y ago
  In Ireland there was a referendum to repeal the ban on abortion referendum there was very heated arguments, bot twitter accounts and general toxicity. For the sake of peoples sanity, there was a "Repeal Shield" implemented that blocked bad faith actors. This news makes me wish to implement my own block on the same contributors to any open source I'm involved with. At the end of the day, their ethics is their ethics. Those ethics are not Linux specific, it was just the high profile target in this instance. I would totally subscribe to or link to a group sourced file similar to a README.md or CONTRIBUTORS.md (CODERS_NON_GRATA.md?) that pulled such things.
  • dm319 5y ago
    I think that is a sensible way to deal with this problem. The linux community is based on trust (as are a lot of other very successful communities), and ideally we trust until we have reason not to. But at that point we do need to record who we don't trust. It is the same in academia and sports.
    • Fordec 5y ago
      The tech community, especially in sub-niches is far smaller than people think it is. It's easy to feel like it's a sea of tech to some when it's all behind a screen. But reputation is a powerful thing in both directions. There is also a more nuclear option which I'm specifically not advocating for quite yet here but I will note none the less; We're starting to see in discourse regarding companies co-opting open source projects for their own profit (cough Amazon) and how license agreements limit them more than regular contributors. That has come about, at the core of it, also because of a demonstrated trend of bad faith but also combined with a larger surface area contact with society. I could foresee a potential future trend where individuals who also act in bad faith are excluded from use of open source projects through their licenses. Imagine if the license for some core infrastructure tech like a networking library or the Linux kernel banned "Joe Blackhat" from using python for professional use. Now he still could, but in reputable companies, particularly larger ones with a legal department that person would be more of a liability than they are worth. There can be potentially huge professional consequences of a type that do not currently exist really in the industry.
• deleted 5y ago
  [deleted]
• sadfev 5y ago
  Dang, I am not sure how to feel about this kind of “research”
• karlding 5y ago
  The University of Minnesota's Department of Computer Science and Engineering released a statement [0] and "suspended this line of research". [0] https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021 https://cse.umn.edu/cs/statement-cse-linux-kernel-research-a...
  • bjornsing 5y ago
    They don’t seem all that happy about it. :)
    • elliekelly 5y ago
      I don’t read any emotion in that statement whatsoever.
    • kfarr 5y ago
      > We take this situation extremely seriously. We have immediately suspended this line of research. yeah those department heads seemed pretty pissed
  • de6u99er 5y ago
    Not sure how this university is run but this doesn't sound plausible to me. >... learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel And this sounds like mainly a lot of damage control is going to happen. >We will report our findings back to the community as soon as practical.
    • detaro 5y ago
      Why does it sound implausible? In any uni I've interacted with, profs did pretty much their own thing and without a reason very little attention is paid to how they do it (or even what they do).
  • vintnes 5y ago
    According to the "Hypocrite Commits" paper by Qiushi Wu, UMN specifically approved this research, granting IRB exemption. https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap... See section VI-A (page 8).
• ne38 5y ago
  It is not done for research purpose. NSA is behind them
• spinny 5y ago
  Are they legally liable in any way for including deliberate flaws in a piece of software they know is widely used and therefore creating a surface attack surface for _any_ attacker with the skill to so do and putting private and public infrastructure at risk ?
• TedShiller 5y ago
  TLDR?
• pertymcpert 5y ago
  I want to know how TF the PC at the IEEE conference decided this was acceptable?
• a-dub 5y ago
  so basically they demonstrated that the oss security model, as it operates today, is not working as it had been previously hoped. it's good work and i'm glad they've done it, but that's depressing. now what?
• inquisitivemind 5y ago
  I have a question for this community: Insofar as this specific method of injecting flaws matches a foreign country's work done on U.S. soil - as many people in this thread have speculated - do people here think that U.S. three letter agencies (in particular NSA/CIA) should have the ability to look at whether the researchers are foreign agents/spies, even though the researchers are operating from the United States? For example, should the three letter agencies have the ability to review these researchers' private correspondence and social graphs? Insofar as those agencies should have this ability, then, when should they use it? If they do use it, and find that someone is a foreign agent, in what way and with whom should they share their conclusions?
• brundolf 5y ago
  What a bizarre saga.
• Pensacola 5y ago
  <consipracy theory>This is intentionally malicious activity conducted with a perfect cover story</conspiracy theory>
• werber 5y ago
  Could this have just been someone trying to cover up being a mediocre programmer in academia by framing it in a lens that would work in the academy with some nonsense vaguely liberal arts sounding social experiment premise?
• GRBurst 5y ago
  Actually I do understand BOTH sides, BUT: The way the university did this tests and the reactions afterwards are just bad. What I see here and what the Uni of Minnesota seem to neglected is: 1. Financial damage (time is wasted) 2. Ethical reasons of experimenting with human beings As a result, the University should give a clear statement on both and should donate a generous amount of on money for compensation of (1.) For part (2.), a simple bit honest apology can do wonders! --- Having said that, I think there are other and ethically better ways to achieve these measurement.
• up2isomorphism 5y ago
  From an outsider, the main question is: does this expose an actual weakness in the Linux development model? From what I understand, this answer seems to be a "yes". Of course, it is understandable that GKH is frustrated, and if his community do not like someone pointing out this issue, it is OK too. However, one researcher does not represent the whole university, so it seems immature to vent this to other unrelated people just because you can.
  • space_rock 5y ago
    The university has an ethics board to review experiments. So what experiments get allowed reflects on the whole university
    • up2isomorphism 5y ago
      If you are actually in a graduate school, you will know it is practically impossible to review details like this, otherwise nobody can do any real work. Besides, how to test the idea without doing what they did? Can you show us a way?
  • dawnbreez 5y ago
    The main issue is that the researchers are now untrustworthy because they conducted this experiment without permission. Essentially, the kernel dev team can no longer trust that any given patch from U of M isn't the same research team using a different email address to submit more malicious patches.
    • up2isomorphism 5y ago
      You actually think there should be way to "trust" someone by looking at his/her Email address domain?
      • dawnbreez 5y ago
        No? I think that there is reason to not trust anything from a given domain if that domain is in use by bad actors.
• iou 5y ago
  Did Linus comment on any of this get? :popcorn:
• emeraldd 5y ago
  Is there a readable version of the message Greg was replying to https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah... ? Or was there more to it that what Greg quoted?
• ineedasername 5y ago
  "We'd like to insert malicious code into the software that runs countless millions of computers and see if they figure it out" I don't think this was the pitch they gave to their IRB.
• soheil 5y ago
  Experiment: let's blow up the world to find out who might stop us so we can write a paper about it.
• soheil 5y ago
  Is getting reactions from HN also part of their experiment and should we expect our comments to be written about in their paper?
• calylex 5y ago
  Reminds me of "It's just a prank bro" video from Filthy Frank https://www.youtube.com/watch?v=_wldE_4xjVQ https://www.youtube.com/watch?v=_wldE_4xjVQ
• jbirer 5y ago
  I am baffled by the immaturity and carelessness of experimenting on a kernel that millions of critical machines use, and I applaud the maintainers for dealing swiftly with this.
• 8bitsrule 5y ago
  Couldn't help themselves. Once they thought of it, they just had to Gopher it.
• chandmk 5y ago
  I am wondering if Aditya didn't respond the way he did (using corporate lawyer's langauge), Greg would have not reached to this conclusion? I am a bit surprised by the entitlement he was showing. Why would anyone use those words despite sending a nonsense patch! What kind of defence he was thinking he had among a group of seasoned developers other than being honest about intentions? I wouldn't be surprised if his professor doesn't even know what he was doing!
• mrleinad 5y ago
  Well, the University got pissed off. https://twitter.com/UMNComputerSci/status/1384948683821694976 https://twitter.com/UMNComputerSci/status/138494868382169497...
• beprogrammed 5y ago
  Well we get to look at the real results of this in realtime, as they get there whole organization banned from the kernel.
• fennecs 5y ago
  They are rightfully worried about old commits? Maybe it's time they switched to a more secure language which can more easily detect malicious code. To be honest C seems critically insecure without a whole lot of work. If a bunch of experts even struggle, seems like they need better tools. Especially since Linux is so important, and there are a lot more threats, Rust seems like a good solution. Apart from some perhaps critical unsafe stuff which should have a lot of attention, requiring everything to be safe/verified to some extent surely is the answer.
• sida 5y ago
  Let me play devil's advocate here though. This is absolutely necessary and shows the process in the kernel is vulnerable. Sure, this is "just" a university research project this time. And sure, this is done in bad taste. But there are legitimately malicious national actors (well, including the US govt and the various 3 letter agencies) that absolutely do this. And the national actors are likely even far more sophisticated than a couple of PhD students. They have the time, resources and energy to do this over a very long period of time. I think on the whole, this is very net positive in that it reveals the vulnerability of open source kernel development. Despite, how shitty it feels.
  • mikewarot 5y ago
    Let me pile on top of that and note that if Linus had listened to his elders and used a Microkernel instead of the monolith, the kernel would be small enough that this kind of thing wouldn't be happening.
    • Wxc2jjJmST9XWWL 5y ago
      You are free to use Minix or Hurd, not sure if a modern browser will even run, but if you want a microkernel so badly... So if only Linus would have listened we would have Linux as microkernel equally feature rich and widespread? Stupid Linus /s https://www.minix3.org/ https://www.minix3.org/ https://www.gnu.org/software/hurd/ https://www.gnu.org/software/hurd/
• leric 5y ago
  If caught, that's a research, not caught that's a backdoor
• rwoerz 5y ago
  So, next paper would be like "On the Effectiveness of Using Email Domain Names for Kernel Submission Bans"
• NalNezumi 5y ago
  So the professor in center of this event, Kangjie Lu[0] is also program comitee at IEEE S&P 2021.[1] I'm by no means an security expert nor a kernel contributor but considering he's program comitee, is these kind of practices a common place in Security/Privacy researchers? Does idea/practises like this get a pass on conference publishing regularly? [0] https://www-users.cs.umn.edu/~kjlu/ https://www-users.cs.umn.edu/~kjlu/ [1] https://www.ieee-security.org/TC/SP2022/cfpapers.html https://www.ieee-security.org/TC/SP2022/cfpapers.html
• amarant 5y ago
  I've been thinking, what would happen if someone intentionally hacked a university and erased all data from all their computer systems, and then lied to their faces about it? New white paper due soon
• nullc 5y ago
  CS department security research is near universally not held to be in the scope of IRBs. This isn't entirely bad: the IRB process that projects are subjected to is so broken that it would be a sin to bring that mess on any other things. But it means the regularly 'security' research does ethically questionable stuff. IRBs exist because of legal risk. If parties harmed by unethical computer science research do not litigate (or bring criminal complaints, as applicable) the university practices will not substantially change.
  • dawnbreez 5y ago
    Security research has its own standards of ethics, and these researchers violated those standards. 1. You don't conduct a penetration test without permission to do so, or without rules of engagement laying out what kinds of actions and targets are permitted. The researchers did not seek permission or request RoE; they tried to ask forgiveness instead. 2. You disclose the vulnerabilities immediately to the software's developers, and wait a certain period before revealing the vulns to the public. While the researchers did immediately notify the kernel dev team in 3 cases, there's apparently another vulnerable commit that the researchers didn't mention in their paper and did not tell the kernel dev team about, which was still in the kernel as of the paper's publish date. Apparently the IRB team that reviewed this project decided that no permission was needed because the experiment was on software, not people--even though the whole thing hinged on human code review practices. It's evident that the IRB doesn't know how infosec research should be conducted, how software is developed, or how code review works, but it's also evident that the researchers themselves either didn't know or didn't care about best practices in infosec.
• satai 5y ago
  Let’s add to the question “what is the quality of code review process in Linux?” an other one “what is the quality of ethical review process at universities?”. I think there should be a real world experiment to test it.
• skerit 5y ago
  And yesterday there was another bit of Linux news by Greg KH trending on Reddit. Nice to see him stepping into the spotlight more :)
• bluenose69 5y ago
  The ban seems rational, when viewed in the context of kernel development. The benefit is twofold: (a) it's simpler to block a whole university than it is to figure out who the individuals are and (b) this sends a message that there is some responsibility at the institutional level. The risk is that someone writing from that university address might have something that would be useful to the software. Getting patches and pull-requests accepted is not a guaranteed. And it's asking a lot of kernel developers that they check not just bad code but also for badly-intended code. I had a look at the research paper (https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...) and it saddens me to see such a thing coming out of a university. It's like a medical researcher introducing a disease to see whether it spreads quickly.
• ElectricMind 5y ago
  Will he get job/work somewhere again?
• dt123 5y ago
  cannot wait for Rust in the kernel..
• jokoon 5y ago
  I'm not surprised. I'm repeating myself, but I'm pretty certain the NSA or other intel agencies (Israel, especially, considering their netsec expertise) have already done it in one way or another. Do you remember the semicolon that caused a big wifi vuln? Hard to really know if it was just a mistake. I'm going full paranoiac here, but anyway. You can also imagine the NSA submitting patches to the windows source code, without the knowledge of microsoft, and so many other similar scenarios (android, apple, etc)
• rationalfaith 5y ago
  The experiment is ridiculous and apathetic. You need consent to deal with this. They could've funded some internal project and have people at random submit commits and a control group that doesn't What they did is unethical to the max. Good job on Greg for holding ground.
• cmclaughlin 5y ago
  What a waste of talent... these kids know how to program, but instead of working on useful projects they’re wasting everyone’s time. It’s really troubling that any professor would have proposed or OK’d this.
• birdyrooster 5y ago
  Straight up grift. If it looks like a duck, quacks like a duck...
• xmly 5y ago
  So they A/B tested the kernel maintainers and got banned. What about the kernel security? Is the patch process getting improved?