8 ms·

I have the same questions. So far we have focused on how bad these "guys" are. Sure, they could have done it differently, etc. However, they proved a big point:

by mk89 6y ago

I have the same questions. So far we have focused on how bad these "guys" are. Sure, they could have done it differently, etc. However, they proved a big point: how "easy" it is to manipulate the most used piece of software on the planet. How to solve this "issue" without putting too much process around it? That's the challenge.

corty 6y ago
They proved nothing that wasn't already obvious. A malicious actor can get in vulnerabilities the same way a careless programmer can. Quick, call the press! And as for the solutions, their contribution is nil. No suggestions that haven't been suggested, tried and done or rejected a thousand times over.
- deleted 6y ago
  [deleted]
- dumpsterdiver 6y ago
  Agreed. So many security vulnerabilities have been created not by malicious actors, but by people who just weren't up to task. Buggy software and exhausted maintainers is nothing new.
  - dcow 6y ago
    What this proves to me is that perhaps lightweight contributions to the kernel should be done in safe languages that prevent memory leaks and with tooling that actively highlights memory safety issues like use after free. Broader rust adoption in the kernel cant come soon enough. I also consider Greg’s response just as much a test of UMN’s internal processes as the researcher’s attempt at testing kernel development processes. Hopefully there will be lessons learned on both sides and this benign incident makes the world better. Nobody was hurt here.
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - deleted 6y ago
      [deleted]
    - dumpsterdiver 6y ago
      I understand where you are coming from, and I agree that it's good that we are paying more attention to memory safety, but how would a memory safe language protect you from an intentionally malicious code commit? In order to enact their agenda they would need to have found a vulnerability in your logic (which isn't hard to do, usually). Memory safety does not prevent logic errors. > Nobody was hurt here. This is where you got me, because while it's clear to me that short-term damage has been done, in the long term I believe you are correct. I believe this event has made the world a safer place.
  - mk89 6y ago
    This is for me unrelated and even a little bit minimizing the issue here. The purpose of the research was probably to show how easy it is to manipulate the Linux kernel in bad faith. And they did it. What are they gonna do about it besides banning the university?
    - dumpsterdiver 5y ago
      I believe it comes down to having more eyes on the code. If a corporation relies upon open sourced code that has historically been written by unpaid developers, if I was that corportion, I would start paying people to vet that code.
- mk89 6y ago
  So you are just fine knowing that any random guy can sneak any code in the Linux kernel? Honestly, I was personally expecting a higher level of review and attention to such things, considering how used the product is. I don't want to look like the guy that doesn't appreciate what the OSS and FSF communities do everyday even unpaid. However this is unrelated. And probably this is what the researchers tried to prove (with unethical and wrong behavior).
  - kaba0 6y ago
    > So you are just fine knowing that any random guy can sneak any code in the Linux kernel? I mean, it is no surprise. It is even worse with proprietary software, because you are much less likely to be aware of your own college/employee. Hell, seeing that the actual impact is overblown in the paper, I think it is a really great percentage caught to be honest, assuming good faith from the contributor.
  - corty 6y ago
    I'm not fine with it. But those researchers are not helping at all. And also, if I had to pick between a somewhat inclusive mode of work where some rando can get code included at the slightly increased risk of including malicious code, and a tightly knit cabal of developers mistrusting all outsiders per default: I would pick the more open community. If you want more paranoia, go with OpenBSD. But even there some rando can get code submitted at times.
  - simiones 6y ago
    If you've ever done code review on a complex product, it should be quite obvious that the options are either to accept that sometimes bugs will make it in, or to commit once per week or so (not per person, one commit per week to the Linux kernel overall), once every possible test has been run on that commit.
    - mk89 6y ago
      I am not sure if these are the only options we have here. Did you see the list of commits that this bunch of guys sneaked in? It's quite big, it's not just 1-2. A smart attacker could have done 1 commit per month and would have been totally fine. All they needed apparently was a "good" domain name in their email. This is what I think is the root of the problem.
rualca 6y ago
> However, they proved a big point: how "easy" it is to manipulate the most used piece of software on the planet. What? Are you actually trying to argue that "researchers" proved that code reviews don't have a 100% success rate in picking up bugs and errors? Specially when code is pushed in bad faith? I mean, think about that for a minute. There are official competitive events to sneak malicious code that are already decades old and going strong[1]. Sneaking vulnerabilities through code reviews is a competitive sport. Are we supposed to feign surprise now? [1] https://en.wikipedia.org/wiki/Underhanded_C_Contest https://en.wikipedia.org/wiki/Underhanded_C_Contest
- mk89 6y ago
  Bug bounties are a different beast. Here we are talking about a bunch of guys who deliberately put stuff into your next kernel release because they come from an important university, or whatever other reason. One of the reviewers in the thread admitted that they need to pay more attention to code reviews. That sounds to me like a good first step towards solving this issue. Is that enough, though? It's an unsolvable problem, but is the current solution enough?
  - rualca 6y ago
    > Bug bounties are a different beast. Bug bounties are more than a different beast: they are a strawman. Sneaking vulnerabilities through a code review is even a competitive sport, and it has zero to do with bug bounties.
    - mk89 6y ago
      Sorry I think I didn't understand/read correctly what it was about. It's just f** brilliant! :)
zxzax 6y ago
What's next, will they prove how easy it is to break into kernel developers' houses and rob them? Or prove how easy it is to physically assault kernel developers by punching them in the face at conferences? Or prove how easy it is to manipulate kernel developers to lose their life savings investing in cryptocurrency? You can count me out of those... Sarcasm aside, pentesting/redteaming is only ethical if the target consents to it! Please don't try to prove your point the way these researchers have.
- nsonha 6y ago
  Just playing devil advocate here, the surprising factor does play into it. No bad actor will ever give you heads-up. If the researcher has sent these patches under a different identity, that would be just like how malice contributions appear. The maintainers won't assume malice, waste a bunch of time communicating with the bad actor, and may NOT revert their previous potentially harmful contribution.
  - newswasboring 6y ago
    > the surprising factor does play into it. No bad actor will ever give you heads-up. I too thought like this till yesterday. Then someone made me realize thats not how getting consent works in these situations. You take consent from higher up the chain, not the people doing the work. So Greg Kroah-Hartmancould could have been consulted, as he would not be personally reviewing this stuff. This would also give you a chance to understand how the release process works. You also have an advantage over the bad actors because they would be studying the process from outside.
    - nsonha 6y ago
      it's not simple like that, if Greg doesn't do the work of review then who gives him the authority to consent on behalf of others?
      - newswasboring 6y ago
        I see what you are saying. But he is also sort of the director to this whole thing. The research question itself is worthwhile and I don't think if it was done properly this much time would be wasted. All they have to prove is that it will pass few code reviews. That's a few man hours and I really don't think people will be mad about that. This whole fiasco is about the scale of man hours wasted both because they repeatedly made these "attacks" and because this thing slipped into stable code. Both would be avoided in this scheme. But I would like to put in a disclaimer that before getting to that point they could have done so many other things. Review the publicly available review processes, see how security bugs get introduced by accident and see if that can be easily done by a bad actor, etc.

by mk89 6y ago

corty 6y ago

They proved nothing that wasn't already obvious. A malicious actor can get in vulnerabilities the same way a careless programmer can. Quick, call the press! And as for the solutions, their contribution is nil. No suggestions that haven't been suggested, tried and done or rejected a thousand times over.

deleted 6y ago
[deleted]
dumpsterdiver 6y ago
Agreed. So many security vulnerabilities have been created not by malicious actors, but by people who just weren't up to task. Buggy software and exhausted maintainers is nothing new.
- dcow 6y ago
  What this proves to me is that perhaps lightweight contributions to the kernel should be done in safe languages that prevent memory leaks and with tooling that actively highlights memory safety issues like use after free. Broader rust adoption in the kernel cant come soon enough. I also consider Greg’s response just as much a test of UMN’s internal processes as the researcher’s attempt at testing kernel development processes. Hopefully there will be lessons learned on both sides and this benign incident makes the world better. Nobody was hurt here.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
  - dumpsterdiver 6y ago
    I understand where you are coming from, and I agree that it's good that we are paying more attention to memory safety, but how would a memory safe language protect you from an intentionally malicious code commit? In order to enact their agenda they would need to have found a vulnerability in your logic (which isn't hard to do, usually). Memory safety does not prevent logic errors. > Nobody was hurt here. This is where you got me, because while it's clear to me that short-term damage has been done, in the long term I believe you are correct. I believe this event has made the world a safer place.
- mk89 6y ago
  This is for me unrelated and even a little bit minimizing the issue here. The purpose of the research was probably to show how easy it is to manipulate the Linux kernel in bad faith. And they did it. What are they gonna do about it besides banning the university?
  - dumpsterdiver 5y ago
    I believe it comes down to having more eyes on the code. If a corporation relies upon open sourced code that has historically been written by unpaid developers, if I was that corportion, I would start paying people to vet that code.
mk89 6y ago
So you are just fine knowing that any random guy can sneak any code in the Linux kernel? Honestly, I was personally expecting a higher level of review and attention to such things, considering how used the product is. I don't want to look like the guy that doesn't appreciate what the OSS and FSF communities do everyday even unpaid. However this is unrelated. And probably this is what the researchers tried to prove (with unethical and wrong behavior).
- kaba0 6y ago
  > So you are just fine knowing that any random guy can sneak any code in the Linux kernel? I mean, it is no surprise. It is even worse with proprietary software, because you are much less likely to be aware of your own college/employee. Hell, seeing that the actual impact is overblown in the paper, I think it is a really great percentage caught to be honest, assuming good faith from the contributor.
- corty 6y ago
  I'm not fine with it. But those researchers are not helping at all. And also, if I had to pick between a somewhat inclusive mode of work where some rando can get code included at the slightly increased risk of including malicious code, and a tightly knit cabal of developers mistrusting all outsiders per default: I would pick the more open community. If you want more paranoia, go with OpenBSD. But even there some rando can get code submitted at times.
- simiones 6y ago
  If you've ever done code review on a complex product, it should be quite obvious that the options are either to accept that sometimes bugs will make it in, or to commit once per week or so (not per person, one commit per week to the Linux kernel overall), once every possible test has been run on that commit.
  - mk89 6y ago
    I am not sure if these are the only options we have here. Did you see the list of commits that this bunch of guys sneaked in? It's quite big, it's not just 1-2. A smart attacker could have done 1 commit per month and would have been totally fine. All they needed apparently was a "good" domain name in their email. This is what I think is the root of the problem.

rualca 6y ago

> However, they proved a big point: how "easy" it is to manipulate the most used piece of software on the planet. What? Are you actually trying to argue that "researchers" proved that code reviews don't have a 100% success rate in picking up bugs and errors? Specially when code is pushed in bad faith? I mean, think about that for a minute. There are official competitive events to sneak malicious code that are already decades old and going strong[1]. Sneaking vulnerabilities through code reviews is a competitive sport. Are we supposed to feign surprise now? [1] https://en.wikipedia.org/wiki/Underhanded_C_Contest https://en.wikipedia.org/wiki/Underhanded_C_Contest

mk89 6y ago
Bug bounties are a different beast. Here we are talking about a bunch of guys who deliberately put stuff into your next kernel release because they come from an important university, or whatever other reason. One of the reviewers in the thread admitted that they need to pay more attention to code reviews. That sounds to me like a good first step towards solving this issue. Is that enough, though? It's an unsolvable problem, but is the current solution enough?
- rualca 6y ago
  > Bug bounties are a different beast. Bug bounties are more than a different beast: they are a strawman. Sneaking vulnerabilities through a code review is even a competitive sport, and it has zero to do with bug bounties.
  - mk89 6y ago
    Sorry I think I didn't understand/read correctly what it was about. It's just f** brilliant! :)

zxzax 6y ago

What's next, will they prove how easy it is to break into kernel developers' houses and rob them? Or prove how easy it is to physically assault kernel developers by punching them in the face at conferences? Or prove how easy it is to manipulate kernel developers to lose their life savings investing in cryptocurrency? You can count me out of those... Sarcasm aside, pentesting/redteaming is only ethical if the target consents to it! Please don't try to prove your point the way these researchers have.

nsonha 6y ago
Just playing devil advocate here, the surprising factor does play into it. No bad actor will ever give you heads-up. If the researcher has sent these patches under a different identity, that would be just like how malice contributions appear. The maintainers won't assume malice, waste a bunch of time communicating with the bad actor, and may NOT revert their previous potentially harmful contribution.
- newswasboring 6y ago
  > the surprising factor does play into it. No bad actor will ever give you heads-up. I too thought like this till yesterday. Then someone made me realize thats not how getting consent works in these situations. You take consent from higher up the chain, not the people doing the work. So Greg Kroah-Hartmancould could have been consulted, as he would not be personally reviewing this stuff. This would also give you a chance to understand how the release process works. You also have an advantage over the bad actors because they would be studying the process from outside.
  - nsonha 6y ago
    it's not simple like that, if Greg doesn't do the work of review then who gives him the authority to consent on behalf of others?
    - newswasboring 6y ago
      I see what you are saying. But he is also sort of the director to this whole thing. The research question itself is worthwhile and I don't think if it was done properly this much time would be wasted. All they have to prove is that it will pass few code reviews. That's a few man hours and I really don't think people will be mad about that. This whole fiasco is about the scale of man hours wasted both because they repeatedly made these "attacks" and because this thing slipped into stable code. Both would be avoided in this scheme. But I would like to put in a disclaimer that before getting to that point they could have done so many other things. Review the publicly available review processes, see how security bugs get introduced by accident and see if that can be easily done by a bad actor, etc.