7 ms·

1) They identified vulnerabilities with a process 2) They contributed the correct code after showing the maintainer the security vulnerability they missed. 3)

1) They identified vulnerabilities with a process 2) They contributed the correct code after showing the maintainer the security vulnerability they missed. 3) Getting the consent of the people behind the process would invalidate the results.

waihtis 6y ago
Go hack a random organization without a vulnerability disclosure program in place and see how much goodwill you have. There is a very established best practice in how to do responsible disclosure and this is far from it.
- XorNot 6y ago
  Also by and large reputation is a good first step in a security process. While any USB stick might have malware on it if it's ever been out of your sight, that one you found in the parking lot is a much bigger problem.
- Avamander 6y ago
  Propose a way to test this without invalidating the results.
  - waihtis 6y ago
    1) Contact a single maintainer and explore feasibility of the study 2) Create a group of maintainers who know the experiment is going to happen, but leave a certain portion of the org out of it 3) Orchestrate it so that someone outside of the knowledge group approves one or more of these patches 4) Interfere before any further damage is done Besides, are you arguing that ends justify the means if the intent behind the research is valid?
    - bezout 6y ago
      It depends. Does creating a vaccine justify the death of some lab animals? Probably. Does creating supermen justify mutilating people physically and psychologically without their consent? Hell no. You can’t just ignore the context.
    - Avamander 6y ago
      > 1) Contact a single maintainer and explore feasibility of the study That has the risk that the contacted maintainer is later accused of collaborating with saboteurs or that they consult others. Either very awful or possibly invalidates results. > 2) Create a group of maintainers who know the experiment is going to happen, but leave a certain portion of the org out of it Assuming the leadership agrees and won't break confidentiality, which they might if the results could make them look bad. Results would be untrustworthy or potentially increase complacency. > 4) Interfere before any further damage is done That was done, was it not? > Besides, are you arguing that ends justify the means if the intent behind the research is valid? Linux users are lucky they got off this easy.
      - rincebrain 6y ago
        > That was done, was it not? The allegation being made on the mailing list is that some incorrect patches of theirs made it into git and even the stable trees. As there is not presently an enumeration of them, or which ones are alleged to be incorrect, I cannot state whether this is true. But that's the claim. edit: And looking at [1], they have a bunch of relatively tiny patches to a lot of subsystems, so depending on how narrowly gregkh means "rip it all out", this may be a big diff. edit 2: On rereading [2], I may have been incorrectly conflating the assertion about "patches containing deliberate bugs" with "patches that have been committed". Though if they're ripping everything out anyway, it appears they aren't drawing a distinction either... [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.15&qt=author&q=pakki001%40umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [2] - https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.c...
        rincebrain 6y ago
        Too late for the edit deadline, but [1] is a claim of an example patch that made it to stable with a deliberate bug. [1] - https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/
    - MaxBarraclough 6y ago
      Perhaps I'm missing something obvious, but what's the point of all this subterfuge in the first place? Couldn't they just look at the history of security vulnerabilities in the kernel, and analyze how long it took for them to be detected? What does it matter whether the contributor knew ahead of time that they were submitting insecure code? It's seems equivalent to vandalising Wikipedia to see how long it takes for someone to repair the damage you caused. There's no point doing this, you can just search Wikipedia's edits for corrections, and start your analysis from there.
      - waihtis 6y ago
        Ah, but youre missing the fact that discovered vulnerabilities are now trophies in the security industry. This is potentially gold in your CV.
      - TeMPOraL 6y ago
        > What does it matter whether the contributor knew ahead of time that they were submitting insecure code? It's a specific threat model they were exploring: a malicious actor introducing vulnerability on purpose. > Couldn't they just look at the history of security vulnerabilities in the kernel, and analyze how long it took for them to be detected? Perhaps they could. I guess it'd involve much more work, and could've yielded zero results - after all, I don't think there are any documented examples when a vulnerability was proven to have been introduced on purpose. > what's the point of all this subterfuge in the first place? Control over the experimental setup, which is important for validity of research. Notice how most research involves gathering up fresh subjects and controls - scientists don't chase around the world looking for people or objects that, by chance, already did the things they're testing for. They want fresh subjects to better account for possible confounders, and hopefully make the experiment reproducible. (Similarly, when chasing software bugs, you could analyze old crash dumps all day to try and identify a bug - and you may start with that - but you always want to eventually reproduce the bug yourself. Ultimately, "I can and did that" is always better than "looking at past data, I guess it could happen".) > It's seems equivalent to vandalising Wikipedia to see how long it takes for someone to repair the damage you caused. Honestly, I wouldn't object to that experiment either. It wouldn't do much harm (little additional vandalism doesn't matter on the margin, the base rate is already absurd), and could yield some social good. Part of the reason to have public research institutions is to allow researchers to do things that would be considered bad if done by random individual. Also note that both Wikipedia and Linux kernel are essentially infrastructure now. Running research like this against them makes sense, where running the same research against a random small site / OSS project wouldn't.
    - mahogany 6y ago
      > 3) Orchestrate it so that someone outside of the knowledge group approves one or more of these patches Isn't this part still experimenting on people without their consent? Why does one group of maintainers get to decide that you can experiment on another group?
      - waihtis 6y ago
        It is, but that is how security testing goes about in general (in the commercial world.) Of its application to research and ethics, I’m not much of an authority.
      - ncann 6y ago
        In general you try to obtain consent from their boss, so that if the people you pentested on complain you can point to their boss and say "Hey they agreed to it" and that will be the end of the story. In this case it's not clear who the "boss" is but something like the Linux Foundation would be a good start.
  - dcminter 6y ago
    1. Get permission 2. Submit patches from a cover identity.
  - occamrazor 6y ago
    If you can’t make an experiment without violating ethical standards, you simply don’t do it, you can’t use this as an excuse to violate ethical standards.
    - Avamander 6y ago
      Misplaced trust was broken, that's it. Linux users are incredibly lucky this was a research group and not an APT.
  - ProblemFactory 6y ago
    There doesn't have to be a way. Kernel maintainers are volunteering their time and effort to make Linux better, not to be entertaining test subjects for the researchers. Even if there is no ethical violation, they are justified to be annoyed at having their time wasted, and taking measures to discourage and prevent such malicious behaviour in the future.
    - Avamander 6y ago
      > There doesn't have to be a way. Given the importance of the Linux kernel, there has to be a way to make contributions safer. Some people even compare it to the "water supply" and others bring in "national security". > they are justified to be annoyed at having their time wasted, and taking measures to discourage and prevent such malicious behaviour in the future. "Oh no, think of the effort we have to spend at defending a critical piece of software!"
      - deleted 6y ago
        [deleted]
  - tetha 6y ago
    In every commercial pentest I have been in, you have 1-2 usually senior employees on the blue team in the know. They have the job to stop employees from going to far on defense, as well as stop the pentesters from going too far. The rest of the team stays in the dark to test their response and observation. In this case, in my opinion, a small set of maintainers and linus as "management" would have to be in the know to e.g. stop a merge of such a patch once it was accepted by someone in the dark.
nicklecompte 6y ago
> 3) Getting the consent of the people behind the process would invalidate the results. This has not been a valid excuse since the 1950s. Scientists are not allowed to ignore basic ethics because they want to discover something. Deliberately introducing bugs into any open source project is plainly unethical; doing so in the Linux kernel is borderline malicious.
- bezout 6y ago
  We should ban A/B testing then. Google didn’t tell me they were using me to understand which link color is more profitable for them. There are experiments and experiments. Apart from the fact that they provided the fix right away, they didn’t do anyone harm. And, by the way, it’s their job. Maintainers must approve patches after they ensured that the patch is fine. It’s okay to do mistakes, but don’t tell me “you’re wasting my time” after I showed you that maybe there’s something wrong with the process. If anything, you should thank me and review the process. If your excuse is “you knew the patch was vulnerable”, then how are you going to defend the project from bad actors?
  - wccrawford 6y ago
    Actually, I think participants in an A/B test should be informed of it. I think people should be informed when market research is being done on them. For situations where they are already invested in the situation, it should be optional. For other situations, such as new customer acquisition, the person would have the option of simply leaving the site to avoid it. But either way, they should be informed.
  - corty 6y ago
    > they didn’t do anyone harm. Several of the patches are claimed to have landed in stable. Also, distributions and others (like the grsecurity people) pick up lkml patches that are not included in stable but might have security benefits. So even just publishing such a patch is harmful. Also, fixes were only provided to the maintainers privately as it seems, and unsuccessfully. Or not at all. > If your excuse is “you knew the patch was vulnerable”, then how are you going to defend the project from bad actors? Exactly the same way as without that "research". If you try to pry open my car door, I'll drag you to the next police station. "I'm just researching the security of car doors" won't help you.
arcatek 6y ago
Getting specific consent from the project leads is entirely doable, and would have avoided most of the concerns.
- Avamander 6y ago
  It really wouldn't have and would've made the patches not pass all levels of review.
  - arcatek 6y ago
    How do you think social engineering audits work? You first coordinate with the top layer (in private, of course) and only after getting their agreement do you start your tests. This isn't any different.
    - Avamander 6y ago
      > You first coordinate with the top layer (in private, of course) and only after getting their agreement do you start your tests. The highest level is what had to be tested as well, or do you imagine only consulting Linus? Do you think that wouldn't've gotten him lynched?
twic 6y ago
You're right, and it is depressing how negative the reaction has been here. This work is the technical equivalent of "Sokalling", and it is a good and necessary thing. The thing that people should be upset about is that such an important open source project so easily accepts patches which introduce security vulnerabilities. Forget the researchers for a moment - if it is this easy, you can be certain that malicious actors are also doing it. The only difference is that they are not then disclosing that they have done so! The Linux maintainers should be grateful that researchers are doing this, and researchers should be doing it to every significant open source project.
- anonymousab 6y ago
  > The thing that people should be upset about is that such an important open source project so easily accepts patches which introduce security vulnerabilities They were trusting of contributors to not be malicious, and in particular, were trusting of a university to not be wholly malicious. Sure, there is a possible threat model where they would need to be suspicious of entire universities. But in general, human projects will operate under some level of basic trust, with some sort of means to establish that trust. To be able to actually get anything done; you cannot perfectly formally review everything with finite human resources. I don't see where they went wrong with any of that here. There's also the very simple fact that responding to an incident is also a part of the security process, and broadly banning a group whole-cloth will be more secure than not. So both them and you are getting what you want it of it - more of the process to research, and more security. If the changes didn't make it out to production systems, then it seems like the process worked? Even if some of it was due to admissions that would not happen with truly malicious actors, so too were the patches accepted because the actors were reasonably trusted.
  - twic 6y ago
    The Linux project absolutely cannot trust contributors to not be malicious. If they are doing that, then this work has successfully exposed a risk.
    - 6y ago

waihtis 6y ago

Go hack a random organization without a vulnerability disclosure program in place and see how much goodwill you have. There is a very established best practice in how to do responsible disclosure and this is far from it.

XorNot 6y ago
Also by and large reputation is a good first step in a security process. While any USB stick might have malware on it if it's ever been out of your sight, that one you found in the parking lot is a much bigger problem.
Avamander 6y ago
Propose a way to test this without invalidating the results.
- waihtis 6y ago
  1) Contact a single maintainer and explore feasibility of the study 2) Create a group of maintainers who know the experiment is going to happen, but leave a certain portion of the org out of it 3) Orchestrate it so that someone outside of the knowledge group approves one or more of these patches 4) Interfere before any further damage is done Besides, are you arguing that ends justify the means if the intent behind the research is valid?
  - bezout 6y ago
    It depends. Does creating a vaccine justify the death of some lab animals? Probably. Does creating supermen justify mutilating people physically and psychologically without their consent? Hell no. You can’t just ignore the context.
  - Avamander 6y ago
    > 1) Contact a single maintainer and explore feasibility of the study That has the risk that the contacted maintainer is later accused of collaborating with saboteurs or that they consult others. Either very awful or possibly invalidates results. > 2) Create a group of maintainers who know the experiment is going to happen, but leave a certain portion of the org out of it Assuming the leadership agrees and won't break confidentiality, which they might if the results could make them look bad. Results would be untrustworthy or potentially increase complacency. > 4) Interfere before any further damage is done That was done, was it not? > Besides, are you arguing that ends justify the means if the intent behind the research is valid? Linux users are lucky they got off this easy.
    - rincebrain 6y ago
      > That was done, was it not? The allegation being made on the mailing list is that some incorrect patches of theirs made it into git and even the stable trees. As there is not presently an enumeration of them, or which ones are alleged to be incorrect, I cannot state whether this is true. But that's the claim. edit: And looking at [1], they have a bunch of relatively tiny patches to a lot of subsystems, so depending on how narrowly gregkh means "rip it all out", this may be a big diff. edit 2: On rereading [2], I may have been incorrectly conflating the assertion about "patches containing deliberate bugs" with "patches that have been committed". Though if they're ripping everything out anyway, it appears they aren't drawing a distinction either... [1] - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.11.15&qt=author&q=pakki001%40umn.edu https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux... [2] - https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.c...
      - rincebrain 6y ago
        Too late for the edit deadline, but [1] is a claim of an example patch that made it to stable with a deliberate bug. [1] - https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/ https://lore.kernel.org/linux-nfs/YIAta3cRl8mk%2FRkH@unreal/
  - MaxBarraclough 6y ago
    Perhaps I'm missing something obvious, but what's the point of all this subterfuge in the first place? Couldn't they just look at the history of security vulnerabilities in the kernel, and analyze how long it took for them to be detected? What does it matter whether the contributor knew ahead of time that they were submitting insecure code? It's seems equivalent to vandalising Wikipedia to see how long it takes for someone to repair the damage you caused. There's no point doing this, you can just search Wikipedia's edits for corrections, and start your analysis from there.
    - waihtis 6y ago
      Ah, but youre missing the fact that discovered vulnerabilities are now trophies in the security industry. This is potentially gold in your CV.
    - TeMPOraL 6y ago
      > What does it matter whether the contributor knew ahead of time that they were submitting insecure code? It's a specific threat model they were exploring: a malicious actor introducing vulnerability on purpose. > Couldn't they just look at the history of security vulnerabilities in the kernel, and analyze how long it took for them to be detected? Perhaps they could. I guess it'd involve much more work, and could've yielded zero results - after all, I don't think there are any documented examples when a vulnerability was proven to have been introduced on purpose. > what's the point of all this subterfuge in the first place? Control over the experimental setup, which is important for validity of research. Notice how most research involves gathering up fresh subjects and controls - scientists don't chase around the world looking for people or objects that, by chance, already did the things they're testing for. They want fresh subjects to better account for possible confounders, and hopefully make the experiment reproducible. (Similarly, when chasing software bugs, you could analyze old crash dumps all day to try and identify a bug - and you may start with that - but you always want to eventually reproduce the bug yourself. Ultimately, "I can and did that" is always better than "looking at past data, I guess it could happen".) > It's seems equivalent to vandalising Wikipedia to see how long it takes for someone to repair the damage you caused. Honestly, I wouldn't object to that experiment either. It wouldn't do much harm (little additional vandalism doesn't matter on the margin, the base rate is already absurd), and could yield some social good. Part of the reason to have public research institutions is to allow researchers to do things that would be considered bad if done by random individual. Also note that both Wikipedia and Linux kernel are essentially infrastructure now. Running research like this against them makes sense, where running the same research against a random small site / OSS project wouldn't.
  - mahogany 6y ago
    > 3) Orchestrate it so that someone outside of the knowledge group approves one or more of these patches Isn't this part still experimenting on people without their consent? Why does one group of maintainers get to decide that you can experiment on another group?
    - waihtis 6y ago
      It is, but that is how security testing goes about in general (in the commercial world.) Of its application to research and ethics, I’m not much of an authority.
    - ncann 6y ago
      In general you try to obtain consent from their boss, so that if the people you pentested on complain you can point to their boss and say "Hey they agreed to it" and that will be the end of the story. In this case it's not clear who the "boss" is but something like the Linux Foundation would be a good start.
- dcminter 6y ago
  1. Get permission 2. Submit patches from a cover identity.
- occamrazor 6y ago
  If you can’t make an experiment without violating ethical standards, you simply don’t do it, you can’t use this as an excuse to violate ethical standards.
  - Avamander 6y ago
    Misplaced trust was broken, that's it. Linux users are incredibly lucky this was a research group and not an APT.
- ProblemFactory 6y ago
  There doesn't have to be a way. Kernel maintainers are volunteering their time and effort to make Linux better, not to be entertaining test subjects for the researchers. Even if there is no ethical violation, they are justified to be annoyed at having their time wasted, and taking measures to discourage and prevent such malicious behaviour in the future.
  - Avamander 6y ago
    > There doesn't have to be a way. Given the importance of the Linux kernel, there has to be a way to make contributions safer. Some people even compare it to the "water supply" and others bring in "national security". > they are justified to be annoyed at having their time wasted, and taking measures to discourage and prevent such malicious behaviour in the future. "Oh no, think of the effort we have to spend at defending a critical piece of software!"
    - deleted 6y ago
      [deleted]
- tetha 6y ago
  In every commercial pentest I have been in, you have 1-2 usually senior employees on the blue team in the know. They have the job to stop employees from going to far on defense, as well as stop the pentesters from going too far. The rest of the team stays in the dark to test their response and observation. In this case, in my opinion, a small set of maintainers and linus as "management" would have to be in the know to e.g. stop a merge of such a patch once it was accepted by someone in the dark.

nicklecompte 6y ago

> 3) Getting the consent of the people behind the process would invalidate the results. This has not been a valid excuse since the 1950s. Scientists are not allowed to ignore basic ethics because they want to discover something. Deliberately introducing bugs into any open source project is plainly unethical; doing so in the Linux kernel is borderline malicious.

bezout 6y ago
We should ban A/B testing then. Google didn’t tell me they were using me to understand which link color is more profitable for them. There are experiments and experiments. Apart from the fact that they provided the fix right away, they didn’t do anyone harm. And, by the way, it’s their job. Maintainers must approve patches after they ensured that the patch is fine. It’s okay to do mistakes, but don’t tell me “you’re wasting my time” after I showed you that maybe there’s something wrong with the process. If anything, you should thank me and review the process. If your excuse is “you knew the patch was vulnerable”, then how are you going to defend the project from bad actors?
- wccrawford 6y ago
  Actually, I think participants in an A/B test should be informed of it. I think people should be informed when market research is being done on them. For situations where they are already invested in the situation, it should be optional. For other situations, such as new customer acquisition, the person would have the option of simply leaving the site to avoid it. But either way, they should be informed.
- corty 6y ago
  > they didn’t do anyone harm. Several of the patches are claimed to have landed in stable. Also, distributions and others (like the grsecurity people) pick up lkml patches that are not included in stable but might have security benefits. So even just publishing such a patch is harmful. Also, fixes were only provided to the maintainers privately as it seems, and unsuccessfully. Or not at all. > If your excuse is “you knew the patch was vulnerable”, then how are you going to defend the project from bad actors? Exactly the same way as without that "research". If you try to pry open my car door, I'll drag you to the next police station. "I'm just researching the security of car doors" won't help you.

arcatek 6y ago

Getting specific consent from the project leads is entirely doable, and would have avoided most of the concerns.

Avamander 6y ago
It really wouldn't have and would've made the patches not pass all levels of review.
- arcatek 6y ago
  How do you think social engineering audits work? You first coordinate with the top layer (in private, of course) and only after getting their agreement do you start your tests. This isn't any different.
  - Avamander 6y ago
    > You first coordinate with the top layer (in private, of course) and only after getting their agreement do you start your tests. The highest level is what had to be tested as well, or do you imagine only consulting Linus? Do you think that wouldn't've gotten him lynched?

twic 6y ago

You're right, and it is depressing how negative the reaction has been here. This work is the technical equivalent of "Sokalling", and it is a good and necessary thing. The thing that people should be upset about is that such an important open source project so easily accepts patches which introduce security vulnerabilities. Forget the researchers for a moment - if it is this easy, you can be certain that malicious actors are also doing it. The only difference is that they are not then disclosing that they have done so! The Linux maintainers should be grateful that researchers are doing this, and researchers should be doing it to every significant open source project.

anonymousab 6y ago
> The thing that people should be upset about is that such an important open source project so easily accepts patches which introduce security vulnerabilities They were trusting of contributors to not be malicious, and in particular, were trusting of a university to not be wholly malicious. Sure, there is a possible threat model where they would need to be suspicious of entire universities. But in general, human projects will operate under some level of basic trust, with some sort of means to establish that trust. To be able to actually get anything done; you cannot perfectly formally review everything with finite human resources. I don't see where they went wrong with any of that here. There's also the very simple fact that responding to an incident is also a part of the security process, and broadly banning a group whole-cloth will be more secure than not. So both them and you are getting what you want it of it - more of the process to research, and more security. If the changes didn't make it out to production systems, then it seems like the process worked? Even if some of it was due to admissions that would not happen with truly malicious actors, so too were the patches accepted because the actors were reasonably trusted.
- twic 6y ago
  The Linux project absolutely cannot trust contributors to not be malicious. If they are doing that, then this work has successfully exposed a risk.
  - 6y ago