Announcement

Collapse
No announcement yet.

University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • StarterX4
    replied
    Those Chinese names sound to me like CCP stands behind it through their "Confucius institutes" that bring corruption to the universities worldwide.

    Leave a comment:


  • Terrablit
    replied
    Originally posted by gigi View Post
    in the name of research, person has introduced or frankly verified that malicious commits can be indeed introduced without much hassle in open source projects (i mean where source code is available without any restrictions to view and with dedication resolve issues). i wonder how open source community will react to 42nd IEEE Symposium on Security and Privacy (Oakland'21). Virtual conference, May 2021.
    Originally posted by lkucharczyk View Post
    Also from the paper:
    A. Ethical Considerations
    Ensuring the safety of the experiment. In the experiment,we aim to demonstrate the practicality of stealthily introducing vulnerabilities through hypocrite commits. Our goal is not to introduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code.

    Seems like they failed, no?
    Originally posted by User42 View Post

    By all mean, read!

    https://github.com/QiushiWu/QiushiWu...Insecurity.pdf

    What you say makes sense and is even quantified with latency period, catch rate, etc. Look at figure 1... Use after free bug, 42% chance of being spotted during review. Would stay unfixed in the kernel 5 years on average. Wouldn't it be great to increase the likelihood of that thing being spotted on day 1 hopefully or at least within months, not years after release? If you don't know where the problem is, how prevalent it is, how it gets through review and what impact it has on the code, how can you "fix" it in general?
    Man, 3 brand new accounts in a thread. That's pretty unusual in something that wouldn't start a flame war. It's a good thing they're all:
    • promoting sites and future events related to the study's authors
    • minimizing the negative impact of this study and otherwise gaslighting concerns about it
    • promoting the "need" for studies like this
    • specifically interested and/or knowledgeable about this topic

    I mean, without them, I probably wouldn't have known about the importance of auditing open source code, right? Or even how to view the study's authors and the related organizations. Astroturfing is super important. I mean, it's not like grass can grow on its own, right? Why, I might even hire them to review my open-source project, which is probably super insecure without their expertise.

    /s

    In all seriousness, maybe try open and direct engagement next time? It's a small relatively field and the linux fanbase has a high occurrence of paranoia. Which makes me a bit of a dick, I guess, for pointing this out with the knowledge that it's going to set some tinfoil hats spinning. But, with two mistakes about not communicating properly in a row, maybe the third time it'll sink in?

    Leave a comment:


  • kpedersen
    replied
    Originally posted by martinus View Post
    Everybody who works inside a corporation knows how the power structure and recognition systems inside a corporation will automatically lead to the low level of quality and secureness that closed source software is measurably known for.
    This is so true. It is naive to think that development behind closed doors is "perfection" just because you can't see it!

    Leave a comment:


  • cybik
    replied
    Originally posted by obri View Post
    Why does the word "assholes" come to my mind?
    What have arseholes ever done to you to get put in the same group as these abusive researchers?

    Leave a comment:


  • zexelon
    replied
    Originally posted by oiaohm View Post
    The latest news and commentary on workplace and employment. Find free resources on labor insights, working conditions, and people management software labor efficiency and helping your teams achieve success.

    What you have stated here is a false idea. In closed source you can still have your sabotaging parties that can be very hard to find.
    Thanks for sharing the link, quite an interesting quick read. You are definitely correct that the kernel does not need people explicitly screwing it up for research with no intent to control or retract when your research is done.

    Leave a comment:


  • martinus
    replied
    Originally posted by zexelon View Post
    The question is how do you validate contributor's trustworthiness in a community that champions total freedom of contribution? In closed source everyone contributing can be 100% managed and vetted.
    You are raising a valid question about open source development. However, don't hold your breath waiting for quality coming out of closed source software. Everybody who works inside a corporation knows how the power structure and recognition systems inside a corporation will automatically lead to the low level of quality and secureness that closed source software is measurably known for.

    Leave a comment:


  • MadCatX
    replied
    Originally posted by User42 View Post

    This is not about banning people because those commits were potentially harmful. I hope it is clear if that was the reason, everybody would be banned: introducing new bugs is a very common thing after all. If you look at the series of emails, Greg most likely did not like being treated as a lab rat (understandable) especially without anybody in the kernel being involved (very understandable). Though a certain amount of secrecy is necessary not to bias the study, not involving anyone is a bad idea.

    Now there is a new series of patches that he perceived as useless, not harmful, useless. It looks like his conclusion was that they are being used as lab rats again, therefore ban. Now, as Sonadow noted, some reviewer actually think some of these patches are good, fix problems and are probably not malicious. Considering the content of the paper, this might be (I insist, might be) the result of the application of the workflow they recommended or it might be a new experiment. Anyway he was not afraid of harmful commits, he clearly does not want the kernel to become an Academic playground.
    Well, some people from UMN deliberately slipped some malicious code into the kernel. The fact that some of the code that was submitted by them during this research might have been legitimate could have been a part of the "scheme". Shortly after this came to light another UMN guy submitted a sketchy patch. It was not just GKH's opinion, everybody in that thread agreed that the code was wrong. Does it really matter if it introduced a bug or was just solving a non-existent problem?

    Leave a comment:


  • drjohnnyfever
    replied
    Originally posted by oiaohm View Post

    No the conditional requirements. "depending on the results of the sabotage." key and "giving aid to a enemy" Word War II the enemy was clearly defined so Treason charges are more possible. The law is still on the books for Treason in the USA but its hard prosecute due to the requirements current day and since world war II. Sabotage is a lot more simple. The china version of Treason allows for Sabotage of government properly to be prosecuted without confirming enemy because you doing the sabotage was the enemy.

    Reason for the lack of recent historic examples treason examples in USA is lack of clear define enemy. Something to remember a code modification might sit in place with a flaw for a decade+ before being found by then the USA could be at war with a party that is a clear define enemy and could be in the mood again to use the Treason change. Remember the Linux kernel has kept detail records of who submitted what. So being noticed and removed is technically saving their hide against future risk.
    You have to jump to a lot of crazy conclusions to believe this fits into Treason somehow. By the same logic speeding or shoplifting is treason too if done to "aid the enemy." So basically you've done a fantastic job of proving you can make anything be treason with enough mental gymnastics. I'm so glad you brought this up...

    Leave a comment:


  • oiaohm
    replied
    Originally posted by drjohnnyfever View Post
    The last time someone was convicted of Treason in the United States was 1952 over events that happened in World War II, and eventually the sentence was commuted. If your interpretations of Treason law were at all reasonable one would expect there to be a at least a single historical example.
    No the conditional requirements. "depending on the results of the sabotage." key and "giving aid to a enemy" Word War II the enemy was clearly defined so Treason charges are more possible. The law is still on the books for Treason in the USA but its hard prosecute due to the requirements current day and since world war II. Sabotage is a lot more simple. The china version of Treason allows for Sabotage of government properly to be prosecuted without confirming enemy because you doing the sabotage was the enemy.

    Reason for the lack of recent historic examples treason examples in USA is lack of clear define enemy. Something to remember a code modification might sit in place with a flaw for a decade+ before being found by then the USA could be at war with a party that is a clear define enemy and could be in the mood again to use the Treason change. Remember the Linux kernel has kept detail records of who submitted what. So being noticed and removed is technically saving their hide against future risk.

    Leave a comment:


  • obri
    replied
    Why does the word "assholes" come to my mind?

    Leave a comment:

Working...
X