7 ms·
> having the gall to brag about it is a new low Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for
by alpaca128 6y ago
> having the gall to brag about it is a new low
Even worse: They bragged about it, then sent a new wave of buggy patches to see if the "test subjects" fall for it once again, and then tried to push the blame on the kernel maintainers for being "intimidating to newbies".
This is thinly veiled and potentially dangerous bullying.
- smsm42 6y agoThis looks a very cynical attempt to leverage PC language to manipulate people. Basically a social engineering attack. They surely will try to present it as pentest, but IMHO it should be treated as an attack.
- ISL 6y agoIt isn't even bullying. It is just dumb? Fortunately, the episode also suggests that the kernel-development immune-system is fully-operational.
- tigerBL00D 6y agoNot sure. From what I read they've successfully introduced a vulnerability in their first attempt. Would anyone have noticed if they didn't call more attention to their activities?
- mirchibajji 6y agoCan you point to this please? From my reading, it appears that their earlier patches were merged, but there is no mention of them being actual vulnerabilities. The lkml thread does mention they want to revert these patches, just in case.
- lb7000 6y agoFrom LKML "A lot of these have already reached the stable trees. I can send you revert patches for stable by the end of today (if your scripts have not already done it)." https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.c...
- PeterisP 6y agoIt's not saying that those are introduced bugs; IMHO they're just proactively reverting all commits from these people.
- lfc07 6y agoYes because the UMN guys have made their intent clear, and even went on to defend their actions. They should have apologised and asked for reverting their patches.
- remexre 6y agoWhich kind of sucks for everyone else at UMN, including people who are submitting actual security fixes...
- capybara_2020 6y ago> > > They introduce kernel bugs on purpose. Yesterday, I took a look on 4 > > > accepted patches from Aditya and 3 of them added various severity security > > > "holes". It looks like actual security vulnerabilities were successfully added to the stable branch based on that comment.
- dr-detroit 6y agodont most distro come with systemd so they're already compromised?
- IAmNotAFix 6y agoAt this point how do you even make the difference between their genuine behavior and the behavior that is part of the research?
- fellellor 6y agoIt would be hard to show this wasn’t genuine behaviour but a malicious attempt to infect the Linux kernel. That still doesn’t give them a pass though. Academia is full of copycat “scholars”. Kernel maintainers would end up wasting significant chunks of their time fending off this type of “research”.
- winkeltripel 6y agoThe kernel maintainers don't need to show or prove anything, or owe anyone an explanation. The University's staff/students are banned, and their work will be undone within a few days. The reputational damage will be lasting, both for the researchers, and for UMN.
- Mordisquitos 6y agoI would say that, from the point of view of the kernel maintainers, that question is irrelevant, as they never agreed to taking part in any research so. Therefore, from their perspective, all the behaviour is genuinely malevolent regardless of the individual intentions of each UMN researcher.
- deagle50 6y agoAnd they tried to blow the "preconceived biases" dog whistle. I read that as a threat.
- forkwhilefork 6y agoContext for those curious: https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/ https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...
- kstrauser 6y agoWTF. I didn't have strong feelings about that until reading this thread. Nothing like doubling down on the assholishness after getting caught, Aditya.
- fartcannon 6y agoIntimidating new people is the same line that was lobbed at Linus to neuter his public persona. It would not surprise me if opportunists utilize this kind of language more frequently in the future.
- cosmie 6y ago> This is thinly veiled and potentially dangerous bullying. Which itself could be the basis of a follow up research paper. The first one was about surreptitiously slipping vulnerabilities into the kernel code. There's nothing surreptitious about their current behavior. They're now known bad actors attempting to get patches approved. First nonchalantly, and after getting called out and rejected they framed it as an attempt at bullying by the maintainers. If patches end up getting approved, everything about the situation is ripe for another paper. The initial rejection, attempting to frame it as bullying by the maintainers (which ironically, is thinly veiled bullying itself), impact of public pressure (which currently seems to be in the maintainers' favor, but the public is fickle and could turn on a dime). Hell, even if the attempt isn't successful you could probably turn it into another paper anyway. Wouldn't be as splashy, but would still be an interesting meta-analysis of techniques bad actors can use to exploit the human nature of the open source process.
- throw14082020 6y ago> Which itself could be the basis of a follow up research paper. Seems more like low grade journalism to me.
- dcow 6y agoYep, while the downside is that it wastes maintainers’ time and they are rightfully annoyed, I find the overall topic fascinating not repulsive. This is a real world red team pen test on one of the highest profile software projects. There is a lot to learn here all around! Hope the UMN people didn't burn goodwill by being too annoying, though. Sounds like they may not be the best red team after all...
- kemonocode 6y agoA good red team pentest would have been to just stop after the first round of patches, not to try again and then cry foul when they get rightfully rejected. Unless, of course, social denunciation is part of the attack- and yes, it's admittedly a pretty good sidechannel- but that's a rather grisly social engineering attack, wouldn't you agree?
- deleted 6y ago
- sergiotapia 6y ago>then tried to push the blame on the kernel maintainers for being "intimidating to newbies". As soon as I read that all sympathy for this clown was out the window. He knows exactly what he's doing.
- mintplant 6y agoI'm gonna go against the grain here and say I don't think this is a continuation of the original research. It'd be a strange change in methodology. The first paper used temporary email addresses, why switch to a single real one? The first paper alerted maintainers as soon as patches were approved, why switch to allowing them to make it through to stable? The first paper focused on a few subtle changes, why switch to random scattershot patches? Sure, this person's advisor is listed as a co-author of the first paper, but that really doesn't imply the level of coordination that people are assuming here.
- legacynl 6y agoIt doesn't really matter that he/they changed MO, because they've already shown to be untrustworthy. You can only get the benefit of the doubt once. I'm not saying people or institutions cant change. But the burden of proof is on them now to show that they did. A good first step would be to acknowledge that there IS a good reason for doubt, and certainly not whine about 'preconceived bias'.
- powersnail 6y agoThey had already done it once without asking for consent. At least in my eye, that makes them—everyone in the team—lose their credibility. Notifying the kernel maintainers afterwards is irrelevant. It is not the job of the kernel maintainers to justify the teams new nonsense patches. If the team has stopped being bullshit, they should defend the merit of their own patches. They have failed to do so, and instead tried to deflect with recriminations, and now they are banned.
- twic 6y agoI don't see any sense in which this is bullying.
- spfzero 6y agoThere are some activities that should be "intimidating to newbies" though, shouldn't there? I can think of a lot of specific examples, but in general, anything where significant preparation is helpful in avoiding expensive (or dangerous) accidents. Or where lack of preparation (or intentional "mistakes" like in this case) would shift the burden of work unfairly onto someone else. Also, a "newbie" in the context of Linux system programming would still imply reasonable experience and skill in writing code, and in checking and testing your work.
- bobthechef 6y agoWhy not just call it what it is: fraud. They tried to deceive the maintainers into incorporating buggy code under false pretenses. They lied (yes, let's use that word) about it, then doubled down about the lie when caught.