The whole thing reads like what I see on some social platforms.
Here's the exchange between Aditya Pakki, who is a Ph.D. student of Computer Science and Engineering at UMN, and Greg Kroah-Hartman. Pakki had written:
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.
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.
To which Greg Kroah-Hartman has responded:
You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work.
Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing?
They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches?
When submitting patches created by a tool, everyone who does so submits them with wording like "found by tool XXX, we are not sure if this is correct or not, please advise." which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect.
A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid "fix" is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create.
Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way.
Our community does not appreciate being experimented on, and being "tested" by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.
Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems.
that I wrote and it's sensitivity is obviously not great
On an almost complete non sequitur, is it really that hard for a PhD to spell "its" (possessive) correctly, rather than using "it's" (contraction of "it is")?
that I wrote and it's sensitivity is obviously not great
On an almost complete non sequitur, is it really that hard for a PhD to spell "its" (possessive) correctly, rather than using "it's" (contraction of "it is")?
If you are going to do something like that, you should contact first an officer of the project you are going to send faulty patches to. Otherwise you can't make the difference between bad actors and good actors. And you need tracability back to the bad commits to remove them afterward.
Agreed. This could have been a valuable research project if they had handled it correctly. But instead, they seemed to opt for the sleaziest way of handling things, with a "better to ask for forgiveness than for permission" attitude. After all, the maintainer might have said "no".
Now that this has come to light, maybe someone will be taking a closer look at the ethics board that rubber-stamped this idiocy. It deserves to be censured. Of course, given the apparently weak grasp on ethical behavior, maybe no one there will give a shit.
What's particularly disgusting to me is how the Ph.D. student turns around and *attacks* the kernel maintainers, accusing them of making false accusations and acting in an unfriendly and intimidating manner. I mean, damn, once the game is up, at least have the decency to acknowledge what you were doing, and apologize for any inconvenience. These people are without any shred of ethics, and deserve their ban. And the University of Minnesota deserves shame for allowing it to happen.
Personally, I believe that's a bullshit cover story. I'm curious what makes you believe it. It was neatly taken apart by Greg Kroah-Hartman. That "static analysis" claim looked suspicious to him due to the varied nature of the issues "caught " Moreover, most static analysis doesn't fix issues automatically. And even then, they were actually introducing bugs? No one reviewed or caught the errors before submission? The developer in question is either negligent, incompetent, or lying. There's really no other choice here.
At the very least, being affiliated with a group that has intentionally introduced bugs in the Linux kernel, the burden falls on this student to demonstrate exactly how that particular static analysis tool found and subsequently introduced bugs, without any review that caught obvious errors being introduced. Let's see a reproduction of the process, which he should easily be able to do if this is a valid research project. Of course, if my suspicion is correct, there's no way he can do that.
Were I so accused, I would reproduce exactly how these mistakes occurred, and I'd be a hell of a lot more apologetic for introducing bugs instead of turning around and attacking the maintainer. Even if he were innocent, which I very much doubt, the kernel developers are well within their right to ban them on sheer incompetence or negligence. Imposing a public and embarrassing sanction against the entire university is the best way to prevent this sort of nonsense from happening again at a different university.
Nope, sorry. Not buying it for a nanosecond. The Linux kernel development community will do just fine without these guys.
Unfortunately, pretty much everything you wrote is wrong.
GregKH claimed: "You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work."
Yes, GregKH claimed that, and it is an entirely factual statement. It bears noting that the very next sentence from GregKH in that same message is "Now you submit a new series of obviously-incorrect patches again, so
what am I supposed to think of such a thing?"
Funny how that sentence provides the actual context. I can see why you omitted it.
But Aditya Pakki in fact is in a different group, working to find and fix bugs via static analysis.
No, Aditya Pakki in fact is in the same group as Kangjie Lu (assistant professor) and Qiushi Wu (PhD student), authors of the paper mentioned by GregKH. Pakki claims to be working to find and fix bugs via static analysis, but there is no "group" at UMN doing that. It's just him.
Here [umn.edu] is professor Kangjie Lu's page at UMN. You will note that Aditya Pakki's name appears alongside Lu's as an author of four papers listed on Lu's page.
Just because Pakki wasn't a named author of the Lu/Wu paper doesn't mean he's not in the same group as Lu/Wu. He quite clearly is. They are all systems security researchers working under the same assistant professor in the same floor in the same building in the same academic department at UMN.
So that is already wrong, and directly accusing the student of malicious intent is very wrong.
In this message [kernel.org] on the mailing list, Leon Romanovsky says:
Yesterday, I took a look on 4
accepted patches from Aditya and 3 of them added various severity security
"holes".
Those spurious "patches" don't include the patch Aditya Pakki submitted that reintroduced a old vulnerability and kicked off the entire shitstorm.
The original Lu/Wu paper was published months ago, and the linux devs made their displeasure known about the methods employed by the researchers. It completely stretches credulity to think that Pakki believed he wasn't doing anything wrong by pushing yet another bogus "patch" into the pipeline months later.
So I understand the student's reaction.
Your understanding is based on faulty assumptions/reasoning. Maybe you should try understanding the reactions of the expert devs whose valuable time was wasted by this "researcher".
Unfortunately, the student is now being hounded by an angry mob, apparently fired up by someone who should know better.
Uh huh. Are there linux devs hounding or harassing Pakki? What's your proof that Aditya Pakki is being hounded by anyone? Or is this just something you think might be happening?
IMO, the Linux development community has every right to be angry. These UMN "researchers" acted unethically and possibly criminally. If the only consequences they face as a result of their behavior are some nasty e-mails, they should consider themselves lucky.
Where does the Linux kernel community get its supply of new developers? Primarily from universities just like this one.
Now, what student is going to want to get anywhere near the kernel community?
Hopefully students will learn a valuable lesson from Aditya Pakki's actions and only contribute code that actually fixes bugs instead of introducing or reintroducing them for the purposes of their "research".
None of which is "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits".
So what? The UMN "group" is assistant professor Lu, 5 PhD students, 3 master's, and one undergrad. Aditya Pakki [github.io] and Qiushi Wu, [github.io] whose name IS on the paper, share the same damn office.
There is absolutely nothing inaccurate about GregKH saying they are in the same "group". You have to be severely mentally challenged to believe otherwise.
He said as much, but you have your fingers in your ears.
LOL! Fingers in my ears? Your head so far up your ass you have to peer through your navel to see anything at all, and your ears are so clogged with your own shit you
Oh, it's worse than that. It's not good research if there are biases in the study that cannot be allowed for.
In other words, you cannot determine ahead of time the desirability or aversion to patches from UMinn, so it is not fully randomised. Since the level of aversion changes unpredictably with each faulty submission, you can't correct for it. As different projects do different levels of code review, and as you can't know the precise level any given patch gets, you can't make any generalized conclusion from this one attack.
So as a study, it's absolutely useless. It tells you nothing about the ability to insert malicious code into open source software. All it tells you is that someone involved was either a paid schill for a rival OS (and it's probably not going to be Theo) or that the UMinn is simply not capable of credible research. This is Utah's Cold Fusion level of gross incompetence.
The one thing they might have got right, being a university, they got wrong. But at least they got the full set.
Greg Kroah-Hartman, right to the throat on that one. A very good response to this kind of bullshit. The *plonk* at the end was just the icing on the cake.
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
Note to anyone. Anything in bad faith means that "benefit of the doubt" is no longer an option for you. That's literally something applicable in legal proceedings as well as pretty much every social norm. Fuck this university with a firepole.
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
No. You know what? The firepole is being too nice.
Greg is Linus's designated successor. He's been taking over more and more of what Linus used to do.
Being Linus junior, I suspect he's not all THAT concerned about offending some college student who admits they intentionally tried to put bugs in the kernel.
How do you think his co-worker/mentor Linus Torvalds would have handled it?
Many many moons ago, I actually submitted a patch for a driver via Alan Cox... It was for the driver for the Apple/Farallon LocalTalk PC card, which was an 8 bit ISA card that allowed PC machines to connect to Apple LocalTalk networks. I was a complete noob and knew nothing about the kernel, but figured out this oddity in the driver that wasn't quite right. If I recall, it was a case of something being a "" comparison, rather than "=" or similar. Anyhow, it's my one contribution to the kernel, which is lon
Whining about politics is neither necessary nor appropriate here.
My understanding is the linux community does have standard practices for novices who want feedback on their own uncertain work. To push such things as genuine fixes of "something" without an accompanying analyst to explain their reasoning is unethical and unprofessional. Sadly, it fits the stereotype of people whose inferior skills makes them unfit for industry, yet somehow they slip into academics.
But the 'research paper' was a success in having a very definite outcome. I bet they get an A - wait do they still give out grades or just participation trophies?
I'd like to see what ethics committee signed off on this. It's more likely this guy cut a few corners with his research methodology and deserves whatever happens as a result.
They know nothing about the risks of OSS. They failed to randomise variables. They failed to determine how biases vary according to stimulus, other than observing that they do. They failed to determine differences in code review practices between projects. There's no obvious methodology. There's no obvious baseline. There's no way of measuring degree of success. The experiment is unrepeatable. The hypothesis (if there even is one) is unfalsifiable.
For that, I'd want the supervisor forced to do six months hard labour as primary school janitor.
That's a pretty bad ethics violation, and a fairly reasonable response.
It might be a bit worse than that.
IANAL (or even a U.S. citizen), but they're in the U.S. so this https://www.law.cornell.edu/us... [cornell.edu] may be applicable.
"(5)
(A) knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;"
If their problematic patched ended up in an actual production computer, this section of the Computer Fraud and Abuse Act might cause them trouble...
If were an experimental psychologist working at a university who conducted an experiment on human participants without consent, you would very likely be fired (at best); probably fired, sued, and possibly charged criminally.
OTOH, if you're a computer scientist at the UMN you can conduct experiments on human participants without consent and everything is fine?
Considering Linux *does* run under the hood of a bunch of "critical infrastructure" and a whole lot of heavy moving machinery, you're not as far off as you think.
A crap ton of phones run linux. If you're relying on them to be able to call 911...they're critical for you.
A lot of government and medical software runs on servers running some flavor of linux.
I could go on.
Yes it is sabotage and yes it is as bad as cutting and weakening bolts or rebar shipped to a construction site.
The probability of a bug getting past an audit is given by the probability of the auditor missing a bug multiplied by the probability of there being a bug in the first place.
An adversary deliberately introducing bugs increases the latter quantity, thereby increasing the overall probability of a bug in the finished product.
Let me try a car analogy: if I break into Pep Boys overnight and score the inside of every fourth tire with a knife...is it your fault for not personally inspecting every tire you bought from there that you end up with a flat?
If you blindly put untested and unaudited code into critical systems then the burden is on YOU, not the author.
Let's see if that makes sense if we turn it into a baking analogy: If you blindly put untested ingredients into a cake, then the burden is on YOU, not the maker of the ingredient. We'll say the ingredient is flour and the maker of the flour concealed rat poison in it, doing their best to make it look like regular flour. Someone eats the cake and dies... I would say that the assertion does not hold water there.
How about a Halloween candy analogy: If you blindly let your kids eat untested Halloween candy, the
> Yeah bad software caused the meltdown. Not someone ignoring safety protocols and procedures...
There's an old/.er around here who was there when it happened. He says it was a Masters project of the son of one of the Kremlin's upper crust and despite all the warnings of the people at Chernobyl, he overrode them and they ran the kid's code. Boom.
For whitehat pentesting to be legal, ethical and, well whitehat you have to reach agreement with client first. You cant just take it upon yourself to carry out the test without notifying anyone and then claim it was for research. How are the maintainers to know that this wasn't actually malicious? Just because it came from a university? Its as if they had never heard of disgruntled employees or compromised accounts before.
They deserve their ban. This isn't how these things are done and it displays a shocking amount of recklessness and arrogance from their computer science department to think that was acceptable.
That's not necessarily true. If I stumble upon a hole and let you know about it privately, that's white hat hacking even without a prior agreement. It's probably illegal, but it's white hat.
No, that's bug fixing. "Stumble upon a hole" is different to "actively probing and looking for holes". In this case, they weren't even doing that - they'd taken a flaming shovel and started creating their own holes to crow about.
Stumble upon is different than actively seeking. I see ?customerId=12341 in your URL and think gee what if I change it to 12340. That might be stumbled upon. Its right there in front of my face.
I try tampering with one of the 20 parameters in your JWT and find 18 enjoys some kind of signature exclusion that is a little different.
I said pentesting. Finding existing exploits in the wild and reporting them is a related but different process. Pentesting isn't always directly testing infrastructure against known exploits, sometimes its testing the people and bureaucracy.
That's what happened here. The authors performed a test on how well the Linux kernel maintainers guarded against malicious commits. On its face that's a valid test. But for it to be a test and ethical you would have to do it above the board. Contact Linus and plan it out
Sadly its pretty often how things are done in the 'whitehat' security community.
First there is incredible pressure to 'get you name out there' by finding and publishing something. That is how you get the good jobs, as opposed to the ones where you grind your life away watching logs as first level person in some SOC (sorry if I hurt anyone feelings)/
Second, lets be completely honest the people attracted to pentesting typically have some personality quirks. Most people don't actually enjoy trying to do things they are not supposed to do and seeing if they can break stuff all day long. There is an "i want to watch the world burn" element to most of these guys and they cheer and clap for each other when something visible happens. So there is a positive feedback loop that pushes recklessness behavior.
and yet people go into psychiatry typically for one of two reasons: 1) they are trying to diagnose themselves, secretly of course. 2) they are trying to diagnose family members. Never trust a shrink, they have too many skeletons they are trying to hide. Hence all the projection they are guilty of.
Some years ago, I had a conversation with a Harvard undergrad who was pre-med, planning on going into psychiatry. Her parents were both Harvard med shrinks themselves, and her motivation apparently was to show them up by exceeding their academic record, and prove to them once and for all that she was smarter than they are, etc. Wanting to help the mentally ill didn't even come up. She really creeped me out.
I know a guy whose parents were both psychiatrists. He is the second most damaged human being I have never known. He literally can't function as an adult without mood stabilizing medication.
You can't become a psychiatrist without being treated by one. And the profession, as a whole, believe that 1/3 of all people should be on psychiatric drugs at any given time. They're all crazy because they make each other crazy.
No, but they may have had other real world consequences. Disinformation is quite dangerous, as we saw (again) on Jan 6 in the attack on the US capital. If you modify Wikipedia falsely, given how much people use it with blind trust, you can start an awful lot of bad processes going.
Wikipedia has a unique problem. If a news source reports misinformation they got from Wikipedia, that reporting can then be used to justify the continued inclusion of that misinformation!
Thanks to Wikipedia and lazy reporters, one troll's lie can become common knowledge, assumed by the masses to be gospel truth.
..I think open source software has a problem defending against malicious contributions. I am not sure the kernel development team's response shows that they can handle this..some commits were already accepted into stable tree apparantly..
It's not clear that all the commits were malicious or buggy. As I read it, all contributions from the University are being ripped out as a cautions measure. How can you be sure that there wasn't something you missed?
OTOH, it's also true that some bugs have persisted for decades. This can be documented for Linux. For commercial OSes, who knows? I tend to expect, based on lots of prior events, that they have a much larger number of unfixed bugs, but that *has* to be an assumption. The only groups that h
Eventually the whackjobs will provoke blowback but that will take years because the community is full of freaks who washed up there looking for a place to influence, not a place to contribute quality code.
FOSS like everywhere else has a problem with people who throw tantrums. The proper response to tantrums is a brutal smackdown followed by shunning but weaklings won't do that.
Universities absolutely have such regulation, as does every research institution in the US. There are federal laws that apply here. In the first place, this kind of research must be reviewed and approved by the Institutional Review Board (IRB). Based on what they did I can't imagine that there is an IRB in the US that will approve this. The main mission of IRBs is to protect the research subjects. My experience with IRBs is that they are dead serious about that. So these "researchers" either did not get approval from the University of Minnesota IRB or their protocol dramatically deviated from the protocol that was approved.
The linux kernel team should contact the university IRB. This guy and whoever supervises him are looking at a life long ban on receiving federal research funding or working at a public institution.
I also love how his email starts with "I respectfully ask you..." and immediately descents into disrespectful and abusive demands and accusation. How could have as well started with "Hi, I am a sociopath..."
They did get approval from IRB according to their research paper: https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.io/main/papers/OpenSourceInsecurity.pdf
Regarding potential human research concerns. This experiment studies issues with the patching process instead of individual behaviors, and we do not collect any personal information. We send the emails to the Linux community and seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of Universi
If this is the reasoning behind them being exempted, then they both lied to the IRB and omitted information.They seem to say that there is no injury to the privacy of the individual and they do not discuss causing harm in any other way. The first one is obviously false because maintainers can be personally identified as responsible for allowing the malicious patches, regardless if they are named or not. You just need to check the publicly available logs. Introducing security bugs into the Linux kernel and l
I've also done IRB-approved human subjects research and IRBs' role is critical, even if interacting with them is sometimes frustrating. My guess is that these researchers either decided that the IRB stuff was BS or didn't really understand the human implications of what they proposed to do (lie to their subjects to inject vulnerabilities into software used on billions of devices), then gave highly CS-ish answers to a group of people who mostly deal with biomedical research.
This experiment had even more worth than was intended. It demonstrated the weakness of large open source projects from their dependence on unstated assumptions. The world is not made up of milk and honey, and the need for actual security against organized sabotage has made the multiple contributor model obsolete.
While I agree that yes, there are potential security vulnerabilities in the open source model, this is absolutely positively not the way you test for this.
They were adding documented exploits to an active project. A project that happens to run on a wide gamut of devices and infrastructures ranging from the least to most secure.
Now imagine if that documented exploit got into the wild, on less maintained firmware such as an IOT device, then sold to the highest bidder.
No it hasn't, it's demonstrated that they were able to leverage the goodwill established by static analysis tools making minor changes without serious incidents for years and use this as a way to shoehorn in innocuous-looking bad changes submitted under an assumed good faith basis. Add to that the fact that many maintainers are more willing to be relaxed about receiving largely cosmetic patches from first-time contributors, and it's easy to see how some of these made their way in. These people have now singlehandedly burned through all of that goodwill and set back both academic research in static analysis tools and the initial hurdle required for first-time contributors. The unethical conduct of the researcher is certainly not going to help his future academic life, though perhaps he'll settle into a white hat firm that doesn't care about ethical considerations.
I'm not joking, this is a solution they propose [github.com] to address the problem of malicious patches.
We believe that an effective and immediate action would be to update the code of conduct of OSS, such as adding a term like “by submitting the patch, I agree to not intend to introduce bugs.”
That's brilliant! Maybe we could have a thing so when you get a driver's license, you have to sign a form agreeing not to commit a violent crime? That would solve the crime problem! They're geniuses!!
Of course, we'd then be very suspicious of people who don't drive... but at least they couldn't flee the scene of the crime quickly.
That's brilliant! Maybe we could have a thing so when you get a driver's license, you have to sign a form agreeing not to commit a violent crime? That would solve the crime problem! They're geniuses!!
Of course, we'd then be very suspicious of people who don't drive... but at least they couldn't flee the scene of the crime quickly.
Not true.... ever hear of a getaway driver... there is a glitch in the matix.....grin.
Ric Flair went to the University of Minnesota. His shtick was to put out his hand to shake his opponent's and then kick them in the nuts. Must be part of the curriculum there.
I certainly hope someone from the linux kernel contact the university to figure this out. There should have been an IRB process. And I can't believe the IRB would ok that research without expert/external supervision.
UMN and the Linux Kernel team could have very justifiably written up the incident and then passed it onto the FBI or DHS. Pen testing without authorization is a felony; trying to inject vulnerabilities into something as strategic as Linux to the US economy is a great way to have agents from DHS out at your house for attacking critical infrastructure.
This pretty typical in the "whitehat" hacking circles and the infosec space as a whole. Rather than trying to fix things, the biggest focus for a large portion of the whole community is to draw as much attention as possible to themselves. Be it by exaggerating found vulnerabilities, not following accepted public disclosure guidelines, using systems by unwitting participants as guinea pigs and just generally not caring about the damage caused.
In other words a large portion of the community consists of attention hungry narcissists with a complete lack of professionalism. It describes these people in particular pretty well as they pushed bad patches specifically to the project that would net them the most attention when they could easily have proven their point with another project that had much less potential for serious damage. When caught trying to push more bad patches they of course denied and tried to accuse Greg and the kernel community of being racists for seeing trough their obvious ruse.
Linus has gone on record saying that he thinks the entire security industry is rotten. They are just more interested in shenanigans than actually trying to improve the situation. It's like, no shit Linux has security problems, and also not magically immune to social engineering attacks. If they really wanted to help, they should have studied how much money depends on Linux being secure in all facets (code, and management).
I mean, they intentionally injected flaws in software they had no permission to do so, I believe (although I'm might be mistaken) that this is in violation of the Computer Fraud and Abuse Act of 1984.
Linux is used by "protected computers" as defined by the act (by government and financial institutions), and introducing flaws intentionally would be considered damage to those systems.
If all they get is banned from the kernel and a couple OSS projects, they got it easy. I think the should see prison time.
Also, I don't get how an ethics committee approved this in the first place.
It's not a 'reaction', it is a 'stall for time'. This is the Computer Science Department, not HR - they, more than anyone understand the situation, implications, and consequences. Once they got their first whiff of this, their response should have been we have recused ourselves and reported the incident to DHS/DOJ.
... Congress also added a provision to penalize those who intentionally alter, damage, or destroy data belonging to others. This latter provision was designed to cover such activities as the
Obvious problems there are that whether there is direct experimentation on humans or not, people are, by definition, involved in the process - people that were not aware of what activity was being carried out, and which certainly were not in a position to offer informed consent to participate. Ignoring the human element, there's also the case that the patcher is knowingly inserting bad changes and that these are being presented on a presumed good faith basis. Static checkers can and do break things by faili
They got exemption from "Human Subject Research" regulation because they are not collecting personally identifiable information. The is a pretty standard reason for getting an exemption. It is obvious that they were lying to the IRB and hiding relevant infomration: i) despite their claims to the opposite, maintainers can be linked to patches as all patches are documented - direct harm to the maintainer that let the patch in; ii) they do not reveal the significant impact bugs in the linux kernel can have on
I expect a lot worse is going to happen to this student and advisor than being banned from the kernel. They were gaming the IRB the same way they were gaming the kernel developers. But even then the IRB appears to be broken because this should have been realized. There is no universe in which this is "not human research". That phrasing is itself deceptive. As far as I know the relevant standard is whether or not it "involves human subjects", which it obviously does. One has to get IRB approval to even
1. The IRB had no idea what was involved in the experiment, thinking it was testing some sort of software testing framework instead of people
or
2. The researchers couched their proposal in terms that made it seem like no humans would be involved in the test
If the IRB was fully aware of what the researchers were doing, then every professor on the board should be permanently banned from holding that position again and reprimanded, as they allowed experiments to be conducted on human partici
We need a freaking IRB to interview people about what they think of a user interface or how the user interface should be modified and we need to inform them of that before the interview can begin.
Now it would be hard to inform each person individually. But seeking consent from a leader in the community would seem necessary.
Well, yeah. An IRB *only* cares about protecting human subjects. That's the sole reason they exist. It doesn't really matter what you do. If you have human subjects, you get approval from the IRB.
There are other ethical considerations that should have been addressed in the case in TFA, but those aren't the IRB's concern.
Good point. Plenty of people getting salty that it was proven true. Heartbleed was around for years before it was discovered that "many eyes" actually meant zero.
Did you actually read the email? GKH offered good reasons to doubt that the patch resulted from static analysis or at the least that no human had even bothered to review the patch before sending it in.
If you're going to submit a patch, the LEAST you should do is review it carefully and run with it on your own machine first.
If you want to have similar fun (but more serious consequences), try calling 911 and immediately alerting the emergency personnel that it was a false alarm when they get there (worst Apri
"Oh what wouldn't I give to be spat at in the face..."
-- a prisoner in "Life of Brian"
speaking of hypocrites (Score:5, Informative)
That's a pretty bad ethics violation, and a fairly reasonable response.
Re:speaking of hypocrites (Score:5, Informative)
The whole thing reads like what I see on some social platforms.
Here's the exchange between Aditya Pakki, who is a Ph.D. student of Computer Science and Engineering at UMN, and Greg Kroah-Hartman. Pakki had written:
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.
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.
To which Greg Kroah-Hartman has responded:
You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work.
Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing?
They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches?
When submitting patches created by a tool, everyone who does so submits them with wording like "found by tool XXX, we are not sure if this is correct or not, please advise." which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect.
A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid "fix" is totally negligent on your part, not ours. You are the one at fault, it is not our job to be the test subjects of a tool you create.
Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way.
Our community does not appreciate being experimented on, and being "tested" by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here.
Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems.
*plonk*
Re:speaking of hypocrites (Score:4, Insightful)
On an almost complete non sequitur, is it really that hard for a PhD to spell "its" (possessive) correctly, rather than using "it's" (contraction of "it is")?
Re: (Score:2)
As my father used to say, "Sometimes, a PhD just means you're a well educated idiot."
Re: (Score:3)
We used to know them as "post hole diggers"
Re:speaking of hypocrites (Score:5, Funny)
On an almost complete non sequitur, is it really that hard for a PhD to spell "its" (possessive) correctly, rather than using "it's" (contraction of "it is")?
Its difficult.
Re: (Score:3, Insightful)
It is an easy mistake to make.
Bullshit.
Re: speaking of hypocrites (Score:2)
Not quite.
her .. hers .. hes .. his .. its
he
it
It is perfectly logical, although hes changed over the years.
(although hes and his sound the same, with older British accents)
Re:speaking of hypocrites (Score:5, Funny)
It is an easy mistake to make.
No its not.
Re:speaking of hypocrites (Score:5, Insightful)
If you are going to do something like that, you should contact first an officer of the project you are going to send faulty patches to. Otherwise you can't make the difference between bad actors and good actors. And you need tracability back to the bad commits to remove them afterward.
Re:speaking of hypocrites (Score:5, Insightful)
Agreed. This could have been a valuable research project if they had handled it correctly. But instead, they seemed to opt for the sleaziest way of handling things, with a "better to ask for forgiveness than for permission" attitude. After all, the maintainer might have said "no".
Now that this has come to light, maybe someone will be taking a closer look at the ethics board that rubber-stamped this idiocy. It deserves to be censured. Of course, given the apparently weak grasp on ethical behavior, maybe no one there will give a shit.
What's particularly disgusting to me is how the Ph.D. student turns around and *attacks* the kernel maintainers, accusing them of making false accusations and acting in an unfriendly and intimidating manner. I mean, damn, once the game is up, at least have the decency to acknowledge what you were doing, and apologize for any inconvenience. These people are without any shred of ethics, and deserve their ban. And the University of Minnesota deserves shame for allowing it to happen.
Re:speaking of hypocrites (Score:5, Insightful)
What's particularly disgusting to me is how the Ph.D. student turns around and *attacks* the kernel maintainers ...
I imagine the guy's thesis is on the line -- and *that's* what he cares about, not Linux or the patches per se.
Re:speaking of hypocrites (Score:4, Insightful)
Personally, I believe that's a bullshit cover story. I'm curious what makes you believe it. It was neatly taken apart by Greg Kroah-Hartman. That "static analysis" claim looked suspicious to him due to the varied nature of the issues "caught " Moreover, most static analysis doesn't fix issues automatically. And even then, they were actually introducing bugs? No one reviewed or caught the errors before submission? The developer in question is either negligent, incompetent, or lying. There's really no other choice here.
At the very least, being affiliated with a group that has intentionally introduced bugs in the Linux kernel, the burden falls on this student to demonstrate exactly how that particular static analysis tool found and subsequently introduced bugs, without any review that caught obvious errors being introduced. Let's see a reproduction of the process, which he should easily be able to do if this is a valid research project. Of course, if my suspicion is correct, there's no way he can do that.
Were I so accused, I would reproduce exactly how these mistakes occurred, and I'd be a hell of a lot more apologetic for introducing bugs instead of turning around and attacking the maintainer. Even if he were innocent, which I very much doubt, the kernel developers are well within their right to ban them on sheer incompetence or negligence. Imposing a public and embarrassing sanction against the entire university is the best way to prevent this sort of nonsense from happening again at a different university.
Nope, sorry. Not buying it for a nanosecond. The Linux kernel development community will do just fine without these guys.
Re:speaking of hypocrites (Score:4, Insightful)
GregKH claimed: "You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work."
Yes, GregKH claimed that, and it is an entirely factual statement. It bears noting that the very next sentence from GregKH in that same message is "Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing?"
Funny how that sentence provides the actual context. I can see why you omitted it.
But Aditya Pakki in fact is in a different group, working to find and fix bugs via static analysis.
No, Aditya Pakki in fact is in the same group as Kangjie Lu (assistant professor) and Qiushi Wu (PhD student), authors of the paper mentioned by GregKH. Pakki claims to be working to find and fix bugs via static analysis, but there is no "group" at UMN doing that. It's just him.
Here [umn.edu] is professor Kangjie Lu's page at UMN. You will note that Aditya Pakki's name appears alongside Lu's as an author of four papers listed on Lu's page.
Just because Pakki wasn't a named author of the Lu/Wu paper doesn't mean he's not in the same group as Lu/Wu. He quite clearly is. They are all systems security researchers working under the same assistant professor in the same floor in the same building in the same academic department at UMN.
So that is already wrong, and directly accusing the student of malicious intent is very wrong.
In this message [kernel.org] on the mailing list, Leon Romanovsky says:
Those spurious "patches" don't include the patch Aditya Pakki submitted that reintroduced a old vulnerability and kicked off the entire shitstorm.
The original Lu/Wu paper was published months ago, and the linux devs made their displeasure known about the methods employed by the researchers. It completely stretches credulity to think that Pakki believed he wasn't doing anything wrong by pushing yet another bogus "patch" into the pipeline months later.
So I understand the student's reaction.
Your understanding is based on faulty assumptions/reasoning. Maybe you should try understanding the reactions of the expert devs whose valuable time was wasted by this "researcher".
Unfortunately, the student is now being hounded by an angry mob, apparently fired up by someone who should know better.
Uh huh. Are there linux devs hounding or harassing Pakki? What's your proof that Aditya Pakki is being hounded by anyone? Or is this just something you think might be happening?
IMO, the Linux development community has every right to be angry. These UMN "researchers" acted unethically and possibly criminally. If the only consequences they face as a result of their behavior are some nasty e-mails, they should consider themselves lucky.
Where does the Linux kernel community get its supply of new developers? Primarily from universities just like this one.
Yeah...you don't know what you're talking about. The Linux kernel community primarily gets its supply of new developers from industry. [linuxfoundation.org]
Now, what student is going to want to get anywhere near the kernel community?
Hopefully students will learn a valuable lesson from Aditya Pakki's actions and only contribute code that actually fixes bugs instead of introducing or reintroducing them for the purposes of their "research".
Re: (Score:3)
None of which is "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits".
So what? The UMN "group" is assistant professor Lu, 5 PhD students, 3 master's, and one undergrad. Aditya Pakki [github.io] and Qiushi Wu, [github.io] whose name IS on the paper, share the same damn office.
There is absolutely nothing inaccurate about GregKH saying they are in the same "group". You have to be severely mentally challenged to believe otherwise.
He said as much, but you have your fingers in your ears.
LOL! Fingers in my ears? Your head so far up your ass you have to peer through your navel to see anything at all, and your ears are so clogged with your own shit you
Re:speaking of hypocrites (Score:5, Insightful)
Oh, it's worse than that. It's not good research if there are biases in the study that cannot be allowed for.
In other words, you cannot determine ahead of time the desirability or aversion to patches from UMinn, so it is not fully randomised. Since the level of aversion changes unpredictably with each faulty submission, you can't correct for it. As different projects do different levels of code review, and as you can't know the precise level any given patch gets, you can't make any generalized conclusion from this one attack.
So as a study, it's absolutely useless. It tells you nothing about the ability to insert malicious code into open source software. All it tells you is that someone involved was either a paid schill for a rival OS (and it's probably not going to be Theo) or that the UMinn is simply not capable of credible research. This is Utah's Cold Fusion level of gross incompetence.
The one thing they might have got right, being a university, they got wrong. But at least they got the full set.
Re:speaking of hypocrites (Score:4)
Damn.
Greg Kroah-Hartman, right to the throat on that one. A very good response to this kind of bullshit. The *plonk* at the end was just the icing on the cake.
Re: (Score:2)
Here's the exchange between Aditya Pakki, who is a Ph.D. student of Computer Science and Engineering at UMN, ...
"These patches were sent as part of a new static analyzer that I wrote and it's sensitivity is obviously not great ..."
So... a Ph.D. in CS from UMN is either really good or really, really bad.
Re: (Score:3)
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
Note to anyone. Anything in bad faith means that "benefit of the doubt" is no longer an option for you. That's literally something applicable in legal proceedings as well as pretty much every social norm. Fuck this university with a firepole.
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
No. You know what? The firepole is being too nice.
Re:speaking of hypocrites (Score:5, Insightful)
Greg's not a subject of the university in question, is he?
He told the clown to fuck off in far more diplomatic terms than I would if I were in his place.
-jcr
Greg is Linus's successor (Score:3)
Greg is Linus's designated successor. He's been taking over more and more of what Linus used to do.
Being Linus junior, I suspect he's not all THAT concerned about offending some college student who admits they intentionally tried to put bugs in the kernel.
How do you think his co-worker/mentor Linus Torvalds would have handled it?
Re:speaking of hypocrites (Score:4, Insightful)
"Newbies and non-experts" have no business submitting anything any more than some random toddler.
They should be "intimidated" and stay in their lane for the very good reason they're not competent.
Re: (Score:3)
Many many moons ago, I actually submitted a patch for a driver via Alan Cox... It was for the driver for the Apple/Farallon LocalTalk PC card, which was an 8 bit ISA card that allowed PC machines to connect to Apple LocalTalk networks. I was a complete noob and knew nothing about the kernel, but figured out this oddity in the driver that wasn't quite right. If I recall, it was a case of something being a "" comparison, rather than "=" or similar. Anyhow, it's my one contribution to the kernel, which is lon
Re: (Score:2)
You don't sound like a noobie, and you also sound like an expert.
Re: (Score:2)
Whining about politics is neither necessary nor appropriate here.
My understanding is the linux community does have standard practices for novices who want feedback on their own uncertain work. To push such things as genuine fixes of "something" without an accompanying analyst to explain their reasoning is unethical and unprofessional. Sadly, it fits the stereotype of people whose inferior skills makes them unfit for industry, yet somehow they slip into academics.
Of course, incompetence is the fig leaf to
Re:speaking of hypocrites (Score:4, Insightful)
Re:speaking of hypocrites (Score:4, Interesting)
I'd like to see what ethics committee signed off on this. It's more likely this guy cut a few corners with his research methodology and deserves whatever happens as a result.
Re: (Score:2)
Re:speaking of hypocrites (Score:5, Insightful)
I assume by definite outcome you mean the ban.
Now, onto the academic side:
They know nothing about the risks of OSS.
They failed to randomise variables.
They failed to determine how biases vary according to stimulus, other than observing that they do.
They failed to determine differences in code review practices between projects.
There's no obvious methodology.
There's no obvious baseline.
There's no way of measuring degree of success.
The experiment is unrepeatable.
The hypothesis (if there even is one) is unfalsifiable.
For that, I'd want the supervisor forced to do six months hard labour as primary school janitor.
Re: (Score:3)
Yes, but that might contravene the prohibition on cruel and unusual punishment.
Re:speaking of hypocrites (Score:5, Interesting)
That's a pretty bad ethics violation, and a fairly reasonable response.
It might be a bit worse than that. IANAL (or even a U.S. citizen), but they're in the U.S. so this https://www.law.cornell.edu/us... [cornell.edu] may be applicable. "(5) (A) knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;" If their problematic patched ended up in an actual production computer, this section of the Computer Fraud and Abuse Act might cause them trouble...
Re:human science researchers would be fired (Score:3, Insightful)
If were an experimental psychologist working at a university who conducted an experiment on human participants without consent, you would very likely be fired (at best); probably fired, sued, and possibly charged criminally.
OTOH, if you're a computer scientist at the UMN you can conduct experiments on human participants without consent and everything is fine?
Um wat? (Score:5, Insightful)
"Let's see how resilient the power grid is by setting explosives at strategic substations and interconnects."
"They say this bridge design is redundant...but let's find out *how* redundant it really is by cutting every other cable."
"They say the LD50 of this drug is X, so let's get 200 volunteers and..."
This isn't research, it's sociopaths with a .edu email.
Re:Um wat? (Score:4, Funny)
Contributing bad code is the same as sabotaging critical infrastructure. Right. Poettering better look out in that case...
Re: Um wat? (Score:5, Insightful)
Considering Linux *does* run under the hood of a bunch of "critical infrastructure" and a whole lot of heavy moving machinery, you're not as far off as you think.
A crap ton of phones run linux. If you're relying on them to be able to call 911...they're critical for you.
A lot of government and medical software runs on servers running some flavor of linux.
I could go on.
Yes it is sabotage and yes it is as bad as cutting and weakening bolts or rebar shipped to a construction site.
Re: (Score:2)
If you blindly put untested and unaudited code into critical systems then the burden is on YOU, not the author.
Re: Um wat? (Score:4, Insightful)
The probability of a bug getting past an audit is given by the probability of the auditor missing a bug multiplied by the probability of there being a bug in the first place.
An adversary deliberately introducing bugs increases the latter quantity, thereby increasing the overall probability of a bug in the finished product.
Let me try a car analogy: if I break into Pep Boys overnight and score the inside of every fourth tire with a knife...is it your fault for not personally inspecting every tire you bought from there that you end up with a flat?
Re: (Score:3)
If you blindly put untested and unaudited code into critical systems then the burden is on YOU, not the author.
Let's see if that makes sense if we turn it into a baking analogy: If you blindly put untested ingredients into a cake, then the burden is on YOU, not the maker of the ingredient. We'll say the ingredient is flour and the maker of the flour concealed rat poison in it, doing their best to make it look like regular flour. Someone eats the cake and dies... I would say that the assertion does not hold water there.
How about a Halloween candy analogy: If you blindly let your kids eat untested Halloween candy, the
Re: (Score:2)
Just gonna drop this here: https://www.theonion.com/repor... [theonion.com]
Re: (Score:3)
> Yeah bad software caused the meltdown. Not someone ignoring safety protocols and procedures...
There's an old /.er around here who was there when it happened. He says it was a Masters project of the son of one of the Kremlin's upper crust and despite all the warnings of the people at Chernobyl, he overrode them and they ran the kid's code. Boom.
Also NOT in the official report.
Went about it the wrong way (Score:5, Insightful)
For whitehat pentesting to be legal, ethical and, well whitehat you have to reach agreement with client first. You cant just take it upon yourself to carry out the test without notifying anyone and then claim it was for research. How are the maintainers to know that this wasn't actually malicious? Just because it came from a university? Its as if they had never heard of disgruntled employees or compromised accounts before.
They deserve their ban. This isn't how these things are done and it displays a shocking amount of recklessness and arrogance from their computer science department to think that was acceptable.
Re: (Score:2)
Maybe someone will bring back the "rogue engineer" defense.
Re: Went about it the wrong way (Score:2)
That's not necessarily true. If I stumble upon a hole and let you know about it privately, that's white hat hacking even without a prior agreement. It's probably illegal, but it's white hat.
Re: Went about it the wrong way (Score:5, Insightful)
Re: (Score:3)
Re: (Score:2)
If I stumble upon a hole
Stumble upon is different than actively seeking. I see ?customerId=12341 in your URL and think gee what if I change it to 12340. That might be stumbled upon. Its right there in front of my face.
I try tampering with one of the 20 parameters in your JWT and find 18 enjoys some kind of signature exclusion that is a little different.
Re: (Score:3)
I said pentesting. Finding existing exploits in the wild and reporting them is a related but different process. Pentesting isn't always directly testing infrastructure against known exploits, sometimes its testing the people and bureaucracy.
That's what happened here. The authors performed a test on how well the Linux kernel maintainers guarded against malicious commits. On its face that's a valid test. But for it to be a test and ethical you would have to do it above the board. Contact Linus and plan it out
Re:Went about it the wrong way (Score:5, Interesting)
Sadly its pretty often how things are done in the 'whitehat' security community.
First there is incredible pressure to 'get you name out there' by finding and publishing something. That is how you get the good jobs, as opposed to the ones where you grind your life away watching logs as first level person in some SOC (sorry if I hurt anyone feelings)/
Second, lets be completely honest the people attracted to pentesting typically have some personality quirks. Most people don't actually enjoy trying to do things they are not supposed to do and seeing if they can break stuff all day long. There is an "i want to watch the world burn" element to most of these guys and they cheer and clap for each other when something visible happens. So there is a positive feedback loop that pushes recklessness behavior.
Re: (Score:3)
Most people don't actually enjoy trying to do things they are not supposed to do and seeing if they can break stuff all day long.
You mean...hackers? Same people cheered on when it's breaking DRM?
Psych research (Score:4, Insightful)
A large fraction of psych research is devoted to proving that the researchers are smarter than their subjects. This is another example of same.
Re:Psych research (Score:4, Insightful)
Except psych research has the presence of ethics boards. Not sure what the CS or engineering department has.
Re: (Score:2)
Re: (Score:2, Interesting)
Some years ago, I had a conversation with a Harvard undergrad who was pre-med, planning on going into psychiatry. Her parents were both Harvard med shrinks themselves, and her motivation apparently was to show them up by exceeding their academic record, and prove to them once and for all that she was smarter than they are, etc. Wanting to help the mentally ill didn't even come up. She really creeped me out.
-jcr
Re: (Score:2)
I know a guy whose parents were both psychiatrists. He is the second most damaged human being I have never known. He literally can't function as an adult without mood stabilizing medication.
You can't become a psychiatrist without being treated by one. And the profession, as a whole, believe that 1/3 of all people should be on psychiatric drugs at any given time. They're all crazy because they make each other crazy.
Reminds me of the Wikipedia experiments (Score:2)
Re: (Score:2)
I don't think those hoaxes ever fucked up anyone's computer or deliberately left it open to compromise from third-parties.
Re: (Score:2)
No, but they may have had other real world consequences. Disinformation is quite dangerous, as we saw (again) on Jan 6 in the attack on the US capital. If you modify Wikipedia falsely, given how much people use it with blind trust, you can start an awful lot of bad processes going.
Re: (Score:3)
Wikipedia has a unique problem. If a news source reports misinformation they got from Wikipedia, that reporting can then be used to justify the continued inclusion of that misinformation!
Thanks to Wikipedia and lazy reporters, one troll's lie can become common knowledge, assumed by the masses to be gospel truth.
not nice what they did, but.. (Score:2)
Re: (Score:2)
It's not clear that all the commits were malicious or buggy. As I read it, all contributions from the University are being ripped out as a cautions measure. How can you be sure that there wasn't something you missed?
OTOH, it's also true that some bugs have persisted for decades. This can be documented for Linux. For commercial OSes, who knows? I tend to expect, based on lots of prior events, that they have a much larger number of unfixed bugs, but that *has* to be an assumption. The only groups that h
The word for "malicious contributions" is sabotage (Score:2)
Eventually the whackjobs will provoke blowback but that will take years because the community is full of freaks who washed up there looking for a place to influence, not a place to contribute quality code.
FOSS like everywhere else has a problem with people who throw tantrums. The proper response to tantrums is a brutal smackdown followed by shunning but weaklings won't do that.
University ethics violation? (Score:3)
Iâ(TM)m sure UMN has some kind of ethical research rules, along with some entity to evaluate potential violations.
Re:University ethics violation? (Score:5, Insightful)
Universities absolutely have such regulation, as does every research institution in the US. There are federal laws that apply here. In the first place, this kind of research must be reviewed and approved by the Institutional Review Board (IRB). Based on what they did I can't imagine that there is an IRB in the US that will approve this. The main mission of IRBs is to protect the research subjects. My experience with IRBs is that they are dead serious about that. So these "researchers" either did not get approval from the University of Minnesota IRB or their protocol dramatically deviated from the protocol that was approved.
The linux kernel team should contact the university IRB. This guy and whoever supervises him are looking at a life long ban on receiving federal research funding or working at a public institution.
I also love how his email starts with "I respectfully ask you ..." and immediately descents into disrespectful and abusive demands and accusation. How could have as well started with "Hi, I am a sociopath..."
Re: (Score:2)
They did get approval from IRB according to their research paper:
https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.io/main/papers/OpenSourceInsecurity.pdf
Regarding potential human research concerns. This experiment studies issues with the patching process instead of
individual behaviors, and we do not collect any personal
information. We send the emails to the Linux community
and seek their feedback. The experiment is not to blame
any maintainers but to reveal issues in the process. The IRB
of Universi
Re: (Score:3)
Re: (Score:3)
Maybe they were actually researching if you could exploit vulnerabilities in the IRB. /s
Re: (Score:3)
I've also done IRB-approved human subjects research and IRBs' role is critical, even if interacting with them is sometimes frustrating. My guess is that these researchers either decided that the IRB stuff was BS or didn't really understand the human implications of what they proposed to do (lie to their subjects to inject vulnerabilities into software used on billions of devices), then gave highly CS-ish answers to a group of people who mostly deal with biomedical research.
It's never been clear to me what'
Well, they got their result (Score:2)
The UMN had worked on a research paper dubbed "On the Feasibility of Stealthily Introducing Vulnerabilities..."
The result is:
It might work once but then you get banned from the community. Find another system to corrupt in the future.
Reality check (Score:2)
Re: (Score:2)
Solarwind.
Re: (Score:2)
While I agree that yes, there are potential security vulnerabilities in the open source model, this is absolutely positively not the way you test for this.
They were adding documented exploits to an active project. A project that happens to run on a wide gamut of devices and infrastructures ranging from the least to most secure.
Now imagine if that documented exploit got into the wild, on less maintained firmware such as an IOT device, then sold to the highest bidder.
The University absolutely deserved that ba
Re:Reality check (Score:5, Insightful)
No it hasn't, it's demonstrated that they were able to leverage the goodwill established by static analysis tools making minor changes without serious incidents for years and use this as a way to shoehorn in innocuous-looking bad changes submitted under an assumed good faith basis. Add to that the fact that many maintainers are more willing to be relaxed about receiving largely cosmetic patches from first-time contributors, and it's easy to see how some of these made their way in. These people have now singlehandedly burned through all of that goodwill and set back both academic research in static analysis tools and the initial hurdle required for first-time contributors. The unethical conduct of the researcher is certainly not going to help his future academic life, though perhaps he'll settle into a white hat firm that doesn't care about ethical considerations.
Code of conduct FTW (Score:5, Informative)
Re:Code of conduct FTW (Score:5, Funny)
That's brilliant! Maybe we could have a thing so when you get a driver's license, you have to sign a form agreeing not to commit a violent crime? That would solve the crime problem! They're geniuses!!
Of course, we'd then be very suspicious of people who don't drive... but at least they couldn't flee the scene of the crime quickly.
Re: (Score:2)
That's brilliant! Maybe we could have a thing so when you get a driver's license, you have to sign a form agreeing not to commit a violent crime? That would solve the crime problem! They're geniuses!!
Of course, we'd then be very suspicious of people who don't drive... but at least they couldn't flee the scene of the crime quickly.
Not true.... ever hear of a getaway driver... there is a glitch in the matix.... .grin.
Re: (Score:2)
Darn! You found the one flaw in the plan!
Re: (Score:2)
Next research topic (Score:3)
I raised an issue :) (Score:4, Informative)
Re: (Score:2)
I certainly hope someone from the linux kernel contact the university to figure this out. There should have been an IRB process. And I can't believe the IRB would ok that research without expert/external supervision.
He's actually really lucky (Score:5, Interesting)
UMN and the Linux Kernel team could have very justifiably written up the incident and then passed it onto the FBI or DHS. Pen testing without authorization is a felony; trying to inject vulnerabilities into something as strategic as Linux to the US economy is a great way to have agents from DHS out at your house for attacking critical infrastructure.
Welcome to "whitehat" hacking (Score:3)
In other words a large portion of the community consists of attention hungry narcissists with a complete lack of professionalism. It describes these people in particular pretty well as they pushed bad patches specifically to the project that would net them the most attention when they could easily have proven their point with another project that had much less potential for serious damage. When caught trying to push more bad patches they of course denied and tried to accuse Greg and the kernel community of being racists for seeing trough their obvious ruse.
Re: (Score:3)
Isn't this unethical and illegal? (Score:3)
I mean, they intentionally injected flaws in software they had no permission to do so, I believe (although I'm might be mistaken) that this is in violation of the Computer Fraud and Abuse Act of 1984.
Linux is used by "protected computers" as defined by the act (by government and financial institutions), and introducing flaws intentionally would be considered damage to those systems.
If all they get is banned from the kernel and a couple OSS projects, they got it easy. I think the should see prison time.
Also, I don't get how an ethics committee approved this in the first place.
Re: (Score:2)
If you install compromised code who is responsible? The author or you?
Re: (Score:3)
Both.
But if they did it intentionally, more them than me.
Blaming the victim is a bitch move.
Research Concluded - Who Funded it? (Score:3)
UMN response (Score:5, Informative)
Since nobody has posted this, it is worth pointing out the UMN has reacted.
https://cse.umn.edu/cs/stateme... [umn.edu]
Re: (Score:3)
Re: (Score:3)
I find it hard to believe a functioning IRB approved this. If they did they are at least partially to blame.
They have: https://lore.kernel.org/linux-... [kernel.org] they did: https://lore.kernel.org/linux-... [kernel.org] (at least for the previously published paper).
Re: (Score:2)
Obvious problems there are that whether there is direct experimentation on humans or not, people are, by definition, involved in the process - people that were not aware of what activity was being carried out, and which certainly were not in a position to offer informed consent to participate. Ignoring the human element, there's also the case that the patcher is knowingly inserting bad changes and that these are being presented on a presumed good faith basis. Static checkers can and do break things by faili
Re: (Score:3)
Re: (Score:3)
Getting Through (Score:3)
I'm guessing either:
1. The IRB had no idea what was involved in the experiment, thinking it was testing some sort of software testing framework instead of people
or
2. The researchers couched their proposal in terms that made it seem like no humans would be involved in the test
If the IRB was fully aware of what the researchers were doing, then every professor on the board should be permanently banned from holding that position again and reprimanded, as they allowed experiments to be conducted on human partici
Re: (Score:2)
Yes, this is very strange.
We need a freaking IRB to interview people about what they think of a user interface or how the user interface should be modified and we need to inform them of that before the interview can begin.
Now it would be hard to inform each person individually. But seeking consent from a leader in the community would seem necessary.
Re: (Score:2)
Well, yeah. An IRB *only* cares about protecting human subjects. That's the sole reason they exist. It doesn't really matter what you do. If you have human subjects, you get approval from the IRB.
There are other ethical considerations that should have been addressed in the case in TFA, but those aren't the IRB's concern.
Re: (Score:2)
It looks like they were mostly concerned with protecting the privacy of maintainers as they weren't subjects of the experiment.
Re: (Score:2)
Institutional Review Board
Re: (Score:2)
Good point. Plenty of people getting salty that it was proven true. Heartbleed was around for years before it was discovered that "many eyes" actually meant zero.
Re: (Score:3)
Did you actually read the email? GKH offered good reasons to doubt that the patch resulted from static analysis or at the least that no human had even bothered to review the patch before sending it in.
If you're going to submit a patch, the LEAST you should do is review it carefully and run with it on your own machine first.
If you want to have similar fun (but more serious consequences), try calling 911 and immediately alerting the emergency personnel that it was a false alarm when they get there (worst Apri