27 ms·

An Update on the UMN Affair

462 points by chmaynard 6y ago

belinder 6y ago
So the paper is not being published? Then what was the whole point of the research
- jasonjayr 6y ago
  They were forced to retract the paper as a result of this debacle.
- kjs3 6y ago
  The point was to get a paper published. That's it.
endisneigh 6y ago
My take away from this affair is how we again and again overgeneralize. It never made any sense to blame UMN in general for an action taken by arguably only a single department, and even holding them culpable is a stretch (this is in response to some people in another thread saying no one from UMN should ever be able to contribute to the kernel ever again to teach them a lesson). It's not really surprising a bunch of academic-types were too far removed from open source etiquette - that removal is pretty much the source of the drama (this entire thing would've been avoided if a few key people were informed ahead of time). My other take away is that it seems social engineering still is the most powerful type. From this to the Twitter fiasco - it's worth trying to make your workflow resilient against social engineering indeed - by the authors own admission, the process leans a bit too much towards pre-established trust and credibility. Unfortunately that trust isn't immutable, nor is it everlasting so it's a spot that can be exploited.
- sidr 6y ago
  If the university doesn't review research methodologies that directly impact others (I'm not talking about societal impact of the work down the line), then they should be considered bad-faith actors. This is the equivalent of punishing a university for not having an IRB for human experiments . I assume individual members from UMN may still contribute without a UMN address. They just won't be given any special consideration (implicit or explicit) as belonging to a particular organization.
  - detaro 6y ago
    By that standard, basically no university meets your threshold. (in other places the IRB might have decided differently, but also that's not extremely likely) Researchers are just not monitored that closely usually.
    - hn8788 6y ago
      They'd already complained to UMN about the research, and nothing was done about it. It wasn't just the IRB that allowed it to continue.
      - detaro 6y ago
        Is that the case? I hadn't seen anything conclusive that that actually had happened? (some people said the contacted the IRB, but presumably that was part of what triggered the IRB to look at it) But looking into this and clearly documenting it is part of what UMN needs to do.
        hn8788 6y ago
        In the most recent email chain where they banned UMN, GKH said that they were going to have to complain to the university again. From what I understand, the IRB review was initiated by the researchers themselves after receiving backlash from the original paper.
      - cycomanic 6y ago
        What do you mean continued it. The research of submitting buggy patches had ended already (they even had a draft paper). The whole row started because one of the researchers submitted a patches from a (not very good apparently) in progress static analysis tool. The bad quality of the patch led to GKH accusing the submitter that they are continuing. As the article states this was not the case.
    - HarryHirsch 6y ago
      But researchers don't operate within a vacuum, research is a social effort. The faculty member and the graduate student who dreamt up this line of research have discussed it with others and they all thought it was a splendid idea.
- namelessoracle 6y ago
  Agree or disagree with whether it should have been done but blaming UMN was a social tactic to embarass the University so that UMN would apply pressure to the researcher and deal with them.
  - infogulch 6y ago
    > social tactic This, but not derisively. Note that the university's IRB granted an exception for this behavior, and neither UMN nor the department responded with consideration for the concerns raised by the kernel team until after they banned the whole domain.
  - mturmon 6y ago
    The social tactic could have been changed from "we will revert all recent patches originating from UMN" to "we are forced to review all recent patches originating from UMN, and to enforce stricter scrutiny of UMN patches going forward." Second is more honest and also applies social pressure.
    - hmfrh 6y ago
      The second option also doesn't result in any big negatives for UMN associated personnel because the kernel devs take on all the work of enforcing stricter scrutiny.
    - raegis 6y ago
      That sounds like a good first warning. But they persisted even after Greg KH complained to UMN and told them to stop. A more severe punishment for a second offense is needed, IMO.
- kayodelycaon 6y ago
  > It never made any sense to blame UMN in general for an action taken by arguably only a single department UMN is ultimately responsible for the actions of the people under their organization. This include oversight and dealing with the actions of those people when they have crossed lines.
  - castlecrasher2 6y ago
    Agreed, and I'm stunned this is even in question.
- einpoklum 6y ago
  > It's not really surprising a bunch of academic-types were too far removed from open source etiquette Umm, there's etiquette in academia too you know... even FOSS etiquette in academia.
  - shadowgovt 6y ago
    And that fact highlights the mistakes made here. A fellow researcher intentionally pushing bad data into a colleague's study as some kind of penetration test on the colleague's scientific methodology would be justifiably seen as betrayal, and a possibly bad faith betrayal at that since research grants are a finite resource. The researchers in the story appear to have failed to extrapolate that sort of collegial courtesy to the open source community maintaining Linux.
    - einpoklum 6y ago
      The researchers in this story acted unethically - as academics. I'm saying it's not the culture difference.
at_a_remove 6y ago
Twenty years ago, this incident would have been met with a "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." A decade back, "play stupid games, win stupid prizes" would have won out. Now, I think The Kids would say "Fuck around and find out" (this is often accompanied by a stencil of an open-mouthed alligator). No matter the form of the reaction, I am still left wondering at the proportions of disregard, hubris, naivete, and perhaps sheer lack of consideration of consequences that went into this whole affair. For the life of me I simply cannot imagine anyone patting me on the back and saying, "Good show on that paper, old boy! Smartly done!" Was there nobody in the whole group who had reservations? Were any expressed or were they simply hidden away? I am sincerely curious as to how it managed to get to this point.
- defaultname 6y ago
  I'll be the odd one out and say that I see nothing wrong with their study. There are much more skillful, much better resourced actors who can do what the UMN did much more discretely. I mean, the UMN flaws were egregious and blatantly obvious. They should have been met with ridicule at first glance. If they aren't (and they weren't), there are problems that need to be addressed. But there's a torch mob about this -- a very misled, and I would say foolish torch mob -- and as a result comments like mine will invariably be moderated down to invisible. I guess if we just brigade against some junior researchers it'll help defend the kernel from actually malicious actors...
  - floatingatoll 6y ago
    If UMN’s ethics review(s) has approved this experiment in cooperation with Linus/Greg, there would not be anything to be outraged about. The outrage, and the core ethical violation, centers around intentionally wasting the time of others for selfish benefit without appropriate review and consent.
    - zajio1am 6y ago
      > If UMN’s ethics board has approved this experiment in cooperation with Linus/Greg, there would not be anything to be outraged about. I do not think that would help. This was done on public mailing list and deceptive behavior was also against third parties (other reviewers). I do not think Linus/Greg can give consent to that.
carbocation 6y ago
> The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence. To the contrary, my takeaway from these events is a further erosion of the credibility of Hanlon's razor.
- edoceo 6y ago
  the razor holds IMO. because this isn't adequately explained by incompetence alone. the crafty/sneaky approach has some hints of malice.
  - carbocation 6y ago
    That is actually totally fair. But I will offer a quibble: having to focus on the "adequately" part makes the razor less interesting.
    - admax88q 6y ago
      But... it's there. Without the "adequately" its not Hanlon's razor, its random other razor that is probably less accurate.
- hderms 6y ago
  People jump to Hanlon's razor way too quickly. The mere knowledge that people are likely to brush off things as incompetence instead of malice is a potential tool in the hands of the malicious. Yes, all things being equal, it's better to err on the side of assuming someone didn't have malicious intent, but some people like to use it like a blunt instrument and the fact they do is dangerous in such a complex world. Additionally, it's incredibly biased in its application simply because only a good-natured person would be inclined to brush off malicious action as incompetence. Malicious actors would be unlikely to do the same.
jolux 6y ago
I am not terribly surprised to learn that code review processes for the kernel are not as stringent as they should be. However, I do wonder whether the kernel's defect rate is significantly different from that of NT or XNU, and whether the situation could be significantly improved. I thought there was large institutional investment in Linux kernel development, but if the existing developers are horribly overworked and stand no chance of properly reviewing every patch, even from existing contributors, clearly the project needs more resources. I'm glad that this situation has prompted reflection on these issues for kernel developers though. It seems like the best possible outcome.
lacker 6y ago
Key takeaway from this update: One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.
- chmaynard 6y ago
  Instead of submitting patches with known bugs, the UMN researcher could have done a retrospective study of patches from other kernel developers containing bugs that were later found and fixed. Not only was he acting in bad faith, he was stupid.
  - hangonhn 6y ago
    There was also a high degree of arrogance on his part. That he thought his needs and priorities outweigh those of the much, much bigger community and/or that he doesn't need permission from anyone in charge of the codebase is just astounding.
  - izgzhen 6y ago
    That is not considered high impact by the research community ;)
  - xucheng 6y ago
    Alternatively, I think the research could be done in an isolated experiment environment among consented participants. For example, they could ask maintainers to review some set of patches outside the context of Linux kernel. They would then ask maintainers opinions on the said patches using some form of questionnaires. If the participants are well informed the nature of the experiments, there would not be any ethic concerns. For incentive, the researchers could pay for any maintainers willing to participate the experiments.
  - cpeterso 6y ago
    The researcher also could have coordinated with Linux and other Linux leads, so they know which patches will be "bad". They all want the Linux review process to produce high quality code and could have suggested other ways to test the process.
adamrezich 6y ago
interesting that they admit that going forward, they don't really have the resources to fully vet all submitted patches to the degree necessary to prevent something like this from happening again. seems like, if nothing else, this has proven the Linux kernel as pretty vulnerable to similar, more malicious future attacks. there's no real easy solution to this problem
- detaro 6y ago
  That's not really news though, and IMHO one of the major points of criticism against the researchers: If what they did would have shown anything new or unsuspected it'd have been one thing, but they didn't, and could have shown the same with less impact.
  - UncleMeat 6y ago
    The research was a little more compelling than that, since they did use an automated tool to find the partial vulns that they could sneakily upgrade to complete vulns. That is a little more interesting than introducing an entire complete vuln in a patch and hoping nobody notices. Still very unsurprising, but a little more interesting than how the work has been presented in media. I do also still believe that Oakland was incredibly foolish for accepting this work and that the PC has almost as much egg on their face as the researchers.
flowerbeater 6y ago
This is a reasonable and balanced analysis of the situation. In retrospect, it seems like the reversion of the 190 patches was an overreaction that ended up causing a lot of confusion: many people even on HN misinterpreted the comments on reversions to believe that bad patches were committed to the source tree or to stable. But besides the lesson that one ought not to be deceptive with submitting patches, is also the lesson that the kernel is not as well reviewed as one may hope and with some effort, it's certainly possible to add an undetected vulnerability. I think that's probably one thing that led to the drama, is that the fundamental trust and work of the kernel was attacked, and the maintainers felt the need to fight back to protect their reputation.
- detaro 6y ago
  I don't think the latter part is true, my impression is that the kernel people are very well aware of the limits of their review ability and don't pretend to be unfoolable.
  - flowerbeater 6y ago
    There's a wide range of degrees between "unfoolable" and "can be done by a persistent student". I think the impression (at least my impression) used to be is that it was possible before but quite unlikely without state-level efforts, but now we understand a properly advised student can get most of their attempted vulnerabilities inserted.
    - detaro 6y ago
      The pure number of just regular bugs that aren't caught is already a good indicator that not much special effort is needed. (And "just a persistent student" isn't that little, given that the group also contributed regularly to the kernel, was studying its security, ... and thus quite familiar with the field, and the kind of people a nation state would employ for that)
  - Mathnerd314 6y ago
    The harder part is probably fooling all of the static analysis tools that get run on the kernel, Coverity, Coccinelle, Smatch, and so forth.
maest 6y ago
> [LWN subscriber-only content] I'm guessing you weren't supposed to share this link?
- swyx 6y ago
  right below that it says "The following subscription-only content has been made available to you by an LWN subscriber." feature, not bug
  - WA9ACE 6y ago
    I'm so very happy that's a feature, I subscribed to LWN a while back from reading some subscriber only links on HN.
- janfoeh 6y ago
  LWN links are intentionally shareable. See the "Welcome .." box at the top: > The following subscription-only content has been made available to you by an LWN subscriber.
- deleted 6y ago
  [deleted]
- Diederich 6y ago
  FYI: the owner of lwn.net is on record as being ok with people widely sharing subscriber only content links.
- gwd 6y ago
  When (as a subscriber) you make such a link, it says that if such links are "abused", the ability to make them may go away. Having the occasional article posted to HN seems to be OK with them (or they probably would have added a specific request not to post them to news aggregation sites). It's likely a wholesale "Free LWN for all" page with a weekly subscriber link to all the articles they're worried about.
- woofie11 6y ago
  Nope. LWN built the feature that subscribes can share links as a feature. If you subscribe, you can share. LWN is a very fair and ethical organization. This struck what felt to them (and to much of the community) as a good balance.
einpoklum 6y ago
> The corollary — also something we already knew — is that code going into the kernel is often not as well reviewed as we like to think. This may be true but not really a corollary of what happened. In fact, it seems there aren't the resources to determine how many of the patches are actually bad and should really be reverted.
toss1 6y ago
Key point: >>"kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands. They are, as a result, forced to rely on the trustworthiness of the developers who submit patches to them. The kernel development process is, arguably, barely sustainable when that trust is well placed; it will not hold together if incoming patches cannot, in general, be trusted. " Yet these UMN "researchers" deliberately chose to violate that trust. Are they so ethically clueless and arrogant that they didn't think to review the plan? Did they hold any kind of ethical review and pass it, or fail it and decide to proceed anyway? In any case, they've now alerted the entire world that the Linux dev process and OS dev processes in general are incredibly vulnerable to malicious actors. This vulnerability is also shown by another #1 HN story[1] [1] https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/ https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/
- detaro 6y ago
  How does the netlab link have anything to do with Linux development processes?
  - toss1 6y ago
    >> "... a backdoor targeting Linux X64 systems, a family that has been around for at least 3 years." The point is that OS systems fundamentally depend on the trustworthiness of the contributors and the diliginece and bandwidth of the maintainers. Both are examples showing that the diligence and bandwidth is not infinite, and can be relatively easily overwhelmed or outmaneuvered. The UMN hack showed how easily the trust can be violated, and the netlab 3 year lifetime before discovery shows how easily flaws can stay hidden. The saying is "many eyes make shallow bugs". In an ideal case and with systems that are small relative to the body of people maintaining and actively scrutinizing it, that's true. The reality is that the scale of Linux and most OS is now well beyond the set of people scrutinizing it. How much source code did you review before you installed your latest build?
    - detaro 6y ago
MilnerRoute 6y ago
The thing that troubles me is how hundreds of good-faith patches came under suspicion. We can say that the researchers are entirely responsible for that as well -- for creating that need for suspicion. But I do wonder if we were too quick to also fall into a pattern of outrage and absolute rejection. This story went viral partly because it seemed much worse -- "And they're still submitting malicious patches to this day!" -- than it actually was.
- bigwavedave 6y ago
  I dunno, I think this is one case where outrage and rejection weren't too quick in coming. Let's say you're a software architect (dunno if you are or not). You hire four new software devs, two of them from Colorado State University, and you put the two from CSU on the same team. After a year, you find out one of them has been secretly working for CSU's cyber security research department and poisoning your product with patches that do nothing or subtly introduce bugs on purpose purely so their professor can write a research paper about your company's process. Naturally, you fire the developer and that leaves a bad taste in your mouth and CSU promises not to interfere again. Then you get suspicious and start checking the work of the other CSU dev more closely and find out they're submitting bad patches too! They claim that these bad patches were submitted because their experimental static code analyzer didn't find any issues with them. What conclusion should you reach?
  - MilnerRoute 6y ago
    You should conclude "I don't know whether or not these patches were submitted in good faith." People sometimes submit bad patches. Not all of them are malicious. I don't think we've fully addressed or explored the scenario where a young, bright-eyed aspiring student coder does in fact make an innocent mistake. And then is accused of deliberate malicious sabotage. And large chunks of the internet also start condemning them for deliberate and malicious sabotage. What does that say about our community?
    - kuratkull 6y ago
      It's also important to understand the situation you are in - if you are the second CSU dev you got some extra due diligence to do. This is the real world, it's not fair.
woofie11 6y ago
... And I'd still like some update on the UMN IRB, which exempted this research. Graduate students will make mistakes, and as much as this was stupid, reckless, and unethical, graduate school is a time to learn. Professors will make mistakes. That's less excusable. IRBs are set up exactly to prevent stuff like this. My experience is they don't work, and UNM's clearly doesn't.
- dekhn 6y ago
  IRBs are set up to prevent costly lawsuits against the university, although they were originally intended to avoid human experimentation like the nazis (and many eugenecists and other doctors in the US) did.
  - HarryHirsch 6y ago
    There are informal mechanisms as well. Someone will say to a hotheaded or greedy faculty member "look, you can't boot M off this patent, three years ago that other faculty member booted N off a few patents, there were issues, and then we had to pay tens of thousands for all the amended filings!"
  - woofie11 6y ago
    This is false. IRBs are required under federal law, which did result from ethics violations, both by the Nazis, but just as much by US-based experiments, like the Stanford prison study, the Tuskegee Syphilis Study, Yale's Milgram experiment, US-based human radiation experiments, and so on. At some point, we decided we should have ethical research. That's designed to solve a broad set of problems. Most of this isn't about law suits but about federal research funding. There's little private right of action, but if you don't have research reviewed by an IRB, you can't get federal research grants. OMB requires an IRB. That said, universities are finding loopholes. A major one is for profs to do research on "private" time as "consulting." Lots of unethical research being done and published that way. Professors don't really have a clean split between work/life or work 40-hour weeks, so while perhaps this started out reasonable ("I'm consulting to Google"), right now, it's just a way to bypass IRBs. As a footnote: What's not widely recognized in the US yet were the close ties between Nazi research and US research, pre-war. A lot of the eugenics stuff was developed by the American scientific establishment.
notyourday 6y ago
The key take away, for me, has been that the Foundation that sent the demand letter does not have the balls to grant Stupid Prize to those that so diligently tried to win it. A good demand letter announcing the winning of the Stupid Prize would have been to tell the university that it would be banned until it: * fires the assistant professor * terminates all the students that participated with a note that should any of those students or a professor go to a different university that university would be banned as well. Had that price would have been awarded it would have definitely made into future ethics classes.
temp8964 6y ago
I totally agree this is a very balanced review of the affair. The fact that "kernel maintainers ... are overworked and do not have the time to properly review every patch that passes through their hands" is not a situation created by the group of researchers. If the Linux kernel is so crucial to the real world industry, and the kernel team is so distressed at their work, this is a problem need to be seriously addressed. Proactively punish the whole UMN does nothing to address the real issue here. If the team is so distressed at this tremendously important work and they constantly feel they are on the edge of collapsing, may be you really really really should ask for outside help and even demand more contributions from the big techs. Nobody should overwork, especially those work on something so crucial to the whole industry. Edit: I just read a line from the Rust Foundation page [1]: "Good software is built by happy, well-supported people." 1. https://foundation.rust-lang.org/ https://foundation.rust-lang.org/
- josefx 6y ago
  > is not a situation created by the group of researchers. As far as I got from various threads on the issue the university has been involved in at least two major time wasters: * Breaking the trust model and forcing the maintainers to revert all already accepted patches on suspicion alone * Running a primitive static code analysis tool that got overeager with correcting impossible bugs and not marking the generated patches as such. > Proactively punish the whole UMN does nothing to address the real issue here. Proactive? The universities review board signed off on that mess, there is nothing proactive about banning a group of bad actors after the fact.
  - SiempreViernes 6y ago
    Proactive probable refers to also banning the 6700 staff, along with the 46000 students, that are not part of the research project from ever contributing.
    - monocasa 6y ago
      That staff and student body is governed by the same ethics board that allowed this to happen.
openasocket 6y ago
> the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question. Wait, so none of the maintainers were actually fooled by these hypocrite commits? In 2/3 the maintainers explicitly caught the use-after-free bug on their own, and in the third they had some unrelated feedback. Maybe I mis-read their paper, but they made it sound like if they hadn't told the maintainers "wait, don't merge this, it's bad" they would have introduced vulnerabilities into the kernel. But that isn't what happened at all! Again, maybe I mis-read the paper, but it seems like we can add dishonesty, if not outright fraud, to the list of problems with these researchers.
- iudqnolq 6y ago
  Possibly? It depends on whether you think every patch they submitted was part of the research. > Thus, one of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find. Actually, it wasn't all of them; he mentioned a list of 68 others requiring manual review because they do not revert easily. > Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel. > For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them. In others, the intended change was done poorly and will be reimplemented in a better way. And some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).
shp0ngle 6y ago
“It’s easier to ask for forgiveness than for permission”, huh?
- kuratkull 6y ago
  The older you are, the more you understand the importance of knowing this.
returningfory2 6y ago
HN meta point > The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence. This is exactly the comment I left on the original HN thread, which was downvoted [0]. I can understand the kernel maintainers being overwhelmed by the situation and jumping to the worst case interpretation, but interesting to see HN commenters doing the same, too. https://news.ycombinator.com/item?id=26890520 https://news.ycombinator.com/item?id=26890520
- tester756 6y ago
  HN went really emotional about this particular matter
  - waiseristy 6y ago
    HN also often suffers the same fate as other social networking sites, where comments that don't align with masses get downvoted
- raegis 6y ago
  If I dropped by a UMN researcher's office and asked for 30 minutes of their time for something they consider unimportant, they could reasonably reply, "no, I'm too busy with research". Likewise, a kernel developer should not be forced to unwittingly waste their time. The "malice" here is that the researchers may consider their time more valuable than others. Incompetence is a separate thing. Lastly, kernel developers are naturally going to trust computer scientists at major universities. The researchers know this (subconsciously or not) and took advantage of it. Patches from smith@joeschmoe.com will automatically get more scrutiny.
  - cycomanic 6y ago
    But that is not what happened. In the bug submission experiment they used Gmail addresses not their UMN addresses. The whole thing came up when one of the students (I think he was a graduate student working in the research group) submitted patches from his over eager static analysis tool using his uni address. So if anything the work from the uni adress received more scrutiny than the other patches.
dcow 6y ago
So, basically, Greg is kind of a jerk too. I mean I respect the dude for all the work he does but man his back and forth with an honest person and jump to ascribe malice looks pretty bad in this light. An apology might be in order.
- tofuahdude 6y ago
  What? Greg's open-source work was maliciously attacked by the exact same actor who then submits incompetent patch requests. I think he responded in a totally appropriate manner. He does not owe these people anything - and certainly not kindness after their track record.
  - dcow 6y ago
    It wasn't the same person and it wasn't an attack. Read the LWN article. > The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.
    - tofuahdude 6y ago
      By "actor" I was referring to the institutionally untrustworthy UMN, but since you seem interested in splitting hairs, you should probably realize in doing so that Aditya Pakki === Aditya Pakki. Notice that Aditya is one of the signers of the apology letter: https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL... And that several of the identified vulnerabilities were tied to Aditya: https://lwn.net/ml/linux-kernel/YH+zwQgBBGUJdiVK@unreal/ https://lwn.net/ml/linux-kernel/YH+zwQgBBGUJdiVK@unreal/
      - re 6y ago
slaymaker1907 6y ago
I really think this whole thing would make for entertaining content on one of the YouTube drama channels. Overall, I thought the kernel team was right to be upset about being experimented on without consent, but the exchanges on both sides had some notable incidents of immaturity. I didn't think the attacks against the static analysis guy were totally justified. They were calling him an idiot for putting in an unnecessary null check. To be clear, he then also overreacted, and that really made me think that it only takes one side to start de-escalating things. The most disappointing response IMO was from the University itself. I didn't like how they deflected off the issue of why there was no IRB questioning of this. Just because human experimentation is narrowly defined federally doesn't mean you can't have higher standards.
shockeychap 6y ago
> Consider, for example, the 5.12 development cycle (a relatively small one), which added over 500,000 lines of code to the kernel over a period of ten weeks. The resources required to carefully review 500,000 lines of code would be immense, so many of those lines, unfortunately, received little more than a cursory looking-over before being merged. I am more than a little astounded that new functionality is being added to the kernel THAT fast.
dcow 6y ago
> They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them. ... kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands ...code going into the kernel is often not as well reviewed as we like to think. Sounds like there’s some room for improvement in the process of how lighter weight contributions are introduced, reviewed, and land in the kernel. Perhaps there is a technical solution that would help ease the load off maintainers and shift some of the burden to patch authors. — When I find myself in times of trouble / mother Mozilla speaks to me / whisper words of wisdom / don't use C. And in my hour of darkness / Rust is installed in my system tree / emitting tokens of wisdom / don't use C. And then the broken hearted people / maintaining kernel code agree / Rust's safety is the answer / don't use C. For though they may be parted / Rust will prevent Use After Fee / they will see the answer / don't use C. And when the code is cloudy / the borrow checker confronts me / thou shall specify reference lifetimes / don't use C. I wake up to the sound of safe code / not one vuln surrounding me / rust is in the kernel / no more C.
- azinman2 6y ago
  Rust doesn’t magically make your code bug free. The fixes/bugs you reference are highly unlikely to be all memory management related (eg use-after-free), and you can still do unsafe things in Rust even with memory.
  - dcow 6y ago
    Of course you can. But it is much harder. I'm just having some fun. Anecdotally, Rust coerces you into writing sound code and really helps break some destructive habits that C breeds. I rarely need to debug Rust code and when I do the bugs are logic errors not memory errors. It's a noticeable difference. For lightweight contributions to the kernel and "peripheral" contributions (where some big company writes a massive messy driver because the market forces their hand.. not because they enjoy curating and actively helping to maintain linux), the type of discipline Rust enforces is invaluable. Also, what do you mean that Rust won't solve use after free? The whole point of the borrow checker is tracking and enforcing reference lifetimes in order to prevent using a pointer to memory that's been dropped from scope and no longer has an owner (has been freed). Sure it can't prevent all issues magically just yet (there are limitations) but it's a positive force in the right direction. Rust forces developers to do upfront what is usually relegated to careful code review. You're forced to think about the memory implications of your code. If the issue is that we can't thoroughly review the abundance of code submitted to the kernel, then e.g. requiring that, unless justified, new patches shall land in safe rust, seems like it would directly address the core issue that there aren't enough eyes on the code. Obviously it's more nuanced than that, there's existing code you can't just say "all new contributions must be rust".. the example is just illustrative. The existing proposal and work on carefully incorporating rust into the kernel is super awesome. And I'm excited!
cycomanic 6y ago
Apart from the understandable annoyance (anger) of being experimented on and the scandal that this somehow got approved by the UMN ethics board I did find the reaction to this somewhat interesting in that the kernel community was willing to immediately ban every one from UMN (a university of significant size) and investigate/revert all patches originating from UMN. In contrast I don't believe the reaction was anywhere near that strong when it came out that the NSA likely subverted a crypto standardisation process. Should the kernel community have reacted at least equally as strong (if they did and I'm just not aware of it please educate me).
- ilamont 6y ago
  From the UMN response signed by the Computer Science & Engineering department head and associate department head: The study was focused on understanding a system by identifying mechanisms through which security issues could be introduced in Linux software. Therefore, purely as a technical matter, this study did not qualify as “Human Subjects Research” and received no further scrutiny or oversight from the IRB. Importantly, even if one believed the study did involve human research subjects (perhaps due to the interactions and the incidental collection of email addresses), the study would clearly be exempt from IRB oversight pursuant to 45 CFR 46.104(D). In other words, the UMN IRB acted properly in this case. Full response: https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/view https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEi...
  - cycomanic 6y ago
    Ok I guess this shows my ignorance on what constitutes human research (although I'm outside the US and definitions might be different here). I have to say this is a good response letter from the department.
- anonydsfsfs 6y ago
  > In contrast I don't believe the reaction was anywhere near that strong when it came out that the NSA likely subverted a crypto standardisation process It was pretty strong. There were many calls to remove the chair of the IETF CFRG group because of his association with the NSA: https://news.ycombinator.com/item?id=6942145 https://news.ycombinator.com/item?id=6942145
mjw1007 6y ago
I think that's an evenhanded writeup of the situation, but I also think the author should have mentioned in the article that he is himself a member of the technical advisory board whose actions he's reporting on (if https://www.linuxfoundation.org/en/about/technical-advisory-board/ https://www.linuxfoundation.org/en/about/technical-advisory-... is up to date).
Animats 6y ago
That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. That's the trouble with the one giant kernel architecture. Too much trusted code. The QNX microkernel barely changed from year to year, and the number of kernel bugs approached zero. It's only about 65K bytes of code. Yet it could do most of what Linux does.
- gus_massa 6y ago
  I think the problem is that the drivers are "inside" the kernel. Many of the dubious commits are there: > For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them.
truth_ 6y ago
> a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed. So they found a convenient scapegoat. I am not buying it.
occupy_paul_st 6y ago
> Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid Absolutely legendary
bumbledraven 6y ago
> 42 [UMN] patches [out of the 190 listed by Greg Kroah-Hartman] are still set to be pulled out of the kernel... some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).... all of those [42] patches were accepted by subsystem maintainers throughout the kernel, which is not a great result. Perhaps that is a more interesting outcome than the one that the original "hypocrite commit" researchers were looking for. They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them.
shockeychap 6y ago
> But if we cannot institutionalize a more careful process, we will continue to see a lot of bugs and it will not really matter whether they were inserted intentionally or not. I've always known this to be the case with many FOSS projects. (Remember the Heartbleed bug?) I'm a little surprised it's an issue for something this critical that's used by all of the world's largest technology companies, including all of FAANG.
parksy 6y ago
The situation has echoes of the scholars who a few years back submitted fake papers to journals, some of which passed peer review and were published. That was an attempt to backdoor the scientific method, really. I don't condone guerrilla penetration testing whether its on the Linux kernel or a science journal, and I am sure that the ethical implications will be subject to much outrage and debate for some time to come, but when it occurs and is successful it is concerning because if a small team of scholars can do it, so can anyone else. The inner workings of the Linux kernel maintenance has been kind of a black box for me for years, I just naively trust it works and my next update won't compromise my system, so it's concerning that this happened and will be following to see how this plays out.
antattack 6y ago
Given high number of buggy patches being accepted it seems kernel developers could use bug-bounty program.
- Edman274 6y ago
  I'll insert the bugs, and you can fix them, and we'll make bank together!
thamalama 6y ago
reminds me of another potentially critical mistake, https://mncomputinghistory.com/gopher-protocol/ https://mncomputinghistory.com/gopher-protocol/ 'According to Alberti, licensing “socially killed gopher.” Second, changes to internet hardware gradually made Gopher less appealing. As put by McCahill, Gopher was designed within “the limits of what the technology (at the time) could do.” It was deliberately text rich because images were slow to load on the comparatively slow modems of the early 1990s. The decision to prioritize text made Gopher relatively fast while the more image-oriented World Wide Web languished in slow speeds (the “World Wide Wait”). However, by 1994 improvements in modem technology had turned this asset into a liability.'
a_ghoul 6y ago
After doing some academic research I have a sour taste in my mouth for it, and this makes it even worse. Disappointing from UMN.
eximius 6y ago
What I want to know is whether the researchers had ever privately asked anyone in the chain of the kernel whether they would be willing to participate as a filter. Bad example for obvious reasons, but if Linus was given the usernames that would be submitting bad patches and forewarning of which ones were valid and which ones weren't, it could have been done such that the experiment was valid and the commits were not included in the final tree. I think it is a rather mild restriction to the experiment that a single person must be able to find an excuse to recuse themselves - as simple as "I don't have time to look at this, can someone else" would have worked.
feral 6y ago
I found the reaction to this surprising. When Security Researcher tell a company about a bug they've found, and the company reacts badly, this community is usually strongly in favor of the Security Researcher. The overworked corporate sysadmins don't get a lot of empathy. The assumption seems to be that that their software shouldn't have been vulnerable in the first place. Now here's a security researcher researching smuggling bugs into the Linux kernel. It probably should be secure, and probably should face scrutiny. People have tried snuggle bugs into it before.[0] So why is the opinion so strongly against the Security Researcher here? What's the big difference in principal? [0] https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...
- kstrauser 6y ago
  My opinion: security researchers attack an organization’s products, like their code or website or services. UMN attacked the organization’s people to test their defenses. Lots of companies run bug bounty programs and thank you for finding vulnerabilities in their product. Humans don’t scale so well, though, and if you pester the hell out of a company’s office manager trying to social engineer them, that company is going to be super freaking annoyed at you. If UMN had analyzed the Linux code to find problems, then patched them, the kernel team would be happy. They didn’t. They spammed the human maintainers with a flood of patches and lied about why they were sending them. They conducted an impromptu and unanticipated phishing test, and you just don’t do that.
- hyper_reality 6y ago
  One big difference is explained in the article. The fact that code going into the kernel is not as secure as we might hope is already known to the open source community. Maintainers are overworked and none would be surprised if you told them that it would be possible to smuggle in backdoors. This is not a "bug", but an issue with time and resources, and because the researchers attempted to add bugs to demonstrate it just makes it worse. On the other hand, security researchers are finding vulnerabilities that weren't previously known. They've discovered specific exploitable bugs, rather than introducing new ones. Following disclosure, the company can patch the vulnerabilities and users will be safer. Which makes that a laudable thing to do.
re 6y ago
Some of the past related threads: “They introduce kernel bugs on purpose” - https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670 (1954 comments) UMN CS&E Statement on Linux Kernel Research - https://news.ycombinator.com/item?id=26895510 https://news.ycombinator.com/item?id=26895510 (320 comments) Open letter from researchers involved in the “hypocrite commit” debacle - https://news.ycombinator.com/item?id=26929470 https://news.ycombinator.com/item?id=26929470 (374 comments) Linux Foundation’s demands to the University of Minnesota - https://news.ycombinator.com/item?id=26955414 https://news.ycombinator.com/item?id=26955414 (168 comments)
staticassertion 6y ago
> That said, there are multiple definitions of "malice". To some of the developers involved, posting unverified patches from an experimental static-analysis tool without disclosing their nature is a malicious act. It is another form of experiment involving non-consenting humans. What an absurd statement. Malice implies intent ie: the goal was to do harm. There was never any malice - not in the hypocrite commits and certainly not in the static analysis findings.
- darksaints 6y ago
  Yes, malice requires intent, but intent can be interpreted differently too. If I shoot a gun repeatedly in the air for a celebration, I'm not intending to kill someone, but I am intending on acting in a way that has reckless disregard for human life. Malice is an appropriate interpretation of that kind of action, IMO.
  - staticassertion 6y ago
    What? No, it isn't appropriate for that kind of action. That would be negligence. Malice is defined as deliberate harm.
    - darksaints 6y ago
      When you have a reasonable assurance that your actions will cause harm, and you do it anyway, that is virtually indistinguishable from intent to cause harm.
      - staticassertion 6y ago
        No, sorry, that's not how words work. Greg very clearly was implying malice, and intent, which there was none of. I don't care how bad you think the research was, you're welcome to call it negligent, but it was not malicious and it's totally absurd to try to change the definition of the word post-hoc.
        6y ago
rodgerd 6y ago
There is something amusing that the kernel maintainer most outraged by the whole thing is the guy who spends time changing the kernel to cripple OpenZFS.
ThinkBeat 6y ago
Linux is arguably one of the most important software projects on the planet right now. It is vital in so many aspects of society now, Android, AWS/AZure, IOT, routers, etc etc. It should be taken as a serious given that bad actors are working hard, with huge budgets to nefariously gain some advantage in the development of Linux. They will have far better engineers, much larger budges, and have been working on it for many years. I would imagine ever intelligence service on the planet would love to have obscure exploits embedded in the kernel. I can easily imagine a scenario where a single exploit was introduced over many months one tiny bit at a time. Each patch a fully working fix for unrelated problem. Fully Legit. But when they are all combined something wonderful happens. (for the nefarious player). This stunt was a few students who were not well funded nor were they uber kernel coders. Yet they had some success (depending on what you call success). I imagine the NSA has a team on this, with some exceedingly well skilled kernel coders working on embedding things, and I am sure they have a second team to find possibly implants by foreign services and so on. Had this been security researchers who managed to get changes into the WindowsNT kernel I think the reaction by the core Linux devs would have been different. (and yes I am 100% there are people spending just as much time doing this for Windows as for Linux, well maybe not). This highlighted a vulnerability, which is frankly quite real and needs to be taken seriously and contemplated over time. The guys were jerks, yes. What they highlighted is real and a lot more serious than what this little stunt did.
- zamadatix 6y ago
  I think the article raised a good point: "One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. " How big/useful a revelation is it that you can show it's easy to break into someone's house while they are sleeping if it's well known the front door won't even stay shut.
  - kbenson 6y ago
    It's not that the front door won't stay shut, it's that different portals to the house seem to be locked or unlocked or just plain open sometimes at random intervals. There is benefit to an attacker to having a known ingress available on demand. There's a difference between a bug, a potentially exploitable bug, and an exploited bug. There's also a big difference between what's known and what's not yet known. Just because kernel developers are busy inadvertently introducing bugs doesn't mean that those bugs are all equally useful as an exploit. And that's before even considering that some bugs are easier to identify than others. A sophisticated adversary being able to get an exploitable bug into the kernel that they already have an exploit built for skips the discovery and exploit development phases, while also ensuring that the exploit delivers the type of access desired, rather than depending on luck. This is definitely something we should be thinking about.
draw_down 6y ago
All I know is, I don’t wanna hear anything about left-pad ever again.
ej14 6y ago
try
ComodoHacker 6y ago
>the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers So was the entire point of the paper false (or worse, lie)?
Ceezy 6y ago
> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. As an "average" dev I think the conclusion is totally unfair. Comparing a non intentional bug with intentional one(aka malware). I think Principle should matter and these people they violated the rules. And they should be morally shamed and legally sued. I certainly don't want to be mixed with them. Whatever people think of the quality of my code. I understand that's a lot of work and just from a code quality prospective that's the same. But for the community of millions open source projects that's a terrible message to send.
deleted 6y ago
[deleted]

462 points by chmaynard 6y ago

belinder 6y ago

So the paper is not being published? Then what was the whole point of the research

jasonjayr 6y ago
They were forced to retract the paper as a result of this debacle.
kjs3 6y ago
The point was to get a paper published. That's it.

endisneigh 6y ago

My take away from this affair is how we again and again overgeneralize. It never made any sense to blame UMN in general for an action taken by arguably only a single department, and even holding them culpable is a stretch (this is in response to some people in another thread saying no one from UMN should ever be able to contribute to the kernel ever again to teach them a lesson). It's not really surprising a bunch of academic-types were too far removed from open source etiquette - that removal is pretty much the source of the drama (this entire thing would've been avoided if a few key people were informed ahead of time). My other take away is that it seems social engineering still is the most powerful type. From this to the Twitter fiasco - it's worth trying to make your workflow resilient against social engineering indeed - by the authors own admission, the process leans a bit too much towards pre-established trust and credibility. Unfortunately that trust isn't immutable, nor is it everlasting so it's a spot that can be exploited.

sidr 6y ago
If the university doesn't review research methodologies that directly impact others (I'm not talking about societal impact of the work down the line), then they should be considered bad-faith actors. This is the equivalent of punishing a university for not having an IRB for human experiments . I assume individual members from UMN may still contribute without a UMN address. They just won't be given any special consideration (implicit or explicit) as belonging to a particular organization.
- detaro 6y ago
  By that standard, basically no university meets your threshold. (in other places the IRB might have decided differently, but also that's not extremely likely) Researchers are just not monitored that closely usually.
  - hn8788 6y ago
    They'd already complained to UMN about the research, and nothing was done about it. It wasn't just the IRB that allowed it to continue.
    - detaro 6y ago
      Is that the case? I hadn't seen anything conclusive that that actually had happened? (some people said the contacted the IRB, but presumably that was part of what triggered the IRB to look at it) But looking into this and clearly documenting it is part of what UMN needs to do.
      - hn8788 6y ago
        In the most recent email chain where they banned UMN, GKH said that they were going to have to complain to the university again. From what I understand, the IRB review was initiated by the researchers themselves after receiving backlash from the original paper.
    - cycomanic 6y ago
      What do you mean continued it. The research of submitting buggy patches had ended already (they even had a draft paper). The whole row started because one of the researchers submitted a patches from a (not very good apparently) in progress static analysis tool. The bad quality of the patch led to GKH accusing the submitter that they are continuing. As the article states this was not the case.
  - HarryHirsch 6y ago
    But researchers don't operate within a vacuum, research is a social effort. The faculty member and the graduate student who dreamt up this line of research have discussed it with others and they all thought it was a splendid idea.
namelessoracle 6y ago
Agree or disagree with whether it should have been done but blaming UMN was a social tactic to embarass the University so that UMN would apply pressure to the researcher and deal with them.
- infogulch 6y ago
  > social tactic This, but not derisively. Note that the university's IRB granted an exception for this behavior, and neither UMN nor the department responded with consideration for the concerns raised by the kernel team until after they banned the whole domain.
- mturmon 6y ago
  The social tactic could have been changed from "we will revert all recent patches originating from UMN" to "we are forced to review all recent patches originating from UMN, and to enforce stricter scrutiny of UMN patches going forward." Second is more honest and also applies social pressure.
  - hmfrh 6y ago
    The second option also doesn't result in any big negatives for UMN associated personnel because the kernel devs take on all the work of enforcing stricter scrutiny.
  - raegis 6y ago
    That sounds like a good first warning. But they persisted even after Greg KH complained to UMN and told them to stop. A more severe punishment for a second offense is needed, IMO.
kayodelycaon 6y ago
> It never made any sense to blame UMN in general for an action taken by arguably only a single department UMN is ultimately responsible for the actions of the people under their organization. This include oversight and dealing with the actions of those people when they have crossed lines.
- castlecrasher2 6y ago
  Agreed, and I'm stunned this is even in question.
einpoklum 6y ago
> It's not really surprising a bunch of academic-types were too far removed from open source etiquette Umm, there's etiquette in academia too you know... even FOSS etiquette in academia.
- shadowgovt 6y ago
  And that fact highlights the mistakes made here. A fellow researcher intentionally pushing bad data into a colleague's study as some kind of penetration test on the colleague's scientific methodology would be justifiably seen as betrayal, and a possibly bad faith betrayal at that since research grants are a finite resource. The researchers in the story appear to have failed to extrapolate that sort of collegial courtesy to the open source community maintaining Linux.
  - einpoklum 6y ago
    The researchers in this story acted unethically - as academics. I'm saying it's not the culture difference.

at_a_remove 6y ago

Twenty years ago, this incident would have been met with a "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." A decade back, "play stupid games, win stupid prizes" would have won out. Now, I think The Kids would say "Fuck around and find out" (this is often accompanied by a stencil of an open-mouthed alligator). No matter the form of the reaction, I am still left wondering at the proportions of disregard, hubris, naivete, and perhaps sheer lack of consideration of consequences that went into this whole affair. For the life of me I simply cannot imagine anyone patting me on the back and saying, "Good show on that paper, old boy! Smartly done!" Was there nobody in the whole group who had reservations? Were any expressed or were they simply hidden away? I am sincerely curious as to how it managed to get to this point.

defaultname 6y ago
I'll be the odd one out and say that I see nothing wrong with their study. There are much more skillful, much better resourced actors who can do what the UMN did much more discretely. I mean, the UMN flaws were egregious and blatantly obvious. They should have been met with ridicule at first glance. If they aren't (and they weren't), there are problems that need to be addressed. But there's a torch mob about this -- a very misled, and I would say foolish torch mob -- and as a result comments like mine will invariably be moderated down to invisible. I guess if we just brigade against some junior researchers it'll help defend the kernel from actually malicious actors...
- floatingatoll 6y ago
  If UMN’s ethics review(s) has approved this experiment in cooperation with Linus/Greg, there would not be anything to be outraged about. The outrage, and the core ethical violation, centers around intentionally wasting the time of others for selfish benefit without appropriate review and consent.
  - zajio1am 6y ago
    > If UMN’s ethics board has approved this experiment in cooperation with Linus/Greg, there would not be anything to be outraged about. I do not think that would help. This was done on public mailing list and deceptive behavior was also against third parties (other reviewers). I do not think Linus/Greg can give consent to that.

carbocation 6y ago

> The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence. To the contrary, my takeaway from these events is a further erosion of the credibility of Hanlon's razor.

edoceo 6y ago
the razor holds IMO. because this isn't adequately explained by incompetence alone. the crafty/sneaky approach has some hints of malice.
- carbocation 6y ago
  That is actually totally fair. But I will offer a quibble: having to focus on the "adequately" part makes the razor less interesting.
  - admax88q 6y ago
    But... it's there. Without the "adequately" its not Hanlon's razor, its random other razor that is probably less accurate.
hderms 6y ago
People jump to Hanlon's razor way too quickly. The mere knowledge that people are likely to brush off things as incompetence instead of malice is a potential tool in the hands of the malicious. Yes, all things being equal, it's better to err on the side of assuming someone didn't have malicious intent, but some people like to use it like a blunt instrument and the fact they do is dangerous in such a complex world. Additionally, it's incredibly biased in its application simply because only a good-natured person would be inclined to brush off malicious action as incompetence. Malicious actors would be unlikely to do the same.

jolux 6y ago

I am not terribly surprised to learn that code review processes for the kernel are not as stringent as they should be. However, I do wonder whether the kernel's defect rate is significantly different from that of NT or XNU, and whether the situation could be significantly improved. I thought there was large institutional investment in Linux kernel development, but if the existing developers are horribly overworked and stand no chance of properly reviewing every patch, even from existing contributors, clearly the project needs more resources. I'm glad that this situation has prompted reflection on these issues for kernel developers though. It seems like the best possible outcome.

lacker 6y ago

Key takeaway from this update: One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.

chmaynard 6y ago
Instead of submitting patches with known bugs, the UMN researcher could have done a retrospective study of patches from other kernel developers containing bugs that were later found and fixed. Not only was he acting in bad faith, he was stupid.
- hangonhn 6y ago
  There was also a high degree of arrogance on his part. That he thought his needs and priorities outweigh those of the much, much bigger community and/or that he doesn't need permission from anyone in charge of the codebase is just astounding.
- izgzhen 6y ago
  That is not considered high impact by the research community ;)
- xucheng 6y ago
  Alternatively, I think the research could be done in an isolated experiment environment among consented participants. For example, they could ask maintainers to review some set of patches outside the context of Linux kernel. They would then ask maintainers opinions on the said patches using some form of questionnaires. If the participants are well informed the nature of the experiments, there would not be any ethic concerns. For incentive, the researchers could pay for any maintainers willing to participate the experiments.
- cpeterso 6y ago
  The researcher also could have coordinated with Linux and other Linux leads, so they know which patches will be "bad". They all want the Linux review process to produce high quality code and could have suggested other ways to test the process.

adamrezich 6y ago

interesting that they admit that going forward, they don't really have the resources to fully vet all submitted patches to the degree necessary to prevent something like this from happening again. seems like, if nothing else, this has proven the Linux kernel as pretty vulnerable to similar, more malicious future attacks. there's no real easy solution to this problem

detaro 6y ago
That's not really news though, and IMHO one of the major points of criticism against the researchers: If what they did would have shown anything new or unsuspected it'd have been one thing, but they didn't, and could have shown the same with less impact.
- UncleMeat 6y ago
  The research was a little more compelling than that, since they did use an automated tool to find the partial vulns that they could sneakily upgrade to complete vulns. That is a little more interesting than introducing an entire complete vuln in a patch and hoping nobody notices. Still very unsurprising, but a little more interesting than how the work has been presented in media. I do also still believe that Oakland was incredibly foolish for accepting this work and that the PC has almost as much egg on their face as the researchers.

flowerbeater 6y ago

This is a reasonable and balanced analysis of the situation. In retrospect, it seems like the reversion of the 190 patches was an overreaction that ended up causing a lot of confusion: many people even on HN misinterpreted the comments on reversions to believe that bad patches were committed to the source tree or to stable. But besides the lesson that one ought not to be deceptive with submitting patches, is also the lesson that the kernel is not as well reviewed as one may hope and with some effort, it's certainly possible to add an undetected vulnerability. I think that's probably one thing that led to the drama, is that the fundamental trust and work of the kernel was attacked, and the maintainers felt the need to fight back to protect their reputation.

detaro 6y ago
I don't think the latter part is true, my impression is that the kernel people are very well aware of the limits of their review ability and don't pretend to be unfoolable.
- flowerbeater 6y ago
  There's a wide range of degrees between "unfoolable" and "can be done by a persistent student". I think the impression (at least my impression) used to be is that it was possible before but quite unlikely without state-level efforts, but now we understand a properly advised student can get most of their attempted vulnerabilities inserted.
  - detaro 6y ago
    The pure number of just regular bugs that aren't caught is already a good indicator that not much special effort is needed. (And "just a persistent student" isn't that little, given that the group also contributed regularly to the kernel, was studying its security, ... and thus quite familiar with the field, and the kind of people a nation state would employ for that)
- Mathnerd314 6y ago
  The harder part is probably fooling all of the static analysis tools that get run on the kernel, Coverity, Coccinelle, Smatch, and so forth.

maest 6y ago

> [LWN subscriber-only content] I'm guessing you weren't supposed to share this link?

swyx 6y ago
right below that it says "The following subscription-only content has been made available to you by an LWN subscriber." feature, not bug
- WA9ACE 6y ago
  I'm so very happy that's a feature, I subscribed to LWN a while back from reading some subscriber only links on HN.
janfoeh 6y ago
LWN links are intentionally shareable. See the "Welcome .." box at the top: > The following subscription-only content has been made available to you by an LWN subscriber.
deleted 6y ago
[deleted]
Diederich 6y ago
FYI: the owner of lwn.net is on record as being ok with people widely sharing subscriber only content links.
gwd 6y ago
When (as a subscriber) you make such a link, it says that if such links are "abused", the ability to make them may go away. Having the occasional article posted to HN seems to be OK with them (or they probably would have added a specific request not to post them to news aggregation sites). It's likely a wholesale "Free LWN for all" page with a weekly subscriber link to all the articles they're worried about.
woofie11 6y ago
Nope. LWN built the feature that subscribes can share links as a feature. If you subscribe, you can share. LWN is a very fair and ethical organization. This struck what felt to them (and to much of the community) as a good balance.

einpoklum 6y ago

> The corollary — also something we already knew — is that code going into the kernel is often not as well reviewed as we like to think. This may be true but not really a corollary of what happened. In fact, it seems there aren't the resources to determine how many of the patches are actually bad and should really be reverted.

toss1 6y ago

Key point: >>"kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands. They are, as a result, forced to rely on the trustworthiness of the developers who submit patches to them. The kernel development process is, arguably, barely sustainable when that trust is well placed; it will not hold together if incoming patches cannot, in general, be trusted. " Yet these UMN "researchers" deliberately chose to violate that trust. Are they so ethically clueless and arrogant that they didn't think to review the plan? Did they hold any kind of ethical review and pass it, or fail it and decide to proceed anyway? In any case, they've now alerted the entire world that the Linux dev process and OS dev processes in general are incredibly vulnerable to malicious actors. This vulnerability is also shown by another #1 HN story[1] [1] https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/ https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/

detaro 6y ago
How does the netlab link have anything to do with Linux development processes?
- toss1 6y ago
  >> "... a backdoor targeting Linux X64 systems, a family that has been around for at least 3 years." The point is that OS systems fundamentally depend on the trustworthiness of the contributors and the diliginece and bandwidth of the maintainers. Both are examples showing that the diligence and bandwidth is not infinite, and can be relatively easily overwhelmed or outmaneuvered. The UMN hack showed how easily the trust can be violated, and the netlab 3 year lifetime before discovery shows how easily flaws can stay hidden. The saying is "many eyes make shallow bugs". In an ideal case and with systems that are small relative to the body of people maintaining and actively scrutinizing it, that's true. The reality is that the scale of Linux and most OS is now well beyond the set of people scrutinizing it. How much source code did you review before you installed your latest build?
  - detaro 6y ago

MilnerRoute 6y ago

The thing that troubles me is how hundreds of good-faith patches came under suspicion. We can say that the researchers are entirely responsible for that as well -- for creating that need for suspicion. But I do wonder if we were too quick to also fall into a pattern of outrage and absolute rejection. This story went viral partly because it seemed much worse -- "And they're still submitting malicious patches to this day!" -- than it actually was.

bigwavedave 6y ago
I dunno, I think this is one case where outrage and rejection weren't too quick in coming. Let's say you're a software architect (dunno if you are or not). You hire four new software devs, two of them from Colorado State University, and you put the two from CSU on the same team. After a year, you find out one of them has been secretly working for CSU's cyber security research department and poisoning your product with patches that do nothing or subtly introduce bugs on purpose purely so their professor can write a research paper about your company's process. Naturally, you fire the developer and that leaves a bad taste in your mouth and CSU promises not to interfere again. Then you get suspicious and start checking the work of the other CSU dev more closely and find out they're submitting bad patches too! They claim that these bad patches were submitted because their experimental static code analyzer didn't find any issues with them. What conclusion should you reach?
- MilnerRoute 6y ago
  You should conclude "I don't know whether or not these patches were submitted in good faith." People sometimes submit bad patches. Not all of them are malicious. I don't think we've fully addressed or explored the scenario where a young, bright-eyed aspiring student coder does in fact make an innocent mistake. And then is accused of deliberate malicious sabotage. And large chunks of the internet also start condemning them for deliberate and malicious sabotage. What does that say about our community?
  - kuratkull 6y ago
    It's also important to understand the situation you are in - if you are the second CSU dev you got some extra due diligence to do. This is the real world, it's not fair.

woofie11 6y ago

... And I'd still like some update on the UMN IRB, which exempted this research. Graduate students will make mistakes, and as much as this was stupid, reckless, and unethical, graduate school is a time to learn. Professors will make mistakes. That's less excusable. IRBs are set up exactly to prevent stuff like this. My experience is they don't work, and UNM's clearly doesn't.

dekhn 6y ago
IRBs are set up to prevent costly lawsuits against the university, although they were originally intended to avoid human experimentation like the nazis (and many eugenecists and other doctors in the US) did.
- HarryHirsch 6y ago
  There are informal mechanisms as well. Someone will say to a hotheaded or greedy faculty member "look, you can't boot M off this patent, three years ago that other faculty member booted N off a few patents, there were issues, and then we had to pay tens of thousands for all the amended filings!"
- woofie11 6y ago
  This is false. IRBs are required under federal law, which did result from ethics violations, both by the Nazis, but just as much by US-based experiments, like the Stanford prison study, the Tuskegee Syphilis Study, Yale's Milgram experiment, US-based human radiation experiments, and so on. At some point, we decided we should have ethical research. That's designed to solve a broad set of problems. Most of this isn't about law suits but about federal research funding. There's little private right of action, but if you don't have research reviewed by an IRB, you can't get federal research grants. OMB requires an IRB. That said, universities are finding loopholes. A major one is for profs to do research on "private" time as "consulting." Lots of unethical research being done and published that way. Professors don't really have a clean split between work/life or work 40-hour weeks, so while perhaps this started out reasonable ("I'm consulting to Google"), right now, it's just a way to bypass IRBs. As a footnote: What's not widely recognized in the US yet were the close ties between Nazi research and US research, pre-war. A lot of the eugenics stuff was developed by the American scientific establishment.

notyourday 6y ago

The key take away, for me, has been that the Foundation that sent the demand letter does not have the balls to grant Stupid Prize to those that so diligently tried to win it. A good demand letter announcing the winning of the Stupid Prize would have been to tell the university that it would be banned until it: * fires the assistant professor * terminates all the students that participated with a note that should any of those students or a professor go to a different university that university would be banned as well. Had that price would have been awarded it would have definitely made into future ethics classes.

temp8964 6y ago

I totally agree this is a very balanced review of the affair. The fact that "kernel maintainers ... are overworked and do not have the time to properly review every patch that passes through their hands" is not a situation created by the group of researchers. If the Linux kernel is so crucial to the real world industry, and the kernel team is so distressed at their work, this is a problem need to be seriously addressed. Proactively punish the whole UMN does nothing to address the real issue here. If the team is so distressed at this tremendously important work and they constantly feel they are on the edge of collapsing, may be you really really really should ask for outside help and even demand more contributions from the big techs. Nobody should overwork, especially those work on something so crucial to the whole industry. Edit: I just read a line from the Rust Foundation page [1]: "Good software is built by happy, well-supported people." 1. https://foundation.rust-lang.org/ https://foundation.rust-lang.org/

josefx 6y ago
> is not a situation created by the group of researchers. As far as I got from various threads on the issue the university has been involved in at least two major time wasters: * Breaking the trust model and forcing the maintainers to revert all already accepted patches on suspicion alone * Running a primitive static code analysis tool that got overeager with correcting impossible bugs and not marking the generated patches as such. > Proactively punish the whole UMN does nothing to address the real issue here. Proactive? The universities review board signed off on that mess, there is nothing proactive about banning a group of bad actors after the fact.
- SiempreViernes 6y ago
  Proactive probable refers to also banning the 6700 staff, along with the 46000 students, that are not part of the research project from ever contributing.
  - monocasa 6y ago
    That staff and student body is governed by the same ethics board that allowed this to happen.

openasocket 6y ago

> the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question. Wait, so none of the maintainers were actually fooled by these hypocrite commits? In 2/3 the maintainers explicitly caught the use-after-free bug on their own, and in the third they had some unrelated feedback. Maybe I mis-read their paper, but they made it sound like if they hadn't told the maintainers "wait, don't merge this, it's bad" they would have introduced vulnerabilities into the kernel. But that isn't what happened at all! Again, maybe I mis-read the paper, but it seems like we can add dishonesty, if not outright fraud, to the list of problems with these researchers.

iudqnolq 6y ago
Possibly? It depends on whether you think every patch they submitted was part of the research. > Thus, one of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find. Actually, it wasn't all of them; he mentioned a list of 68 others requiring manual review because they do not revert easily. > Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel. > For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them. In others, the intended change was done poorly and will be reimplemented in a better way. And some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).

shp0ngle 6y ago

“It’s easier to ask for forgiveness than for permission”, huh?

kuratkull 6y ago
The older you are, the more you understand the importance of knowing this.

returningfory2 6y ago

HN meta point > The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence. This is exactly the comment I left on the original HN thread, which was downvoted [0]. I can understand the kernel maintainers being overwhelmed by the situation and jumping to the worst case interpretation, but interesting to see HN commenters doing the same, too. https://news.ycombinator.com/item?id=26890520 https://news.ycombinator.com/item?id=26890520

tester756 6y ago
HN went really emotional about this particular matter
- waiseristy 6y ago
  HN also often suffers the same fate as other social networking sites, where comments that don't align with masses get downvoted
raegis 6y ago
If I dropped by a UMN researcher's office and asked for 30 minutes of their time for something they consider unimportant, they could reasonably reply, "no, I'm too busy with research". Likewise, a kernel developer should not be forced to unwittingly waste their time. The "malice" here is that the researchers may consider their time more valuable than others. Incompetence is a separate thing. Lastly, kernel developers are naturally going to trust computer scientists at major universities. The researchers know this (subconsciously or not) and took advantage of it. Patches from smith@joeschmoe.com will automatically get more scrutiny.
- cycomanic 6y ago
  But that is not what happened. In the bug submission experiment they used Gmail addresses not their UMN addresses. The whole thing came up when one of the students (I think he was a graduate student working in the research group) submitted patches from his over eager static analysis tool using his uni address. So if anything the work from the uni adress received more scrutiny than the other patches.

dcow 6y ago

So, basically, Greg is kind of a jerk too. I mean I respect the dude for all the work he does but man his back and forth with an honest person and jump to ascribe malice looks pretty bad in this light. An apology might be in order.

tofuahdude 6y ago
What? Greg's open-source work was maliciously attacked by the exact same actor who then submits incompetent patch requests. I think he responded in a totally appropriate manner. He does not owe these people anything - and certainly not kindness after their track record.
- dcow 6y ago
  It wasn't the same person and it wasn't an attack. Read the LWN article. > The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.
  - tofuahdude 6y ago
    By "actor" I was referring to the institutionally untrustworthy UMN, but since you seem interested in splitting hairs, you should probably realize in doing so that Aditya Pakki === Aditya Pakki. Notice that Aditya is one of the signers of the apology letter: https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL... And that several of the identified vulnerabilities were tied to Aditya: https://lwn.net/ml/linux-kernel/YH+zwQgBBGUJdiVK@unreal/ https://lwn.net/ml/linux-kernel/YH+zwQgBBGUJdiVK@unreal/
    - re 6y ago

slaymaker1907 6y ago

I really think this whole thing would make for entertaining content on one of the YouTube drama channels. Overall, I thought the kernel team was right to be upset about being experimented on without consent, but the exchanges on both sides had some notable incidents of immaturity. I didn't think the attacks against the static analysis guy were totally justified. They were calling him an idiot for putting in an unnecessary null check. To be clear, he then also overreacted, and that really made me think that it only takes one side to start de-escalating things. The most disappointing response IMO was from the University itself. I didn't like how they deflected off the issue of why there was no IRB questioning of this. Just because human experimentation is narrowly defined federally doesn't mean you can't have higher standards.

shockeychap 6y ago

> Consider, for example, the 5.12 development cycle (a relatively small one), which added over 500,000 lines of code to the kernel over a period of ten weeks. The resources required to carefully review 500,000 lines of code would be immense, so many of those lines, unfortunately, received little more than a cursory looking-over before being merged. I am more than a little astounded that new functionality is being added to the kernel THAT fast.

dcow 6y ago

> They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them. ... kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands ...code going into the kernel is often not as well reviewed as we like to think. Sounds like there’s some room for improvement in the process of how lighter weight contributions are introduced, reviewed, and land in the kernel. Perhaps there is a technical solution that would help ease the load off maintainers and shift some of the burden to patch authors. — When I find myself in times of trouble / mother Mozilla speaks to me / whisper words of wisdom / don't use C. And in my hour of darkness / Rust is installed in my system tree / emitting tokens of wisdom / don't use C. And then the broken hearted people / maintaining kernel code agree / Rust's safety is the answer / don't use C. For though they may be parted / Rust will prevent Use After Fee / they will see the answer / don't use C. And when the code is cloudy / the borrow checker confronts me / thou shall specify reference lifetimes / don't use C. I wake up to the sound of safe code / not one vuln surrounding me / rust is in the kernel / no more C.

azinman2 6y ago
Rust doesn’t magically make your code bug free. The fixes/bugs you reference are highly unlikely to be all memory management related (eg use-after-free), and you can still do unsafe things in Rust even with memory.
- dcow 6y ago
  Of course you can. But it is much harder. I'm just having some fun. Anecdotally, Rust coerces you into writing sound code and really helps break some destructive habits that C breeds. I rarely need to debug Rust code and when I do the bugs are logic errors not memory errors. It's a noticeable difference. For lightweight contributions to the kernel and "peripheral" contributions (where some big company writes a massive messy driver because the market forces their hand.. not because they enjoy curating and actively helping to maintain linux), the type of discipline Rust enforces is invaluable. Also, what do you mean that Rust won't solve use after free? The whole point of the borrow checker is tracking and enforcing reference lifetimes in order to prevent using a pointer to memory that's been dropped from scope and no longer has an owner (has been freed). Sure it can't prevent all issues magically just yet (there are limitations) but it's a positive force in the right direction. Rust forces developers to do upfront what is usually relegated to careful code review. You're forced to think about the memory implications of your code. If the issue is that we can't thoroughly review the abundance of code submitted to the kernel, then e.g. requiring that, unless justified, new patches shall land in safe rust, seems like it would directly address the core issue that there aren't enough eyes on the code. Obviously it's more nuanced than that, there's existing code you can't just say "all new contributions must be rust".. the example is just illustrative. The existing proposal and work on carefully incorporating rust into the kernel is super awesome. And I'm excited!

cycomanic 6y ago

Apart from the understandable annoyance (anger) of being experimented on and the scandal that this somehow got approved by the UMN ethics board I did find the reaction to this somewhat interesting in that the kernel community was willing to immediately ban every one from UMN (a university of significant size) and investigate/revert all patches originating from UMN. In contrast I don't believe the reaction was anywhere near that strong when it came out that the NSA likely subverted a crypto standardisation process. Should the kernel community have reacted at least equally as strong (if they did and I'm just not aware of it please educate me).

ilamont 6y ago
From the UMN response signed by the Computer Science & Engineering department head and associate department head: The study was focused on understanding a system by identifying mechanisms through which security issues could be introduced in Linux software. Therefore, purely as a technical matter, this study did not qualify as “Human Subjects Research” and received no further scrutiny or oversight from the IRB. Importantly, even if one believed the study did involve human research subjects (perhaps due to the interactions and the incidental collection of email addresses), the study would clearly be exempt from IRB oversight pursuant to 45 CFR 46.104(D). In other words, the UMN IRB acted properly in this case. Full response: https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/view https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEi...
- cycomanic 6y ago
  Ok I guess this shows my ignorance on what constitutes human research (although I'm outside the US and definitions might be different here). I have to say this is a good response letter from the department.
anonydsfsfs 6y ago
> In contrast I don't believe the reaction was anywhere near that strong when it came out that the NSA likely subverted a crypto standardisation process It was pretty strong. There were many calls to remove the chair of the IETF CFRG group because of his association with the NSA: https://news.ycombinator.com/item?id=6942145 https://news.ycombinator.com/item?id=6942145

mjw1007 6y ago

I think that's an evenhanded writeup of the situation, but I also think the author should have mentioned in the article that he is himself a member of the technical advisory board whose actions he's reporting on (if https://www.linuxfoundation.org/en/about/technical-advisory-board/ https://www.linuxfoundation.org/en/about/technical-advisory-... is up to date).

Animats 6y ago

That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. That's the trouble with the one giant kernel architecture. Too much trusted code. The QNX microkernel barely changed from year to year, and the number of kernel bugs approached zero. It's only about 65K bytes of code. Yet it could do most of what Linux does.

gus_massa 6y ago
I think the problem is that the drivers are "inside" the kernel. Many of the dubious commits are there: > For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them.

truth_ 6y ago

> a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed. So they found a convenient scapegoat. I am not buying it.

occupy_paul_st 6y ago

> Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid Absolutely legendary

bumbledraven 6y ago

> 42 [UMN] patches [out of the 190 listed by Greg Kroah-Hartman] are still set to be pulled out of the kernel... some of the patches contained serious errors; these definitely needed to be reverted (and should not have been accepted in the first place).... all of those [42] patches were accepted by subsystem maintainers throughout the kernel, which is not a great result. Perhaps that is a more interesting outcome than the one that the original "hypocrite commit" researchers were looking for. They failed in their effort to deliberately insert bugs, but were able to inadvertently add dozens of them.

shockeychap 6y ago

> But if we cannot institutionalize a more careful process, we will continue to see a lot of bugs and it will not really matter whether they were inserted intentionally or not. I've always known this to be the case with many FOSS projects. (Remember the Heartbleed bug?) I'm a little surprised it's an issue for something this critical that's used by all of the world's largest technology companies, including all of FAANG.

parksy 6y ago

The situation has echoes of the scholars who a few years back submitted fake papers to journals, some of which passed peer review and were published. That was an attempt to backdoor the scientific method, really. I don't condone guerrilla penetration testing whether its on the Linux kernel or a science journal, and I am sure that the ethical implications will be subject to much outrage and debate for some time to come, but when it occurs and is successful it is concerning because if a small team of scholars can do it, so can anyone else. The inner workings of the Linux kernel maintenance has been kind of a black box for me for years, I just naively trust it works and my next update won't compromise my system, so it's concerning that this happened and will be following to see how this plays out.

antattack 6y ago

Given high number of buggy patches being accepted it seems kernel developers could use bug-bounty program.

Edman274 6y ago
I'll insert the bugs, and you can fix them, and we'll make bank together!

thamalama 6y ago

reminds me of another potentially critical mistake, https://mncomputinghistory.com/gopher-protocol/ https://mncomputinghistory.com/gopher-protocol/ 'According to Alberti, licensing “socially killed gopher.” Second, changes to internet hardware gradually made Gopher less appealing. As put by McCahill, Gopher was designed within “the limits of what the technology (at the time) could do.” It was deliberately text rich because images were slow to load on the comparatively slow modems of the early 1990s. The decision to prioritize text made Gopher relatively fast while the more image-oriented World Wide Web languished in slow speeds (the “World Wide Wait”). However, by 1994 improvements in modem technology had turned this asset into a liability.'

a_ghoul 6y ago

After doing some academic research I have a sour taste in my mouth for it, and this makes it even worse. Disappointing from UMN.

eximius 6y ago

What I want to know is whether the researchers had ever privately asked anyone in the chain of the kernel whether they would be willing to participate as a filter. Bad example for obvious reasons, but if Linus was given the usernames that would be submitting bad patches and forewarning of which ones were valid and which ones weren't, it could have been done such that the experiment was valid and the commits were not included in the final tree. I think it is a rather mild restriction to the experiment that a single person must be able to find an excuse to recuse themselves - as simple as "I don't have time to look at this, can someone else" would have worked.

feral 6y ago

I found the reaction to this surprising. When Security Researcher tell a company about a bug they've found, and the company reacts badly, this community is usually strongly in favor of the Security Researcher. The overworked corporate sysadmins don't get a lot of empathy. The assumption seems to be that that their software shouldn't have been vulnerable in the first place. Now here's a security researcher researching smuggling bugs into the Linux kernel. It probably should be secure, and probably should face scrutiny. People have tried snuggle bugs into it before.[0] So why is the opinion so strongly against the Security Researcher here? What's the big difference in principal? [0] https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/ https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-...

kstrauser 6y ago
My opinion: security researchers attack an organization’s products, like their code or website or services. UMN attacked the organization’s people to test their defenses. Lots of companies run bug bounty programs and thank you for finding vulnerabilities in their product. Humans don’t scale so well, though, and if you pester the hell out of a company’s office manager trying to social engineer them, that company is going to be super freaking annoyed at you. If UMN had analyzed the Linux code to find problems, then patched them, the kernel team would be happy. They didn’t. They spammed the human maintainers with a flood of patches and lied about why they were sending them. They conducted an impromptu and unanticipated phishing test, and you just don’t do that.
hyper_reality 6y ago
One big difference is explained in the article. The fact that code going into the kernel is not as secure as we might hope is already known to the open source community. Maintainers are overworked and none would be surprised if you told them that it would be possible to smuggle in backdoors. This is not a "bug", but an issue with time and resources, and because the researchers attempted to add bugs to demonstrate it just makes it worse. On the other hand, security researchers are finding vulnerabilities that weren't previously known. They've discovered specific exploitable bugs, rather than introducing new ones. Following disclosure, the company can patch the vulnerabilities and users will be safer. Which makes that a laudable thing to do.

re 6y ago

Some of the past related threads: “They introduce kernel bugs on purpose” - https://news.ycombinator.com/item?id=26887670 https://news.ycombinator.com/item?id=26887670 (1954 comments) UMN CS&E Statement on Linux Kernel Research - https://news.ycombinator.com/item?id=26895510 https://news.ycombinator.com/item?id=26895510 (320 comments) Open letter from researchers involved in the “hypocrite commit” debacle - https://news.ycombinator.com/item?id=26929470 https://news.ycombinator.com/item?id=26929470 (374 comments) Linux Foundation’s demands to the University of Minnesota - https://news.ycombinator.com/item?id=26955414 https://news.ycombinator.com/item?id=26955414 (168 comments)

staticassertion 6y ago

> That said, there are multiple definitions of "malice". To some of the developers involved, posting unverified patches from an experimental static-analysis tool without disclosing their nature is a malicious act. It is another form of experiment involving non-consenting humans. What an absurd statement. Malice implies intent ie: the goal was to do harm. There was never any malice - not in the hypocrite commits and certainly not in the static analysis findings.

darksaints 6y ago
Yes, malice requires intent, but intent can be interpreted differently too. If I shoot a gun repeatedly in the air for a celebration, I'm not intending to kill someone, but I am intending on acting in a way that has reckless disregard for human life. Malice is an appropriate interpretation of that kind of action, IMO.
- staticassertion 6y ago
  What? No, it isn't appropriate for that kind of action. That would be negligence. Malice is defined as deliberate harm.
  - darksaints 6y ago
    When you have a reasonable assurance that your actions will cause harm, and you do it anyway, that is virtually indistinguishable from intent to cause harm.
    - staticassertion 6y ago
      No, sorry, that's not how words work. Greg very clearly was implying malice, and intent, which there was none of. I don't care how bad you think the research was, you're welcome to call it negligent, but it was not malicious and it's totally absurd to try to change the definition of the word post-hoc.
      - 6y ago

rodgerd 6y ago

There is something amusing that the kernel maintainer most outraged by the whole thing is the guy who spends time changing the kernel to cripple OpenZFS.

ThinkBeat 6y ago

Linux is arguably one of the most important software projects on the planet right now. It is vital in so many aspects of society now, Android, AWS/AZure, IOT, routers, etc etc. It should be taken as a serious given that bad actors are working hard, with huge budgets to nefariously gain some advantage in the development of Linux. They will have far better engineers, much larger budges, and have been working on it for many years. I would imagine ever intelligence service on the planet would love to have obscure exploits embedded in the kernel. I can easily imagine a scenario where a single exploit was introduced over many months one tiny bit at a time. Each patch a fully working fix for unrelated problem. Fully Legit. But when they are all combined something wonderful happens. (for the nefarious player). This stunt was a few students who were not well funded nor were they uber kernel coders. Yet they had some success (depending on what you call success). I imagine the NSA has a team on this, with some exceedingly well skilled kernel coders working on embedding things, and I am sure they have a second team to find possibly implants by foreign services and so on. Had this been security researchers who managed to get changes into the WindowsNT kernel I think the reaction by the core Linux devs would have been different. (and yes I am 100% there are people spending just as much time doing this for Windows as for Linux, well maybe not). This highlighted a vulnerability, which is frankly quite real and needs to be taken seriously and contemplated over time. The guys were jerks, yes. What they highlighted is real and a lot more serious than what this little stunt did.

zamadatix 6y ago
I think the article raised a good point: "One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. " How big/useful a revelation is it that you can show it's easy to break into someone's house while they are sleeping if it's well known the front door won't even stay shut.
- kbenson 6y ago
  It's not that the front door won't stay shut, it's that different portals to the house seem to be locked or unlocked or just plain open sometimes at random intervals. There is benefit to an attacker to having a known ingress available on demand. There's a difference between a bug, a potentially exploitable bug, and an exploited bug. There's also a big difference between what's known and what's not yet known. Just because kernel developers are busy inadvertently introducing bugs doesn't mean that those bugs are all equally useful as an exploit. And that's before even considering that some bugs are easier to identify than others. A sophisticated adversary being able to get an exploitable bug into the kernel that they already have an exploit built for skips the discovery and exploit development phases, while also ensuring that the exploit delivers the type of access desired, rather than depending on luck. This is definitely something we should be thinking about.

draw_down 6y ago

All I know is, I don’t wanna hear anything about left-pad ever again.

ej14 6y ago

try

ComodoHacker 6y ago

>the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers So was the entire point of the paper false (or worse, lie)?

Ceezy 6y ago

> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. As an "average" dev I think the conclusion is totally unfair. Comparing a non intentional bug with intentional one(aka malware). I think Principle should matter and these people they violated the rules. And they should be morally shamed and legally sued. I certainly don't want to be mixed with them. Whatever people think of the quality of my code. I understand that's a lot of work and just from a code quality prospective that's the same. But for the community of millions open source projects that's a terrible message to send.

deleted 6y ago

[deleted]