Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

Post reply on HN
Print view View original

191–200 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#191

Post by jnxx »

testplzignore wrote: post #58
gnfargbl wrote: post #21

From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

It may be unethical from an academic perspective, but I like that they did this. It shows there is a problem with the review process if it is not catching 100% of this garbage. Actual malicious actors are certainly already doing worse and maybe succeeding. In a roundabout way, this researcher has achieved their goal, and I hope they publish their results. Certainly more meaningful than most of the drivel in the acade…

> It shows there is a problem with the review process if it is not catching 100% of this garbage.

Does that add anything new to what we know since the creation of the "obfuscated C contest" in 1984?

Re: “They introduce kernel bugs on purpose”

#193

Post by throwawayffffas »

jnxx wrote: post #155
throwawayffffas wrote: post #47

As a user of the linux kernel, I feel legal action against the "researchers" should be pursued.

I feel somewhat similar. Since I am using Linux, they ultimately were trying to break the security of my computers. If I do that with any company without their consent, I can easily end up in jail.

It's more than that, if there is no consequences for this kind of action, we are going to get a wave of "security researcher" wannabes trying to pull similar bullshit.

Ps: I have put security researcher in quotes because this kind of thing is not security research, it's a publicity stunt.

Re: “They introduce kernel bugs on purpose”

#194

Post by jaywalk »

GoblinSlayer wrote: post #154
ENOTTY wrote: post #22

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…

Forking the kernel should be sufficient for research.

This research is specifically about getting patches accepted into open source projects, so that wouldn't work at all.

Re: “They introduce kernel bugs on purpose”

#195

Post by jokoon »

I'm pretty confident the NSA has been doing this for at least two decades, it's not a crazy enough conspiracy theory.

Inserting backdoors in the form of bugs is not difficult. Just hijack the machine of a maintainer, insert a well placed semicolon, done!

Do you remember the quote of Linus Torvalds ? "Given enough eye balls, all bugs are shallow." ? Do you really believe the Linux source code is being reviewed for bugs?

By the way, how do you write tests for a kernel?

I like open source, but security implies a lot of different problems and open source is not always better for security.

Re: “They introduce kernel bugs on purpose”

#196

Post by metalliqaz »

foobar33333 wrote: post #178
seanieb wrote: post #28

Regardless of their methods, I think they just proved the kernel security review process is non-existent. Either in the form of static analysis or human review. Whats being done to address those issues?

>Whats being done to address those issues? Moving to rust to limit the scope of possible bugs.

this is a dangerous understanding of Rust. Rust helps to avoid certain kinds of bugs in certain situations. Bugs are very much possible in Rust and the scope of bugs usually depends more on the system than the language used to write it.

Re: “They introduce kernel bugs on purpose”

#197

Post by scoutt »

ansible wrote: post #164

I still don't get the point of this "research". You're just testing the review ability of particular Linux kernel maintainers at a particular point in time. How does that generalize to the extent needed for it to be valid research on open source software development in general? You would need to run this "experiment" hundreds or thousands of times across most major open source projects.

>the point of this "research".

I think it's mostly "finger pointing": you need one exception to break a rule. If the rule is "open source is more secure than closed source because community/auditing/etc.", now with a paper demonstrating that this rule is not always true you can write a nice Medium article for your closed-source product, quoting said paper, claiming that your closed-source product is more secure than the open competitor.

Re: “They introduce kernel bugs on purpose”

#198

Post by mort96 »

xbar wrote: post #174
ENOTTY wrote: post #22

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…

This is not responsible research. This is similar to initiating fluid mechanics experiments on the wings of a Lufthansa A320 in flight to Frankfurt with a load of Austrians. There are a lot of people to feel bad for, but none is at the University of Minnesota. Think of the Austrians.

No, it's totally okay to feel sorry for good, conscientious researchers and students at the University of Minnesota who have been working on the kernel in good faith. It's sad that the actions of irresponsible researchers and associated review boards affect people who had nothing to do with professor Lu's research.

It's not wrong for the kernel community to decide to blanket ban contributions from the university. It obviously makes sense to ban contributions from institutions which are known to send intentionally buggy commits disguised as fixes. That doesn't mean you can't feel bad for the innocent students and professors.

Re: “They introduce kernel bugs on purpose”

#199

Post by throwaway823882 »

henearkr wrote: post #38
ENOTTY wrote: post #22

Later down thread from Greg K-H: > Because of this, I will now have to ban all future contributions from your University. Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota. EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures. In t…

Not a big loss: these professors likely hate open source. [edit: they do not. See child comments.] They are conducting research to demonstrate that it is easy to introduce bugs in open source... (whereas we know that the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards) [removed this ranting that does not apply since they are contributing a lot to the kernel in g…

> the strength of open source is its auditability, thus such bugs are quickly discovered and fixed afterwards

That's not true at all. There are many internet-critical projects with tons of holes that are not found for decades, because nobody except the core team ever looks at the code. You have to actually write tests, do fuzzing, static/memory analysis, etc to find bugs/security holes. Most open source projects don't even have tests.

Assuming people are always looking for bugs in FOSS projects is like assuming people are always looking for code violations in skyscrapers, just because a lot of people walk around them.

Re: “They introduce kernel bugs on purpose”

#200

Post by kleiba »

This is bullshit research. I mean, what they have actually found out through their experiments is that you can maliciously introduce bugs into the linux kernel. But, did anyone have doubts about this being possible prior to this "research"?

Obviously, bugs gets introduced into all software projects all the time. And the bugs don't know whether they've been put there intentionally or accidentally. Alls bugs that ever appeared in the linux kernel obviously made it through the review process. Even when no-one actively tried to introduce them.

So, why should it not be possible to intentionally insert bugs if it already "works" unintentionally? What is the insight gained from this innovative "research"?

Post reply on HN