Hacker News Reader

> that this could be a good pen-test for the kernel

Not really. Everyone knows this flaw exists, the interesting part is how to fix it. Did you read the "suggestions" the researchers made in their paper[1]? They're clueless.

It's like pointing out that buildings can be robbed by breaking their windows. No shit. What do you want to do about it?

[1] https://twitter.com/SarahJamieLewis/status/13848800341465743...

Agreed. As I mentioned in an earlier thread on this scandal, [0] we already know that security bugs can make their way into the kernel.

[0] https://news.ycombinator.com/item?id=26888129

Check out my groundbreaking research. I smashed windows on 20 buildings and took cash out of their registers. In order to fix this vulnerability, I suggest you make everyone who passes by your building sign this piece of paper saying they won't smash your windows and take your money. I will happily receive your nearest Nobel prize now, thank you.

Signed, UMN Researchers.

Edit: Wait, the cops are here. We sincerely apologize for any harm our research group did to your business. Our goal was to identify issues with the windows on your buildings and we are very sorry that the method used in the “smashing windows to take cash” paper was inappropriate.

> I smashed windows on 20 buildings and took cash out of their registers.

More like they posted on your facebook pro-<insert your kink here> messages. There's some value in grounding the analogy in reality.

I think the cash theft is analogous to the dev time the researchers wasted.

What exactly is the value? How did you come to it? The pay rate of people who would be working on the software regardless of the MNU boondoggle, is not wasted anymore than any other day is wasted. This is part of development. Dead ends, circling back, accounting, maintenance, et al.

> I think the cash theft is analogous to the dev time the researchers wasted.

That's a fantasy that developers would like to believe because they put an inappropriate valuation on the the time spent on software. The inability to face this, has been disturbing from the start.

Related: there's a reason the Certified Ethical Hacker course places such emphasis on getting written permission before doing anything.

If you're messing with someone's systems, or (as in this case) with someone's processes, you don't get to claim to be the good guy unless they agreed to it before the fact. It's not rocket science.

Not really. Everyone knows this flaw exists, the interesting part is how to fix it. Did you read the "suggestions" the researchers made in their paper[1]? They're clueless

Fair enough. The kernel maintainers are probably much more aware of this than the average open source project. Maybe for some projects it would change their mindset from knowing that this could be happening, to knowing that this will be happening.

Maybe it's a pipe dream, but I have a feeling it could lead to discussions of "what could we have done to catch this automatically," which in turn would lead to better static analysis tools.

Edit: It would be about as useful as pen testing that includes social engineering. That is to say, everyone knows there are dishonest people, but they may not be aware of some of the techniques they use.

> Maybe it's a pipe dream, but I have a feeling it could lead to discussions of "what could we have done to catch this automatically," which in turn would lead to better static analysis tools.

It did do that, at least twenty years ago. Static analysis tooling is a huge, active area of research and the kernel is frequently a target of that research. Ditto for other areas like language development (see the recent work on getting Rust into the kernel). If these students had tried making real contributions to those areas, I'm sure they would have been welcome. But that kind of work is difficult and requires real research and development, which these students aren't interested in and/or capable of. So we got this trash instead, and now hopefully you understand the harsh reaction to it.

To be clear, I 100% understand the harsh reaction. If anything I think they were lucky no criminal charges were pressed.

Yeah. I'm not trying to come down hard on you or anything, I just feel like a common reaction to this research is, "ethics aside, didn't they point out a real vulnerability?" And I want to make it crystal clear that, no, they didn't. Their research was entirely without value.

If you put ethics aside, then yes there was value. Failed research is most valuable, while successful research is usually quite worthless due to the bias toward finding whatever researchers already believe.

I do wonder if they would have published if they didn't expect disclosure by angry Linux maintainers, i.e. if they really believe they were weakly successful. Generally, I think this is the type of finding that normally gets lost if there's no pre-disclosure.

https://pubmed.ncbi.nlm.nih.gov/16060722/

The ideas in the paper were novel, perhaps (didn't check) but there was far more to learn from looking at reviews where bugs did slip by than doing their experiment. You could probably calculate the bug acceptance rate by category of bug, making a few random data points does not help science here

I think the prevailing belief, and belief they must have had to try their research was the belief that a good percentage of attempts would slip through initial review to be caught at a later stage. I fail to see what your alternative research would do to that apparently false belief other than reinforce it.

> If you put ethics aside, then yes there was value. Failed research is most valuable, while successful research is usually quite worthless due to the bias toward finding whatever researchers already believe.

True as far as it goes, but the most valuable failing research is that which fails to produce an expected positive result.

Next most valuable is failing to corroborate a novel hypothesis (which is probably what you meant).

When you get an expected result, you haven't learned much, regardless of whether you were (or should have been) expecting success OR failure (with the exception being getting more, or more accurate, data that narrows error bars).

How else were they supposed to get that much exposure for their tier 2 CS program?

smash some windows in their own university

<s> Bother the freedesktop project? </s>

This. and more so, they should be charged for the broken windows. dev hours times 80.

The stated motivations of the researchers make it seem like they are not interested in advancing the security of open source software, but rather undermining it.

Then "on behalf of whom" should be the next question.

Maybe it is more productive to just do the opposite. When vulnerabilities are found investigate the committer(s) for possible links, and quality of previous work

Why would the Linux Foundation get to decide on if those researchers are allowed to experiment on and waste the time of volunteer developers?

The Linux foundation is in a position to ensure that Linux users don’t accidentally get experimented on when the PRs are approved.

Why would the Linux Foundation get to decide on if those researchers are allowed to experiment on and waste the time of volunteer developers?

Granted, In the case of linux, it might make more sense if it were the combination of the Linux Foundation & Linus. It's their project, they can subject their volunteers to any tests they want. It may drive away some volunteers, but wether to take that risk or not, is up to the project to decide. For something as big as the kernel they may decide to get permission from the individual maintainers, maybe even limit the research to only the subsystems that agree to participate.

In any case, the point I'm trying to make, is that this kind of testing may be beneficial, if the project is aware of it, and agrees to it. Who gets to decide on behalf of the project, would depend on the hierarchy of each project.

There are relatively few volunteers working on Linux. They mostly do it for their day jobs. Though the same criticism applies with respect to wasting time at their various companies. But, yes, there may have been some way of conducting a useful test after receiving permission--probably on a limited subsystem or set of subsystems.

Presumably they would do so after consultation with kernel developers, like uhh... themselves.

I think it depends on how you frame it. If the Linux Foundation thinks this kind of research would generate useful information for the kernel project, then the developers' time wouldn't be wasted, just used in a different, yet productive, way. I concede that this is not an easy question, because the developers may have different opinions about the usefulness of this exercise, but at the end of the day, maintainers can run their projects how they see fit.