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

  • #91
    I would like to read Linus' letter

    Comment


    • #92
      hello @Terrablit

      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?
      i beg to differ.

      did you know that under different name i have specifically created an account and written my opinion for "announcement of devuan distro". feel free to search.

      we are all trying to expressing our opinions. period.

      Comment


      • #93


        We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical.

        Comment


        • #94
          Originally posted by Volta View Post
          Some people saying about 'ethics' must be living in a dream. It's enough to check the news to notice there's mostly no ethics in 'our era'. It seems for many people it's 'ethical' to use atomic bombs against civilians, destroy Afghanistan, Iraq, Syria and their legacy, treat people like slaves (some corporations for example), conduct medical experiments, spread lies all the time in medias (welcome CNN and NYT). If someone expects 'ethics' from mentioned people or institutions then it's his fault.
          You normally expect them to be smart enough not to break the law of their own country. Sabotage is defined under USA law and is a convict-able offence. The kind of research they were doing did cross into Sabotage.

          Originally posted by S.Pam View Post
          https://cse.umn.edu/cs/statement-cse...-april-21-2021

          We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical.
          Absolutely its extremely serious what they were doing is illegal. Linux kernel banning them was being nice thinking with the companies linked to the Linux they could have send a legal cease and desist letter with criminal case to follow to to committing Sabotage against them. Yes case like this the USA state end up having to pick up the prosecution bill.

          I would say there need to be improved safeguards against doing illegal research.

          They wanted to find out how the Linux kernel handles malicious commits. Being banned is one of the Linux kernels maintainer responses to a track record of poor quality code. Its not like the Linux kernel is short of people wanting to develop code and those paid by business to submit code to the Linux kernel who get banned due to poor quality code is end of their employment. Remember over 95% of those committing code to the Linux kernel are paid to-do and their job depends on that they can so there is a very big reason to submit the best possible code mainline by doing multi peer reviews so they don't end up on the banned list.

          The differences outcome between closed source and major open source for a developer doing malicious commits getting caught is basically the same of losing employment.

          Comment


          • #95
            Originally posted by oiaohm View Post

            You normally expect them to be smart enough not to break the law of their own country. Sabotage is defined under USA law and is a convict-able offence. The kind of research they were doing did cross into Sabotage.
            Therefore I recommend the principle of limited trust to everything. Just like on the road.

            Comment


            • #96
              Alexander Grund already mentioned it on the linux-nfs list:

              Code:
              According to the paper:
              > We submit the three patches using a randomGmail account to the Linux community andseek their feedback
              
              So while their behaviour regarding this practice may have been bad, I'd give them the benefit of doubt that they didn't want to actually introduce
              a bug.
              I.e. what they wrote:
              
              > we immediately notify themaintainers of the introduced UAF and request them to notgo ahead to apply the patch.
              > At the same time, we point out the correct fixing of the bug and provide our correct patch.
              > [...] All the UAF-introducing patches stayed only in the emailexchanges, without even becoming a Git commit in Linuxbranches
              
              TLDR:
              - The faulty patches were NOT from umn.edu accounts but from a gmail account
              - Only the corrected patches should have made it to the branches
              Because Greg intentionally ignored the text of the paper, or did what people these days like to do: read the title only and overreact, he now reverted almost 200 patches and they are yet to find one of those supposedly intentionally added bugs.
              The reverted changes aren't even the type of account they are looking for. The research paper states "27% of the incorrect patches were made by fresh developers who have never touched the source code files before" and that they used accounts like that for their paper instead of university emails.

              Re-reviewing for security isn't a bad idea, except in this case it seems to be wasting people's time (as long as I am not the people, I am OK with it), but this far there isn't a single malicious commit, instead they just reverted a lot of bug fixes that they'll need to add one-by-one.
              The real issue Greg got upset about is that someone (unrelated to the paper) posted low quality code, suspected to be from a static analyzer, with a university account and he thinks it's some social experiment by one of the professors.

              Comment


              • #97
                Originally posted by Volta View Post
                Therefore I recommend the principle of limited trust to everything. Just like on the road.
                That is true. The Linux kernel maintainers are also like police force on the Linux kernel source road. Doing something on the road bad enough and the police notice bad things happen to you. Do patches that draw the Linux Kernel Maintainers attention for being bad also result possible bad thing happening to you.

                Limited trust and parties exist in the system to punish those who don't play by the rules. Banned is first step this is like you general offence fine on the road with open source. Push the issue by changing email addresses and so on company legal departments can get involved then things take a turn for the really bad.

                The cheapest path is to resolve without legal but if party will not take hint its not acceptable legal is not off the table if the actions are in fact illegal.

                Open Source projects with big companies behind them are not places to mess around.

                Comment


                • #98
                  People hacking literally anything: nice, well done, helps security! People hacking Linux: monsters! Kill them with fire!

                  He exploited a security flaw. Unethical? Maybe. Helpful? Definitely.

                  Comment


                  • #99
                    Originally posted by Terrablit View Post
                    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?
                    You are a very stupid person. You can't understand that a situation can be grey, it needs to be black or white. The only thing I am saying is that study was actually useful (which was not a given). If you read it instead of dismissing it, you would see it. But I guess I can't ask much from somebody who claims I opened my account to start a flame war... especially when that somebody has not noticed that I happened to open my account a full day before the story was released and probably more than half a day before the story was even written. There is that thing called "causality"... but I guess it's a concept completely lost on you.

                    Comment


                    • Originally posted by oiaohm View Post
                      Horrible there is a valid Company reason to add bugs.

                      Yes it called the Bebugging process where you intentionally add bugs to beta products that testers should report if they are doing the testing they are being paid to do.

                      Of course you are not meant to-do this to final production code or without the knowledge of those making final production code.

                      pmorph there are valid and legal reasons to-do almost anything. The process the university was doing with maintainer approval would not have been problem legally but it was without approval. Like could I have this pile of known defective patches put into Linux kernel next branch to check out detecting and testing rate with the kernel developers knowing this patches have to be removed before production releases would have been Bebugging. This could be used to detect areas in the Linux kernel tree that are not getting regular testing. Of course selling this to the Linux kernel maintainers would be a uphill battle.

                      Remember you can do almost anything legally and above board just to require more paperwork and agreements and consideration risks or you can do what the University here did take the easy way out and do something illegal because you don't have the correct agreements and consideration of risks in place to control the risk.

                      Yes beta test software having a 90 day functionality time out added is one of the risk mitigation when doing Bebugging so even if a security fault is add in by the Bebugging in 90 days fault should no longer be in the wild to be exploited and this generally faster than attackers can find a fault and create the tools to take advantage of a fault. Consideration of risk and the required mitigation this is not present in this universities study or any of the actions they have been doing.
                      And these few injected bugs will tell substantially more about the state of the kernel than the bug reports received from all around the world, all the time? The fact that some method exists doesn't mean it makes sense in every context.

                      Comment

                      Working...
                      X