12 ms·

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, bu

This seems like a pretty scummy way to do "research". I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. It's not that they're doing this, I'm sure they're not the first to think of this (for research or malicious reasons), but having the gall to brag about it is a new low.

EthanHeilman 6y ago
>I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. My personal observation is that infosec/cybersecurity academia has been steadily moving to higher ethical standards in research. That doesn't mean that all academics follow this trend, but that unethical research is more likely to get your paper rejected from conferences. Submitting bugs to an open source project is the sort of stunt hackers would have done in 1990 and then presented at a defcon talk.
- roblabla 6y ago
  > I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. IEEE seems to have no problem with this paper though. >>> On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits Qiushi Wu, and Kangjie Lu. To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. from https://www-users.cs.umn.edu/~kjlu/ https://www-users.cs.umn.edu/~kjlu/
  - neatze 6y ago
    "To appear"
    - JadeNB 6y ago
      "To appear" has a technical meaning in academia, though—it doesn't mean "I hope"; it means "it's been formally accepted but hasn't actually been put in 'print' yet." That doesn't stop someone from lying about it, but it's not a casual claim, and doing so would probably bring community censure (as well as being easily falsifiable after time).
      - neatze 6y ago
        "To appear" to me meant; it is under revision by IEEE, otherwise why not just to state paper was accepted by IEEE.
        flakiness 6y ago
        It's a jargon in academia.
        andi999 6y ago
        It is a bit more complicated, since this is a conference paper. Usually, if a conference paper is accepted, it is only published if the presentation was held (so if the speaker cancels, or doesnt show up, the publication is revoked). Edit: All conference are different, I dont know if it applies to that one.
        neatze 6y ago
        It makes sense, thank you for explanation.
        cardiffspaceman 6y ago
        I have only ever attended one conference, but I attended it about 32 times, and the printed proceedings were in my hands before I attended any talks in the last dozen or so. How does revocation work in that event?
        andi999 6y ago
  - khuey 6y ago
    Decent odds their paper gets pulled by the conference organizers now.
  - MzxgckZtNqX5i 6y ago
    Section IV.A: > We send the minor patches to the Linux community through email to seek their feedback. Fortunately, there is a time window between the confirmation of a patch and the merging of the patch. Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF 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 correct patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches. Therefore, we ensured that none of our introduced UAF bugs was ever merged into any branch of the Linux kernel, and none of the Linux users would be affected. It seems that the research in this paper has been done properly. EDIT: since several comments come to the same point, I paste here an observation. They answer to these objections as well. Same section: > Honoring maintainer efforts. The OSS communities are understaffed, and maintainers are mainly volunteers. We respect OSS volunteers and honor their efforts. Unfortunately, this experiment will take certain time of maintainers in reviewing the patches. To minimize the efforts, (1) we make the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we find three real minor issues (i.e., missing an error message, a memory leak, and a refcount bug), and our patches will ultimately contribute to fixing them. And, coming to ethics: > The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter.
    - capableweb 6y ago
      > It seems that the research in this paper has been done properly. How is wasting the time of maintainers of one of the most popular open source project "done properly"? Also, someone correct me if I'm wrong, but I think if you do experiments that involve other humans, you need to have their consent _before_ starting the experiment, otherwise you're breaking a bunch of rules around ethics.
      - MzxgckZtNqX5i 6y ago
  - deleted 6y ago
    [deleted]
  - lr1970 6y ago
    The IEEE Symposium on Security and Privacy should remove this paper at once for gross ethics violations. The message should be strong and unequivocal that this type of behavior is not tolerated.
  - phw 6y ago
    > IEEE seems to have no problem with this paper though. IEEE is just the publishing organisation and doesn't review research. That's handled by the program committee that each IEEE conference has. These committees consist of several dozen researchers from various institutions that review each paper submission. A typical paper is reviewed by 2-5 people and the idea is that these reviewers can catch ethical problems. As you may expect, there's wide variance in how well this works. While problematic research still slips through the cracks, the field as a whole is getting more sensitive to ethical issues. Part of the problem is that we don't yet have well-defined processes and expectations for how to deal with these issues. People often expect IRBs to make a judgement call on ethics but many (if not most) IRBs don't have computer scientists that are able to understand the nuances of a given research projects and are therefore ill-equipped to reason about the implications.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
rob74 6y ago
Yup, it's basically stating the obvious: that any system based on an assumption of good faith is vulnerable to bad faith actors. The kernel devs are probably on the lookout for someone trying to introduce backdoors, but simply introducing a bug for the sake of introducing a bug (without knowing if it can be exploited), which is obviously much easier to do stealthily - why would anyone do that? Except for "academic research" of course...
- shadowgovt 6y ago
  Academic research, cyberwarfare, a rival operating system architecture attempting to diminish the quality of an alternative to the system they're developing, the lulz of knowing one has damaged something... The reasons for bad-faith action are myriad, as diverse as human creativity.
- cptskippy 6y ago
  In theory wouldn't it be possible to introduce bugs that are seemingly innocuous when reviewed independently but when combined form and exploit? Could a number of seemingly unrelated individuals introduce a number of bugs over time to form and exploit without being detected?
  - dec0dedab0de 6y ago
    yes, of course, and I'm fairly certain it's happened before or at least there have been suspicions of it happening. Thats why trust is important, and why I'm glad kernel development is not very friendly. Doing code review at work I am constantly catching blatantly obvious security bugs. Most developers are so happy to get the thing to work, that they don't even consider security. This is in high level languages, with a fairly small team, only internal users, and pretty simple code base. I can't imagine trying to do it for something as high stakes and complicated as the kernel. Not to mention how subtle bugs can be in C. I suspect it is impossible to distinguish incompetence from malice. So aggressively weeding out incompetence, and then forming layers of trust is the only real defense.
  - rgrs 6y ago
    In that scenario, it is a genuine bug. Not a malicious actor
alpaca128 6y ago
> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies". This is thinly veiled and potentially dangerous bullying.
- smsm42 6y ago
  This looks a very cynical attempt to leverage PC language to manipulate people. Basically a social engineering attack. They surely will try to present it as pentest, but IMHO it should be treated as an attack.
- ISL 6y ago
  It isn't even bullying. It is just dumb? Fortunately, the episode also suggests that the kernel-development immune-system is fully-operational.
  - tigerBL00D 6y ago
    Not sure. From what I read they've successfully introduced a vulnerability in their first attempt. Would anyone have noticed if they didn't call more attention to their activities?
    - mirchibajji 6y ago
      Can you point to this please? From my reading, it appears that their earlier patches were merged, but there is no mention of them being actual vulnerabilities. The lkml thread does mention they want to revert these patches, just in case.
      - lb7000 6y ago
        From LKML "A lot of these have already reached the stable trees. I can send you revert patches for stable by the end of today (if your scripts have not already done it)." https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.c...
ec109685 6y ago
Agree, and it seems like at least this patch, despite the researcher’s protestations, actually landed sufficiently that it could have caused harm? https://lore.kernel.org/patchwork/patch/1062098/ https://lore.kernel.org/patchwork/patch/1062098/
- whoopdedo 6y ago
  I've been scratching my head at this one and admit I can't spot how it can be harmful. Why wouldn't you release the buffer if the send fails?
  - Natsu 6y ago
    It might be a double free if the buffer is released elsewhere.
    - whoopdedo 6y ago
      The buffer should only be released by its own complete callback, which only gets called after being successfully queued. Moreover, other uses of `mlx5_fpga_conn_send`, and the related `mlx5_fpga_conn_post_recv` will free after error. The other part of the patch, that checks for `flow` being NULL may be unnecessary since it looks like the handle is always from an active context. But that's a guess. And it's only unreachable code. The opinion I have from this is despite other patches being bad ideas, this one doesn't look like it. Because the other patches didn't make it past the mailing list, it demonstrates that the maintainers are doing a good enough job.
      - ec109685 5y ago
        You’re right, that wasn’t one of the bad patches: https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL...
mihaaly 6y ago
I believe this is violating research ethics hard, very hard. Reminds me if someone was aiming at researching childs' mental development through the study of inflicting mental damages. The subjects and the likely damages are not similar but the approach and mentality are inconveniently so.
- jpm48 6y ago
  yep first thing I thought was how did this get through the research ethics panel (all research at my University has to get approval).
  - oh_sigh 6y ago
    What I don't understand is how this is ethical, but the sokol hoax was deemed unethical. I assume it's because I'm sokol's case, academia was humiliated, whereas here the target is outside academia
a3n 6y ago
The researchers have a future at Facebook, which experimented on how to make users feel bad. https://duckduckgo.com/?q=facebook+emotional+study&t=fpas&ia=web https://duckduckgo.com/?q=facebook+emotional+study&t=fpas&ia...
DyslexicAtheist 6y ago
LKML should consider not just banning the @umn.edu on the SMTP but sinkholing the whole of University of MN network address space. Demand a public apology and paying for compute for the next 3 years or get yeeted
utopcell 6y ago
Agreed. Plus, I find the "oh, we didn't know what we were doing, you're not an inviting community" social engineering response, completely slimey and off-putting.
deleted 6y ago
[deleted]
shuringai 6y ago
how is this different than blackhats contributing to general awareness of web security practices? Opensource considered secure just because its up on github is no different than plaintext HTTP GET params being secure just because "who the hell will read your params in the browser", which would be still the status quo if some hackers hadn't done the "lowest of the low " and show the world this lesson.
lpapez 6y ago
The "scientific" question answered by the mentioned paper is basically: "Can open-source maintainers make a mistake by accepting faulty commits?" In addition to being scummy, this research seems utterly pointless to me. Of course mistakes can happen, we are all humans, even the Linux maintainers.
mistersquid 6y ago
This observation may very well get downvoted to oblivion: what UMN pulled is the Linux kernel development version of the Sokal Hoax. Both are unethical, disruptive, and prove nothing about the integrity of the organizations they target.
- alexpetralia 6y ago
  The main difference is that the Sokal Hoax worked (that is why it is notable).
- neoburkian 6y ago
  Except for Linux actively running on 99% of all servers on the planet. Vulnerabilities in Linux can literally kill people, open holes for hackers, spies, etc. Submitting a fake paper to a journal read by a few dozen academics is a threat to someones ego. It is not in the same ballpark as a threat to IT infrastructure everywhere.
nborwankar 6y ago
Technically analogous to pen testing except that it wasn’t done at the behest of the target, as legal pen testing is done. Hence it is indistinguishable from and must be considered, a malicious attack.
restingrobot 6y ago
To me, this seems like a convoluted way to hide malicious actions as research, (not the other way around). This smells of intentional vulnerability introduction under the guise of academic investigation. There are millions of other, less critical, open source solutions this "research" could have tested on. I believe this was an intentional targeted attack, and it should be treated as such.
andrepd 6y ago
Devil's advocate, but why? How is this different from any other white/gray-hat pentest? They tried to submit buggy patches, once approved they immediately let the maintainers know not to merge them. Then they published a paper with their findings and which weak parts in the process they thing are responsible, and which steps they recommend be taken to mitigate this.
- kerng 6y ago
  Very easy, if its not authorized it's not a pentest or red team operation. Any pentester or red team considers their profession an ethical one. By the response of the Linux Foundation, this is clearly not authorized nor falling into any bug bounty rules/framework they would offer. Social engineering attacks are often out of bounds for bug bounty - and even for authorized engagements need to follow strict rules and procedures. Wonder if there are even legal steps that could be taken by Linux foundation.
- burnished 6y ago
  You can read the (relatively short) email chains for yourself, but to try and answer your question, as I understood it the problem wasn't entirely the problems submitted in the paper it was followup bad patches and ridiculous defense. Essentially they sent patches that were purportedly the result of static analysis but did nothing, broke social convention by failing to signal that the patch was the result of a tool, and it was deemed indistinguishable from more attempts to send bad code and perform tests on the linux maintainers.
radiator 6y ago
Unfortunately, we cannot be sure it is low for today's academia. So many people working there, with nothing useful to do other than flooding the conferences and journals with papers. They are desperate for anything that could be published. Plus, they know that the standards are low, because they see the other publications.
seoaeu 6y ago
There is no separate real world distinct from academia. Saying that scientists and researchers whose job it is to understand and improve the world are somehow becoming "increasingly disconnected from the real world" is a pretty cheap shot. Especially without any proof or even a suggestion of how you would quantify that.

EthanHeilman 6y ago

>I mean I understand that people in academia are becoming increasingly disconnected from the real world, but wow this is low. I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. My personal observation is that infosec/cybersecurity academia has been steadily moving to higher ethical standards in research. That doesn't mean that all academics follow this trend, but that unethical research is more likely to get your paper rejected from conferences. Submitting bugs to an open source project is the sort of stunt hackers would have done in 1990 and then presented at a defcon talk.

roblabla 6y ago
> I don't have data to back this up, but I've been around a while and I can tell you papers are rejected from conferences for ethics violations. IEEE seems to have no problem with this paper though. >>> On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits Qiushi Wu, and Kangjie Lu. To appear in Proceedings of the 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021. from https://www-users.cs.umn.edu/~kjlu/ https://www-users.cs.umn.edu/~kjlu/
- neatze 6y ago
  "To appear"
  - JadeNB 6y ago
    "To appear" has a technical meaning in academia, though—it doesn't mean "I hope"; it means "it's been formally accepted but hasn't actually been put in 'print' yet." That doesn't stop someone from lying about it, but it's not a casual claim, and doing so would probably bring community censure (as well as being easily falsifiable after time).
    - neatze 6y ago
      "To appear" to me meant; it is under revision by IEEE, otherwise why not just to state paper was accepted by IEEE.
      - flakiness 6y ago
        It's a jargon in academia.
      - andi999 6y ago
        It is a bit more complicated, since this is a conference paper. Usually, if a conference paper is accepted, it is only published if the presentation was held (so if the speaker cancels, or doesnt show up, the publication is revoked). Edit: All conference are different, I dont know if it applies to that one.
        neatze 6y ago
        It makes sense, thank you for explanation.
        cardiffspaceman 6y ago
        I have only ever attended one conference, but I attended it about 32 times, and the printed proceedings were in my hands before I attended any talks in the last dozen or so. How does revocation work in that event?
        andi999 6y ago
- khuey 6y ago
  Decent odds their paper gets pulled by the conference organizers now.
- MzxgckZtNqX5i 6y ago
  Section IV.A: > We send the minor patches to the Linux community through email to seek their feedback. Fortunately, there is a time window between the confirmation of a patch and the merging of the patch. Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF 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 correct patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. All the UAF-introducing patches stayed only in the email exchanges, without even becoming a Git commit in Linux branches. Therefore, we ensured that none of our introduced UAF bugs was ever merged into any branch of the Linux kernel, and none of the Linux users would be affected. It seems that the research in this paper has been done properly. EDIT: since several comments come to the same point, I paste here an observation. They answer to these objections as well. Same section: > Honoring maintainer efforts. The OSS communities are understaffed, and maintainers are mainly volunteers. We respect OSS volunteers and honor their efforts. Unfortunately, this experiment will take certain time of maintainers in reviewing the patches. To minimize the efforts, (1) we make the minor patches as simple as possible (all of the three patches are less than 5 lines of code changes); (2) we find three real minor issues (i.e., missing an error message, a memory leak, and a refcount bug), and our patches will ultimately contribute to fixing them. And, coming to ethics: > The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt letter.
  - capableweb 6y ago
    > It seems that the research in this paper has been done properly. How is wasting the time of maintainers of one of the most popular open source project "done properly"? Also, someone correct me if I'm wrong, but I think if you do experiments that involve other humans, you need to have their consent _before_ starting the experiment, otherwise you're breaking a bunch of rules around ethics.
    - MzxgckZtNqX5i 6y ago
- deleted 6y ago
  [deleted]
- lr1970 6y ago
  The IEEE Symposium on Security and Privacy should remove this paper at once for gross ethics violations. The message should be strong and unequivocal that this type of behavior is not tolerated.
- phw 6y ago
  > IEEE seems to have no problem with this paper though. IEEE is just the publishing organisation and doesn't review research. That's handled by the program committee that each IEEE conference has. These committees consist of several dozen researchers from various institutions that review each paper submission. A typical paper is reviewed by 2-5 people and the idea is that these reviewers can catch ethical problems. As you may expect, there's wide variance in how well this works. While problematic research still slips through the cracks, the field as a whole is getting more sensitive to ethical issues. Part of the problem is that we don't yet have well-defined processes and expectations for how to deal with these issues. People often expect IRBs to make a judgement call on ethics but many (if not most) IRBs don't have computer scientists that are able to understand the nuances of a given research projects and are therefore ill-equipped to reason about the implications.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

rob74 6y ago

Yup, it's basically stating the obvious: that any system based on an assumption of good faith is vulnerable to bad faith actors. The kernel devs are probably on the lookout for someone trying to introduce backdoors, but simply introducing a bug for the sake of introducing a bug (without knowing if it can be exploited), which is obviously much easier to do stealthily - why would anyone do that? Except for "academic research" of course...

shadowgovt 6y ago
Academic research, cyberwarfare, a rival operating system architecture attempting to diminish the quality of an alternative to the system they're developing, the lulz of knowing one has damaged something... The reasons for bad-faith action are myriad, as diverse as human creativity.
cptskippy 6y ago
In theory wouldn't it be possible to introduce bugs that are seemingly innocuous when reviewed independently but when combined form and exploit? Could a number of seemingly unrelated individuals introduce a number of bugs over time to form and exploit without being detected?
- dec0dedab0de 6y ago
  yes, of course, and I'm fairly certain it's happened before or at least there have been suspicions of it happening. Thats why trust is important, and why I'm glad kernel development is not very friendly. Doing code review at work I am constantly catching blatantly obvious security bugs. Most developers are so happy to get the thing to work, that they don't even consider security. This is in high level languages, with a fairly small team, only internal users, and pretty simple code base. I can't imagine trying to do it for something as high stakes and complicated as the kernel. Not to mention how subtle bugs can be in C. I suspect it is impossible to distinguish incompetence from malice. So aggressively weeding out incompetence, and then forming layers of trust is the only real defense.
- rgrs 6y ago
  In that scenario, it is a genuine bug. Not a malicious actor

alpaca128 6y ago

> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies". This is thinly veiled and potentially dangerous bullying.

smsm42 6y ago
This looks a very cynical attempt to leverage PC language to manipulate people. Basically a social engineering attack. They surely will try to present it as pentest, but IMHO it should be treated as an attack.
ISL 6y ago
It isn't even bullying. It is just dumb? Fortunately, the episode also suggests that the kernel-development immune-system is fully-operational.
- tigerBL00D 6y ago
  Not sure. From what I read they've successfully introduced a vulnerability in their first attempt. Would anyone have noticed if they didn't call more attention to their activities?
  - mirchibajji 6y ago
    Can you point to this please? From my reading, it appears that their earlier patches were merged, but there is no mention of them being actual vulnerabilities. The lkml thread does mention they want to revert these patches, just in case.
    - lb7000 6y ago
      From LKML "A lot of these have already reached the stable trees. I can send you revert patches for stable by the end of today (if your scripts have not already done it)." https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.c...

ec109685 6y ago

Agree, and it seems like at least this patch, despite the researcher’s protestations, actually landed sufficiently that it could have caused harm? https://lore.kernel.org/patchwork/patch/1062098/ https://lore.kernel.org/patchwork/patch/1062098/

whoopdedo 6y ago
I've been scratching my head at this one and admit I can't spot how it can be harmful. Why wouldn't you release the buffer if the send fails?
- Natsu 6y ago
  It might be a double free if the buffer is released elsewhere.
  - whoopdedo 6y ago
    The buffer should only be released by its own complete callback, which only gets called after being successfully queued. Moreover, other uses of `mlx5_fpga_conn_send`, and the related `mlx5_fpga_conn_post_recv` will free after error. The other part of the patch, that checks for `flow` being NULL may be unnecessary since it looks like the handle is always from an active context. But that's a guess. And it's only unreachable code. The opinion I have from this is despite other patches being bad ideas, this one doesn't look like it. Because the other patches didn't make it past the mailing list, it demonstrates that the maintainers are doing a good enough job.
    - ec109685 5y ago
      You’re right, that wasn’t one of the bad patches: https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL...

mihaaly 6y ago

I believe this is violating research ethics hard, very hard. Reminds me if someone was aiming at researching childs' mental development through the study of inflicting mental damages. The subjects and the likely damages are not similar but the approach and mentality are inconveniently so.

jpm48 6y ago
yep first thing I thought was how did this get through the research ethics panel (all research at my University has to get approval).
- oh_sigh 6y ago
  What I don't understand is how this is ethical, but the sokol hoax was deemed unethical. I assume it's because I'm sokol's case, academia was humiliated, whereas here the target is outside academia

a3n 6y ago

The researchers have a future at Facebook, which experimented on how to make users feel bad. https://duckduckgo.com/?q=facebook+emotional+study&t=fpas&ia=web https://duckduckgo.com/?q=facebook+emotional+study&t=fpas&ia...

DyslexicAtheist 6y ago

LKML should consider not just banning the @umn.edu on the SMTP but sinkholing the whole of University of MN network address space. Demand a public apology and paying for compute for the next 3 years or get yeeted

utopcell 6y ago

Agreed. Plus, I find the "oh, we didn't know what we were doing, you're not an inviting community" social engineering response, completely slimey and off-putting.

deleted 6y ago

[deleted]

shuringai 6y ago

how is this different than blackhats contributing to general awareness of web security practices? Opensource considered secure just because its up on github is no different than plaintext HTTP GET params being secure just because "who the hell will read your params in the browser", which would be still the status quo if some hackers hadn't done the "lowest of the low " and show the world this lesson.

lpapez 6y ago

The "scientific" question answered by the mentioned paper is basically: "Can open-source maintainers make a mistake by accepting faulty commits?" In addition to being scummy, this research seems utterly pointless to me. Of course mistakes can happen, we are all humans, even the Linux maintainers.

mistersquid 6y ago

This observation may very well get downvoted to oblivion: what UMN pulled is the Linux kernel development version of the Sokal Hoax. Both are unethical, disruptive, and prove nothing about the integrity of the organizations they target.

alexpetralia 6y ago
The main difference is that the Sokal Hoax worked (that is why it is notable).
neoburkian 6y ago
Except for Linux actively running on 99% of all servers on the planet. Vulnerabilities in Linux can literally kill people, open holes for hackers, spies, etc. Submitting a fake paper to a journal read by a few dozen academics is a threat to someones ego. It is not in the same ballpark as a threat to IT infrastructure everywhere.

nborwankar 6y ago

Technically analogous to pen testing except that it wasn’t done at the behest of the target, as legal pen testing is done. Hence it is indistinguishable from and must be considered, a malicious attack.

restingrobot 6y ago

To me, this seems like a convoluted way to hide malicious actions as research, (not the other way around). This smells of intentional vulnerability introduction under the guise of academic investigation. There are millions of other, less critical, open source solutions this "research" could have tested on. I believe this was an intentional targeted attack, and it should be treated as such.

andrepd 6y ago

Devil's advocate, but why? How is this different from any other white/gray-hat pentest? They tried to submit buggy patches, once approved they immediately let the maintainers know not to merge them. Then they published a paper with their findings and which weak parts in the process they thing are responsible, and which steps they recommend be taken to mitigate this.

kerng 6y ago
Very easy, if its not authorized it's not a pentest or red team operation. Any pentester or red team considers their profession an ethical one. By the response of the Linux Foundation, this is clearly not authorized nor falling into any bug bounty rules/framework they would offer. Social engineering attacks are often out of bounds for bug bounty - and even for authorized engagements need to follow strict rules and procedures. Wonder if there are even legal steps that could be taken by Linux foundation.
burnished 6y ago
You can read the (relatively short) email chains for yourself, but to try and answer your question, as I understood it the problem wasn't entirely the problems submitted in the paper it was followup bad patches and ridiculous defense. Essentially they sent patches that were purportedly the result of static analysis but did nothing, broke social convention by failing to signal that the patch was the result of a tool, and it was deemed indistinguishable from more attempts to send bad code and perform tests on the linux maintainers.

radiator 6y ago

Unfortunately, we cannot be sure it is low for today's academia. So many people working there, with nothing useful to do other than flooding the conferences and journals with papers. They are desperate for anything that could be published. Plus, they know that the standards are low, because they see the other publications.

seoaeu 6y ago

There is no separate real world distinct from academia. Saying that scientists and researchers whose job it is to understand and improve the world are somehow becoming "increasingly disconnected from the real world" is a pretty cheap shot. Especially without any proof or even a suggestion of how you would quantify that.