LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 04-21-2021, 09:08 AM   #1
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,063

Rep: Reputation: Disabled
Sir, you are being "researched"


The Linux kernel is currently the subject of some University "research" that apparently seeks to prove that "Open Source" software is inherently insecure.

The "researchers" attempt to demonstrate this by submitting malicious kernel patches to the Linux Kernel Mailing List. As these submissions come from persons attached to a (at least previously) respected institution, many such patches have been accepted.

Greg Kroah-Hartman called them out in this LKML thread, and all the patches from these submitters are now being summarily reverted.

Also, it seems the entire university will be banned from participating in Linux kernel development from now on.
 
Old 04-21-2021, 09:18 AM   #2
floppy_stuttgart
Member
 
Registered: Nov 2010
Location: EU mainland
Distribution: Debian like
Posts: 908
Blog Entries: 4

Rep: Reputation: 86
Penetration testing and fooling people is a very very serious topic.
They probably should have done this differently:
a) identify a testified organization preferably observed by lawyers in a serious country
b) inform the linux org lawyers of the try to penetrate linux forums: the target is not to fool and demonstrate they are idiots but should demonstrate this is for making them better
c) make the penetration
d) show to them the area of improvement
e) make it public afterward
The university have not followed the steps (or similar serious steps?) and would show to me only I am a fool?
I would throw them out and ban them.. (I want to improve.. not that people show to me I am a fool).
 
Old 04-21-2021, 09:33 AM   #3
boughtonp
Senior Member
 
Registered: Feb 2007
Location: UK
Distribution: Debian
Posts: 1,341

Rep: Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133
Quote:
Originally Posted by Ser Olmy View Post
As these submissions come from persons attached to a (at least previously) respected institution, many such patches have been accepted.
That's rather worrying - I would have expected code reviews on all submissions, irrespective of their email address!

 
Old 04-21-2021, 09:48 AM   #4
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,063

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by boughtonp View Post
That's rather worrying - I would have expected code reviews on all submissions, irrespective of their email address!
Of course, and the intentionally introduced bugs were eventually caught. But one can see why a patch from a known CS graduate at a US university might be subject to a bit less scrutiny than a patch that appears out of the blue from "random_dude@gmail.com".

I believe the main issue is that the UoM project is being conducted in a way that violates the most basic ethical standards. In the course of their "research", they actually introduced serious vulnerabilities in the Linux kernel.

Had they followed the practices outlined in this paper, at least the commits wouldn't actually have been applied. But they didn't.

For their next project, perhaps they should write a paper on "the Feasibility of Stealthily Introducing Vulnerabilities in Closed-Source software via malicious insiders"? Some of their students could apply for coding jobs at Microsoft, and then push carefully crafted security bugs into the Windows kernel.
 
Old 04-21-2021, 10:33 AM   #5
boughtonp
Senior Member
 
Registered: Feb 2007
Location: UK
Distribution: Debian
Posts: 1,341

Rep: Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133Reputation: 1133
Quote:
Originally Posted by Ser Olmy View Post
But one can see why a patch from a known CS graduate at a US university might be subject to a bit less scrutiny than a patch that appears out of the blue from "random_dude@gmail.com".
One might, but I can't. No patches applied without understanding what they do.

Perhaps, if I received an expected patch from Linus Torvalds (or another core committer), I might give benefit of the doubt and apply it before seeking to comprehend it. Perhaps.



Quote:
I believe the main issue is that the UoM project is being conducted in a way that violates the most basic ethical standards. In the course of their "research", they actually introduced serious vulnerabilities in the Linux kernel.

Had they followed the practices outlined in this paper, at least the commits wouldn't actually have been applied. But they didn't.
Had they followed those practices, we probably wouldn't be discussing this.

Had the maintainers applied their usual high standards and caught them all before they reached stable, we also wouldn't be discussing this.

(Unless they did apply their usual standards, and they're not as high as we would hope!)

Either way, the lapse which alarms me more is on the kernel side.


Quote:
For their next project, perhaps they should write a paper on "the Feasibility of Stealthily Introducing Vulnerabilities in Closed-Source software via malicious insiders"? Some of their students could apply for coding jobs at Microsoft, and then push carefully crafted security bugs into the Windows kernel.
Or maybe they already are. If I worked at Microsoft I'd be having all commits from recent new hires checked by independent teams. Imagine the PR boost if they were able to say they found such an attempt before anything got through. :/

The paper also explicitly mentions FreeBSD, Firefox, and OpenSSL - let's hope their organisations are now exercising increased diligence.

 
Old 04-21-2021, 11:28 AM   #6
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 5,612
Blog Entries: 3

Rep: Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859
The student's whiny response after having gotten caught does not help the situation. Furthermore, there seems to be a "research" paper, posted at an infamous M$ site, about trolling several big name projects with crap, deceptive code submissions. In addition to the kernel, FreeBSD, Firefox, and OpenSSL get named. So those projects also ought to go back and recheck for any University of Minnesota patches.

There are also usually ethical rules which psychological experiments such what this appears to be must adhere to most strictly. There are also similar guidelines for security research, especially penetration testing. Those also seem to have been ignored, at least at first glance. Looking at one article and at Greg's e-mail to the list, it is likely that the University of Minnesota could have been in violation.

( Edit: it seems that the list covered that : https://lore.kernel.org/linux-nfs/3B...theastern.edu/ )

It is something that is worth taking upstream. That department needs an audit for compliance with both sets of guidelines and, while the hood is up, faculty member or student ties or allegiances to M$ should be ferreted out.

Last edited by Turbocapitalist; 04-21-2021 at 01:05 PM.
 
Old 04-21-2021, 11:46 AM   #7
cynwulf
Senior Member
 
Registered: Apr 2005
Location: Walsall, UK
Posts: 2,631
Blog Entries: 7

Rep: Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151
Quote:
Originally Posted by boughtonp View Post
That's rather worrying - I would have expected code reviews on all submissions, irrespective of their email address!
+1

The most important thing to come out of this is that those patches were committed - and that highlights that code reviews are inadequate. The response, in terms of banning those involved doesn't address the problem at all.
 
1 members found this post helpful.
Old 04-21-2021, 11:47 AM   #8
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,063

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by boughtonp View Post
No patches applied without understanding what they do.
Well, no-one did that.

Have you seen the patches in question? The ones I've looked at all seem to do something pretty trivial. The vulnerability is either hidden in some other alteration you're meant to overlook, or it follows as a side effect under very specific circumstances. Like the stuff you'd find in The Underhanded C Contest back in the day.

And still they did get caught, just not right away.
Quote:
Originally Posted by boughtonp View Post
Had they followed those practices, we probably wouldn't be discussing this.
Do you believe the Linux developers have some incentive to keep using a bad review practice if someone were to demonstrate deficiencies in their processes?
Quote:
Originally Posted by boughtonp View Post
Had the maintainers applied their usual high standards and caught them all before they reached stable, we also wouldn't be discussing this.
I'd like to see the practices and standards that cannot be subverted by a malicious actor under any circumstances.

I mean, it's obvious that large companies like Microsoft, Red Hat, Oracle, SAP, and IBM aren't immune to this, as vulnerabilities caused by basic programming errors like buffer overflows, wrong typecasting, and insufficient input sanitation keep turning up in their products.

I'd say the Linux kernel has a pretty decent track record compared to the industry leaders. Compared to a utopian ideal we'll never achieve they still fall far short, of course.
 
Old 04-21-2021, 11:59 AM   #9
Jan K.
Member
 
Registered: Apr 2019
Location: Esbjerg
Distribution: slackware...
Posts: 258

Rep: Reputation: 176Reputation: 176
Quote:
Academic research should NOT waste the time of a community.

If you believe this behavior deserves an escalation, you can contact the Institutional Review Board (irb@umn.edu) at UMN to investigate whether this behavior was harmful; in particular, whether the research activity had an appropriate IRB review, and what safeguards prevent repeats in other communities.
They should be hunted to the edge of the world...

The referenced "paper" seems to have disappeared? Any alternative link?


There's something rotten in the state of... Minnesota.
 
2 members found this post helpful.
Old 04-21-2021, 12:18 PM   #10
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_12{.0|.1}
Posts: 5,616
Blog Entries: 11

Rep: Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655Reputation: 3655
While I agree that the kernel maintainers need to at least review and probably adjust how they accept patches and from whom, the kernel itself and the network of contributors is almost certainly too complex to rely on any "policy" as the filter of last resort. Malicious actors profile the policies as much as the code and the people and there is always going to be some exploitable path to be found. KUDOS to GKH for calling this one out.

I think that in such cases it is of utmost importance to call this what it is - INTENTIONAL MALICIOUS ATTEMPT TO SUBVERT software used by millions in many diverse and doubtless assorted critical applications. Stop calling it research, or penetration testing (another weasle-speak term) or anything of the sort... in ANY other realm it would be considered CRIMINAL activity and should be treated as such. The professor, so-called, behind this activity has apparently promoted this very activity in the past and definitely needs to suffer some consequences! The students involved need to be reprimanded and sent to a remedial ethics training course.
 
Old 04-21-2021, 12:26 PM   #11
Jan K.
Member
 
Registered: Apr 2019
Location: Esbjerg
Distribution: slackware...
Posts: 258

Rep: Reputation: 176Reputation: 176
Quote:
Originally Posted by Jan K. View Post
The referenced "paper" seems to have disappeared? Any alternative link?
Scratch that as the page doesn't show error anymore... https://github.com/QiushiWu/QiushiWu...Insecurity.pdf
 
Old 04-21-2021, 12:43 PM   #12
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,063

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Jan K. View Post
Scratch that as the page doesn't show error anymore... https://github.com/QiushiWu/QiushiWu...Insecurity.pdf
...and it has been archived as well, just in case.
 
Old 04-21-2021, 03:27 PM   #13
Jan K.
Member
 
Registered: Apr 2019
Location: Esbjerg
Distribution: slackware...
Posts: 258

Rep: Reputation: 176Reputation: 176
In the meantime I've now read that paper...


But has there ever been committed and merged "evil" code in the history of Linux?

That is, before this...


Excerpts from the paper...

Quote:
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. 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 ernel, and none of the Linux users would be affected.
Well... then I don't understand why Greg sits there with a list as long as his arm of commits to be re-reviewed and/or reverted...


Quote:
ACKNOWLEDGMENT
We would like to thank Linux maintainers for reviewing our patches and the anonymous reviewers for their helpful suggestions and comments. We are also grateful to the Linux community, anonymous reviewers, program committee chairs, and IRB at UMN for providing feedback on our experiments and findings. This research was supported in part by the NSF awards CNS-1815621 and CNS-1931208. Any opinions, material are those of the authors and do not necessarily reflect the views of NSF
Not so sure the maintainers are entirely pleased with having to take a second view of the commit procedures, but that's probably the best outcome of this...?

But as initial asked: is there really a problem with malicious commits?
 
Old 04-22-2021, 01:24 AM   #14
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 17,237
Blog Entries: 10

Rep: Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160
Quote:
Originally Posted by Ser Olmy View Post
The Linux kernel is currently the subject of some University "research" that apparently seeks to prove that "Open Source" software is inherently insecure.

The "researchers" attempt to demonstrate this by submitting malicious kernel patches to the Linux Kernel Mailing List. As these submissions come from persons attached to a (at least previously) respected institution, many such patches have been accepted.

Greg Kroah-Hartman called them out in this LKML thread, and all the patches from these submitters are now being summarily reverted.

Also, it seems the entire university will be banned from participating in Linux kernel development from now on.
So... their research proved that they are capable of criminal behavior.

That said, it is worrying that submitted kernel patches aren't necessarily fully scrutinized.

Last edited by ondoho; 04-22-2021 at 01:20 PM.
 
Old 04-22-2021, 02:15 AM   #15
cynwulf
Senior Member
 
Registered: Apr 2005
Location: Walsall, UK
Posts: 2,631
Blog Entries: 7

Rep: Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151Reputation: 2151
Yes it helps to read the paper itself.

I don't believe that anyone should be criminalised for exposing what they have exposed - i.e. that code review audits need improving. Especially with regards to an important project such as Linux.
 
  


Reply

Tags
kernel, security


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Sir please help me ... please reply quickly sir Dharma Linux - Newbie 10 02-18-2020 06:22 AM
LXer: Sir, You Are Being Hunted FPS Stealth Game Hits The Big Release For Linux LXer Syndicated Linux News 0 05-04-2014 08:20 PM
LXer: Adobe: Thank you sir. May I have another? LXer Syndicated Linux News 0 06-15-2011 04:20 PM
LXer: Twenty Bucks Thank You Sir May I Have Another LXer Syndicated Linux News 0 12-03-2009 08:00 PM
LXer: Sir Bill and Sir Tim: A Tale of Two Knights LXer Syndicated Linux News 0 07-02-2008 12:00 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 01:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration