5 ms·

> We send the emails to the Linux communityand seek their feedback. That's not really what they did. They sent the patches, the patches where either

> We send the emails to the Linux communityand seek their feedback. That's not really what they did. They sent the patches, the patches where either merged or rejected. And they never let anybody knew that they had introduced security vulnerabilities on the kernel on purpose until they got caught and people started reverting all the patches from their university and banned the whole university.

duncaen 5y ago
This is not what happened according to them: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... > (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.
- tecleandor 5y ago
  It'd be great if they pointed to those "please don't merge" messages on the mailing list or anywhere. Seems like there are some patches already on stable trees [1], so they're either lying, or they didn't care if those "don't merge" messages made anybody react to them. 1 - https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3NcPu=17qyVyEEtVMVR_g51Ma6Q@mail.gmail.com/ https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N...
  - treesknees 5y ago
    The paper doesn't cite specific commits used. It's possible that any of the commits in stable are actually good commits and not part of the experiment. I support the ban/revert, I'm just pointing out there's a 3rd option you didn't touch on.
    - coriny 5y ago
      Patches with built-in bugs made it to stable: https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/.
      - bmcahren 5y ago
        Here's the commit specifically identified by Leon Romanovsky as having a "built-in bug" https://github.com/torvalds/linux/commit/8e949363f017 https://github.com/torvalds/linux/commit/8e949363f017
        rigden33 5y ago
        That commit is from Aditya Pakki who I don't believe is affiliated with the paper in question, whose only authors are Qiushi Wu, and Kangjie Lu.
        computershit 5y ago
        Aditya Pakki is an RA under Kangjie Lu.
        rurban 5y ago
        We have 4 people, with the students Quishu Wu and Aditya Pakki intruducing the faulty patches, and the 2 others, Prof Kangjie Lu and Ass.Prof Wengwen Wang patching vulnerabilities in the same area. Banning the leader seems ok to me, even if he produced some good fixes and SW to detect it. The only question is Wang who is now in Georgia, and was never caught. Maybe he left Lu at umn because of his questionable ethics.
        bombcar 5y ago
        At least one of Wang’s patches has been double reviewed and the reversion NACK’d - in other words it was a good patch.
  - corty 5y ago
    Also, they are talking of three cases. However, the list of patches to be reverted by gregkh is far longer than three, more than a hundred. Most of the first batch look sufficiently similar that I would guess all of them are part of this "research". So the difference in numbers alone points to them most probably lying.
- finnthehuman 5y ago
  I was more ambivalent about their "research" until I read that "clarification." It's weaselly bullshit. >> The work taints the relationship between academia and industry > We are very sorry to hear this concern. This is really not what we expected, and we strongly believe it is caused by misunderstandings Yeah, misunderstandings by the university that anyone, ever, in any line of endeavor would be happy to be purposely fucked with as long as the perpetrator eventually claims it's for a good cause. In this case the cause isn't even good, they're proving the jaw-droppingly obvious.
  - rualca 5y ago
    Even their choice of wording ("We are very sorry to hear this concern.") is the blend of word fuckery that conveys the idea they care nothing about what they did or why it negatively affected others.
  - PeterisP 5y ago
    The first step of an apology is admitting the misdeed. Here they are explicitly not acknowledging that what they did was wrong, they are still asserting that this was a misunderstanding.
  - dwild 5y ago
    > they're proving the jaw-droppingly obvious. Yet we do nothing about it? I wouldn't call that jaw-droppingly obvious, if anything, without this, I'm pretty sure that anyone would argue that it would be caught way before making it way into stable.
    - rurp 5y ago
      I've literally never come across an open source project that was thought to have a bullet proof review process or had a lack of people making criticisms. What they do almost universally lack is enough people making positive contributions (in time, money, or both). This "research" falls squarely into the former category and burns resources that could have been spent on the latter.
  - HackOfAllTrades 5y ago
- Apofis 5y ago
  This is zero percent different from a bad actor and hopefully criminal. I think a lot of maintainers work for large corporations like Microsoft, Oracle, Ubuntu, Red Hat, etc... I think these guys really stepped in it.
incrudible 5y ago
> And they never let anybody knew that they had introduced security vulnerabilities on the kernel on purpose... Yes, that's the whole point! The real malicious actors aren't going to notify anyone that they're injecting vulnerabilities either. They may be plants at reputable companies, and they'll make it look like an "honest mistake". Had this not been caught, it would've exposed a major flaw in the process. > ...until they got caught and people started reverting all the patches from their university and banned the whole university. Either these patches are valid fixes, in which case they should remain, or they are intentional vulnerabilities, in which case they should've already been reviewed and rejected. Reverting and reviewing them "at a later date" just makes me question the process. If they haven't been reviewed properly yet, it's better to do it now instead of messing around with reverts.
- simiones 5y ago
  This reminds me of that story about Go Daddy sending everyone "training phishing emails" announcing that they had received a company bonus - with the explanation that this is ok because it is a realistic pretext that real phishing may use. While true, it's simply not acceptable to abuse trust in this way. It causes real emotional harm to real humans, and while it also may produce some benefits, those do not outweigh the harms. Just because malicious actors don't care about the harms shouldn't mean that ethical people shouldn't either.
  - incrudible 5y ago
    This isn't some employer-employee trust relationship. The whole point of the test is that you can't trust a patch just because it's from some university or some major company.
    - simiones 5y ago
      The vast majority of patches are not malicious. Sending a malicious patch (one that is known to introduce a vulnerability) is a malicious action. Sending a buggy patch that creates a vulnerability by accident is not a malicious action. Given the completely unavoidable limitations of the review and bug testing process, a maintainer has to react very differently when they have determined that a patch is malicious - all previous patches past from that same source (person or even organization) have to be either re-reviewed at a much higher standard or reverted indiscriminately; and any future patches have to be rejected outright. This puts a heavy burden on a maintainer, so intentionally creating this type of burden is a malicious action regardless of intent. Especially given that the intent was useless in the first place - everyone knows that patches can introduce vulnerabilities, either maliciously or by accident.
deleted 5y ago
[deleted]

duncaen 5y ago

This is not what happened according to them: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... > (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.

tecleandor 5y ago
It'd be great if they pointed to those "please don't merge" messages on the mailing list or anywhere. Seems like there are some patches already on stable trees [1], so they're either lying, or they didn't care if those "don't merge" messages made anybody react to them. 1 - https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3NcPu=17qyVyEEtVMVR_g51Ma6Q@mail.gmail.com/ https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N...
- treesknees 5y ago
  The paper doesn't cite specific commits used. It's possible that any of the commits in stable are actually good commits and not part of the experiment. I support the ban/revert, I'm just pointing out there's a 3rd option you didn't touch on.
  - coriny 5y ago
    Patches with built-in bugs made it to stable: https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/.
    - bmcahren 5y ago
      Here's the commit specifically identified by Leon Romanovsky as having a "built-in bug" https://github.com/torvalds/linux/commit/8e949363f017 https://github.com/torvalds/linux/commit/8e949363f017
      - rigden33 5y ago
        That commit is from Aditya Pakki who I don't believe is affiliated with the paper in question, whose only authors are Qiushi Wu, and Kangjie Lu.
        computershit 5y ago
        Aditya Pakki is an RA under Kangjie Lu.
        rurban 5y ago
        We have 4 people, with the students Quishu Wu and Aditya Pakki intruducing the faulty patches, and the 2 others, Prof Kangjie Lu and Ass.Prof Wengwen Wang patching vulnerabilities in the same area. Banning the leader seems ok to me, even if he produced some good fixes and SW to detect it. The only question is Wang who is now in Georgia, and was never caught. Maybe he left Lu at umn because of his questionable ethics.
        bombcar 5y ago
        At least one of Wang’s patches has been double reviewed and the reversion NACK’d - in other words it was a good patch.
- corty 5y ago
  Also, they are talking of three cases. However, the list of patches to be reverted by gregkh is far longer than three, more than a hundred. Most of the first batch look sufficiently similar that I would guess all of them are part of this "research". So the difference in numbers alone points to them most probably lying.
finnthehuman 5y ago
I was more ambivalent about their "research" until I read that "clarification." It's weaselly bullshit. >> The work taints the relationship between academia and industry > We are very sorry to hear this concern. This is really not what we expected, and we strongly believe it is caused by misunderstandings Yeah, misunderstandings by the university that anyone, ever, in any line of endeavor would be happy to be purposely fucked with as long as the perpetrator eventually claims it's for a good cause. In this case the cause isn't even good, they're proving the jaw-droppingly obvious.
- rualca 5y ago
  Even their choice of wording ("We are very sorry to hear this concern.") is the blend of word fuckery that conveys the idea they care nothing about what they did or why it negatively affected others.
- PeterisP 5y ago
  The first step of an apology is admitting the misdeed. Here they are explicitly not acknowledging that what they did was wrong, they are still asserting that this was a misunderstanding.
- dwild 5y ago
  > they're proving the jaw-droppingly obvious. Yet we do nothing about it? I wouldn't call that jaw-droppingly obvious, if anything, without this, I'm pretty sure that anyone would argue that it would be caught way before making it way into stable.
  - rurp 5y ago
    I've literally never come across an open source project that was thought to have a bullet proof review process or had a lack of people making criticisms. What they do almost universally lack is enough people making positive contributions (in time, money, or both). This "research" falls squarely into the former category and burns resources that could have been spent on the latter.
- HackOfAllTrades 5y ago
Apofis 5y ago
This is zero percent different from a bad actor and hopefully criminal. I think a lot of maintainers work for large corporations like Microsoft, Oracle, Ubuntu, Red Hat, etc... I think these guys really stepped in it.

incrudible 5y ago

> And they never let anybody knew that they had introduced security vulnerabilities on the kernel on purpose... Yes, that's the whole point! The real malicious actors aren't going to notify anyone that they're injecting vulnerabilities either. They may be plants at reputable companies, and they'll make it look like an "honest mistake". Had this not been caught, it would've exposed a major flaw in the process. > ...until they got caught and people started reverting all the patches from their university and banned the whole university. Either these patches are valid fixes, in which case they should remain, or they are intentional vulnerabilities, in which case they should've already been reviewed and rejected. Reverting and reviewing them "at a later date" just makes me question the process. If they haven't been reviewed properly yet, it's better to do it now instead of messing around with reverts.

simiones 5y ago
This reminds me of that story about Go Daddy sending everyone "training phishing emails" announcing that they had received a company bonus - with the explanation that this is ok because it is a realistic pretext that real phishing may use. While true, it's simply not acceptable to abuse trust in this way. It causes real emotional harm to real humans, and while it also may produce some benefits, those do not outweigh the harms. Just because malicious actors don't care about the harms shouldn't mean that ethical people shouldn't either.
- incrudible 5y ago
  This isn't some employer-employee trust relationship. The whole point of the test is that you can't trust a patch just because it's from some university or some major company.
  - simiones 5y ago
    The vast majority of patches are not malicious. Sending a malicious patch (one that is known to introduce a vulnerability) is a malicious action. Sending a buggy patch that creates a vulnerability by accident is not a malicious action. Given the completely unavoidable limitations of the review and bug testing process, a maintainer has to react very differently when they have determined that a patch is malicious - all previous patches past from that same source (person or even organization) have to be either re-reviewed at a much higher standard or reverted indiscriminately; and any future patches have to be rejected outright. This puts a heavy burden on a maintainer, so intentionally creating this type of burden is a malicious action regardless of intent. Especially given that the intent was useless in the first place - everyone knows that patches can introduce vulnerabilities, either maliciously or by accident.

deleted 5y ago

[deleted]