lkml.org 
[lkml]   [2021]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 000/190] Revertion of all of the umn.edu commits
    Hi!

    I don't believe doing huge revert is good idea.

    > I have been meaning to do this for a while, but recent events have
    > finally forced me to do so.
    >
    > Commits from @umn.edu addresses have been found to be submitted in "bad
    > faith" to try to test the kernel community's ability to review "known
    > malicious" changes. The result of these submissions can be found in a
    > paper published at the 42nd IEEE Symposium on Security and Privacy
    > entitled, "Open Source Insecurity: Stealthily Introducing
    > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
    > of Minnesota) and Kangjie Lu (University of Minnesota).

    Do you have examples of those "bad faith" commits? Because that's not
    what the paper says. While I identified one unneccessary commit during
    stable review, I don't believe it was done in bad faith. According to
    the paper, there are just three (3) (!!) bad faith commits, and were
    done from gmail addresses, and steps were taken so to prevent them
    from entering git.

    I do believe we have problem with -stable kernel getting way too many
    changes that are not really fixing anything, or are fixing stuff like
    "16 bytes memory leak once per boot" or printk log levels. I tried
    pushing back with little success. Stable kernel rules are not
    consistent with patches actually accepted into stable. Plus, it is
    quicker to get patch to stable release than to mainline release, which
    I believe is additional problem.

    For the reference, the paper seems to be available here:

    https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

    Quoting the paper:

    Experiment overview. In this experiment, we leverage
    program-analysis techniques to prepare three minor hypocrite
    commits that introduce UAF bugs in the Linux kernel. The
    three cases represent three different kinds of hypocrite commits:
    (1) a coding-improvement change that simply prints an error
    message, (2) a patch for fixing a memory-leak bug, and (3) a
    patch for fixing a refcount bug. We submit the three patches
    using a random Gmail account to the Linux community and
    seek their feedback—whether the patches look good to them.
    The experiment is to demonstrate the practicality of hypocrite
    commits, and it will not introduce or intend to introduce actual
    UAF or any other bug in the Linux kernel.
    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. In addition
    to the minor patches that introduce UAF conditions, we also
    prepare the correct patches for fixing the minor issues. 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
    ...

    Best regards,
    Pavel
    --
    http://www.livejournal.com/~pavelmachek
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2021-04-22 10:41    [W:4.185 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site