This is nuts. Some contributions have made it into the Kernel already. All contributions from UofM are being removed though, and are being barred from contributing any Kernel patches in the future.
With the disclaimer that I haven’t deep-dived this and there’s plenty of information yet to be revealed…
This appears to be a complicated situation directly comparable to the gray area in ethical hacking. Depending on the exact details of how the group conducted the research including how they planned to disclose, how unnecessary the risks were to achieve the objective and what their intent was there may be a ton of justifiable criticism against the group.
However, outright banning the entire university for the actions of a group and discrediting a “secret shopper” approach to testing kernel security is a product of ego, not concern for real-world security.
Does Greg expect a heads up from hackers and gov’t actors prior to them pushing bad code? There’s a place for structured pentesting but security is about anticipating the unknown just as much as the known. Organized pentesting has to be mixed with the unexpected. There’s no excuse for the World’s most important software to not accept both.
Personal vendetta’s are not an adequate response to being caught with your pants down. This was an opportunity to broadly improve security and recommend a better structure for pentesting holes in their internal review but the Kernel seems to be blowing it so far.
I’m glad that these were spotted and rejected. It makes me feel confident in the QA of the kernel.
I don’t think that they need to be given the heads up about this sort of thing because anyone who’d want to actually mess with the kernel would not have that kind of courtesy either.
The patches that were added to the kernel though are never mentioned as being one of the intentionally bad ones or not.
The issue is in the morality of how they went about this. If those patches had been accepted, would UofM come out and say it was just a test and the kernel team failed? Or would they silently let them go into the kernel and let that cause problems for millions of people.
When Greg says they caught these problematic patches and asked them to stop, the test is over, but UofM acted like they were the victim and continued their actions. What’s the point of that? Everyone knows what you’re doing now, its no longer a test and proves nothing.
I’d argue those flaws have to be accepted in order for the pentest to mean anything and if they gave a prior heads up for where the problems were it’d make the result extremely easy to mitigate (ex: “hey team, be extra vigilant this week”) or cover up all together.
That’s were i’d like more information, though considering this was done with plenty of evidence i’d suspect they probably intended to disclose no later than what’d be necessary considering the legal ramifications.
Human engineering is the least anticipated form of pentesting and it’s used constantly in the wild. If someone can push vulnerable code into the kernel by using a shotgun approach and complaining about how new devs are treated that’s a hole that has to be patched.
Getting customer service on the line and just complaining until you get what you want is a common exploit. However gross it is to claim a handicap, a bad actor or nation state will ramp that up 10x.
Just to bring this back around, i’m not saying they did this perfectly, just that I think there’s more to it.
I dont think it is a personal vendetta, it feels more like an exemplary punishment to send a message. You can push bad code but only in good faith.
This really needs a deep dive (which I don’t have time for). I’ve been discussing this and i’m hearing there was disclosure but not responsible disclosure and it was revealed in a needlessly nasty way.
I don’t know if the Kernel team is planning to release a recognition of the vulnerabilities discovered or a plan to fix them other than ignoring Minnesota university commits.
I also shouldn’t expect every dev on the Kernel team to be a shining examplar 24/7 during a pretty crappy series of events. This is an open conversation mailing list between devs, not an official statement by the Kernel team or an accurate summary of Greg’s full stance.
Fair enough. I’d like to find out more but I’ll have to find a solid tutorial on how the heck mailing lists work
The Open Source Community and Greg react like a fanatic religious sect, whose main dogma has been attacked. All Open Source believers unite to throw the university off the cliff and ban them for life from the holy church. Instead of solving the issue, proven by the university, they blame and kill the messenger.
There has got to be a better way to socialize the rules and goals of a test like this with the targeted project.
Yeah. Even with the most positive reading of the situation, sending malfunctioning code in this way is still very bad idea.
It creates additional work for people working on the kernel and checking this kind of code can be quite demanding task. What’s worse, if code got integrated it could affect many machines using it – although, hopefully by that time, contributors would inform people working on kernel about it.
The fact that positive side of this situation could be achieved by simply working with the Linux team, where people doing the review wouldn’t know the contribution is bugged, but some other people working on the code would, makes this pretty one sided for me.
This is indefensible. No different than your doctor secretly giving you a different medicine than the one prescribed. Even if the doctor believes the secret new medicine it is a miracle cure, I suspect everyone here can agree the doctor would be terribly wrong. What UMN did is unethical, violates all ethical research standards, and the reaction of the kernel team was, in my opinion, not strong enough.
Agreed. If they want to test, then they need to create their own lab for their testing requirements. This is a simple example of them deflecting the cost (of the lab, environment, developers needed, et al) onto someone else.
List of resources:
Open Letter: An open letter to the Linux community
Credit: Brodie Robertson
When I first read about this security incident, I thought this was just a college security class performing blue team work. However, as I read deeper into the details, this is beginning to look more like red team work.
They say their goal was to improve the security, but it appears that they were looking not only to identify a vulnerability in the patching process, but were actually intending on exploiting the vulnerability. They say they were not, but they got caught in the process. I wonder what would have happened if they had not gotten caught.
The method in which this was done shows a pretty serious lack of judgement. It surprises me that this came from an educational institution. The response from the school was also surprising. They acted like they had no idea about any of this, which might be true, but to think that the school would give a professor that much latitude over something external to the school just shows more lack of judgement.
I almost closed the tab of my browser when I read their first recommendation, an update to the code of conduct. What class was this for?
Again, the subject is worthy of research but this type of testing should be performed in a closed lab, not a production environment. That’s IT 101 right there.
I’ve been desperate to hear from someone in security on this topic and i’m extremely grateful to Steve Gibson for this one, i’d consider this a must watch.
Ask Noah with a good deep dive and another angle.