University of Minnesota banned from contributing to Linux kernel

[John F. Eldredge]

Two researchers at the University of Minnesota have admitted they deliberately introduced security flaws into the Linux kernel, in order to determine how effective the review process is. As a result, all code changes originating from the university have been rolled back and are being re-reviewed, and no one using a University of Minnesota email address will be allowed to submit kernel changes. Apparently the flaws the researchers introduced are now in use on production systems worldwide.

[Kent Perrier]

That isn't true (flaws now in use on production systems). If you read their paper, once the maintainer said "ok, looks good" they told the maintainer of the issue with the code and not to use it. (Section VI A "Ethical Considerations").

Now that may be going through ALL of the code submissions from UMN and ripping it all out and replacing it, but in this case security issues were not introduced into the kernel.

On Sat, Apr 24, 2021 at 9:07 AM John F. Eldredge <jo...@jfeldredge.com> wrote:

Two researchers at the University of Minnesota have admitted they deliberately introduced security flaws into the Linux kernel, in order to determine how effective the review process is. As a result, all code changes originating from the university have been rolled back and are being re-reviewed, and no one using a University of Minnesota email address will be allowed to submit kernel changes. Apparently the flaws the researchers introduced are now in use on production systems worldwide.

--
--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com
To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en

---
You received this message because you are subscribed to the Google Groups "NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nlug-talk+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nlug-talk/CAJfAAY%2BFfNnoW8OJnf_ypyoXPfj-RPaJo-495EqY7cXYCsaQtw%40mail.gmail.com.

[Csaba Toth]

GKH (Greg Kroah-Hartman) got pissed off pretty much. Here is a ZDNet article about it https://www.zdnet.com/google-amp/article/greg-kroah-hartman-bans-university-of-minnesota-from-linux-development-for-deliberately-buggy-patches/

This patch quoted in the article https://lore.kernel.org/linux-nfs/YH5%2Fi7Ovs...@kroah.com/ kinda looks unnecessary (in case we assume gss_release_msg is perfect, who knows what side effects it has...), but...

I know some very prominent security guys (Pipacs https://twitter.com/paxteam and Brad Spengler from GRSecurity https://twitter.com/spendergrsec).

Please read Brad's last 5-6 Tweets and references https://twitter.com/spendergrsec

To view this discussion on the web visit https://groups.google.com/d/msgid/nlug-talk/CA%2B6_KC-PmYdPPuReM3tyG-Ga7OXJsiRGbKEhVgVCWch6649uLQ%40mail.gmail.com.

[John F. Eldredge]

Well, the news report I read said the bugs were submitted and accepted.

To view this discussion on the web visit https://groups.google.com/d/msgid/nlug-talk/CA%2B6_KC-PmYdPPuReM3tyG-Ga7OXJsiRGbKEhVgVCWch6649uLQ%40mail.gmail.com.

[Michael Chaney]

Start reading here:

https://lore.kernel.org/linux-nfs/20210407001658.2...@umn.edu/

This is one of my favorites, the original is gone but you can get some of it in the reply:

https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbm...@kroah.com/

This is the part - note that Pakki is claiming that he's submitting these based on a new static analyzer.  Just read it:

"> Greg,
>
> I respectfully ask you to cease and desist from making wild accusations
> that are bordering on slander.
>
> These patches were sent as part of a new static analyzer that I wrote and
> it's sensitivity is obviously not great. I sent patches on the hopes to get
> feedback. We are not experts in the linux kernel and repeatedly making
> these statements is disgusting to hear.

[note - he's lying]
>
> Obviously, it is a wrong step but your preconceived biases are so strong
> that you make allegations without merit nor give us any benefit of doubt.
>
> I will not be sending any more patches due to the attitude that is not only
> unwelcome but also intimidating to newbies and non experts.

I love this.  "unwelcome but also intimidating to newbies and non experts".

SMH.

This is the most popular operating system kernel on the planet used by billions of devices.  If you're a "newbie" or "non expert" I would hope that it's not just "unwelcome" and "intimidating" - I would hope that they would be outright hostile to you.  It's not your playground, idiot.  Try walking into Microsoft and present yourself as a "non expert newbie" and see if they'll put you right to work on the Windows kernel.  Go to Apple and tell them you're new to programming but you'd like to have commit rights to the Darwin kernel.  See how far you get.

I am glad to see that the guys working on a kernel that I depend on in several ways don't welcome "non experts".  More of this, please.

Michael
--
Michael Darrin Chaney, Sr.
mdch...@michaelchaney.com
http://www.michaelchaney.com/

[Kent Perrier]

I am trusting what they put in their paper. So..... :)

I do think this kind of research needs to be done, I just don't know how to do it in an ethical way, not wasting the time of the developers. I also think the kernel maintainers are the ones most likely to find such submissions. If a supply-chain attack was to be done against "linux" doing it somewhere else, on a smaller project would be the most productive. A single maintainer/smaller team would be more likely, IMO, to be overwhelmed and just accept patches with much less review. As opposed to kernel maintainers who are probably being paid to do that.

Getting a job at Dell or HP to write device drivers would be a far better place to get the access to do something malicious to many, many servers out there.

Kent

To view this discussion on the web visit https://groups.google.com/d/msgid/nlug-talk/CAJfAAYJxZV7xN51uW-UbJVLAFVueCtm8F_jkhE%2BaritEALp7cw%40mail.gmail.com.

[Csaba Toth]

"This is the most popular operating system kernel on the planet used by billions of devices."

This is exactly why it is important to see how well it is protected. We want it to be as secure as possible.

The experiment could not happen at all with the Windows kernel since it's not open source. Some people claim open source has the advantage of many eyes. Is that true? That's the question.

When you want to really test your company's security you hire some pen testers. They may find security holes. Don't get triggered if they find some problems.

The security of the Linux kernel, the high code churn, the volatility of kernel API changes, kernel CI and automated testing system, the shenanigans around dissing CVE numbers - these are all concerns and topics raised by many security minded people in various konferences. Some knuckleheads get really butt hurt when such questions arise.

I follow the GRSecurity and the PaX team's work for decades now. Just take a look at some of the blog posts at https://grsecurity.net/blog - not too rarely it turns out that bug Y which is recently fixed in the kernel (and were present for X years where sometimes X is big number) is already fixed in GRSecurity for many years. With that I don't want to advocate for GRSecurity per se, I'm just always appalled to see how the kernel has serious problems around security and a huge space to improve.

So newbies are not welcome, then how would those three patches from the publication would actually land in the kernel? They would have had the researchers not warned the maintainers after the OK signal was already given. Quote from the publication:

"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"

It's all of our interest to make the kernel more secure. Yes, sometimes that means a stealth pen test.

Maybe UMN made some mistakes but to ban them is too harsh. The takeaway should be that the patches would have gone through and how that process can be fortified.

--

--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com
To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en

---
You received this message because you are subscribed to the Google Groups "NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nlug-talk+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nlug-talk/CAAtfUtFR0j-gGf-TRExNJh0-6DagMmQVCgyW4Tv3uMjAQJi%3D5A%40mail.gmail.com.