Live data from Hacker News

UMN CS&E Statement on Linux Kernel Research

cse.umn.edu

211–220 of 332 posts

Re: UMN CS&E Statement on Linux Kernel Research

#211

Earlier quoted context omitted.

Sorry for getting sidetracked, but does cc has any special function here or you are hoping that dang would read all the comments and see your cc?

I think dang might have something in place which alerts him when he is mentioned. Certainly he tends to show up quickly when people "page" him like this.

I used to have that, but it stopped working with the last re-Lisp of my moderation software. It's on my list to redo it.

https://news.ycombinator.com/item?id=20652146

Some of this stuff will eventually get open-sourced and/or integrated into HN for everybody.

Re: UMN CS&E Statement on Linux Kernel Research

#212
post #152

Earlier quoted context omitted.

> At any point they can just say "we're still investigating" until enough time has passed people aren't paying attention any more. They need to act to get the ban rescinded, they can't just ignore this issue away.

I agree, that's why in this case (as I say in my post) I believe they'll follow through.

"and we admit that a full accounting for these actions is necessary before our ban is rescinded" is a valid (albeit even less common) form of making sure that they are held accountable. Nonetheless, it is important that the accused admits it.

The common case today is that admitting you are due to account for your actions is the same as admitting that you are at fault. I have been denied jobs because I have admitted that to being accountable for my decisions, whereas I got the distinct impression had I simply not accounted for them they wouldn't have cared.

Re: UMN CS&E Statement on Linux Kernel Research

#213

Earlier quoted context omitted.

they are re-reviewing the patches and will be accepting them back if they look fine, it is not really blindly rejecting them all

And in the meantime allowing patched permissions vulnerabilities to reappear in mainline? Seems to be a bit of an overreaction no? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Except that patch is clearly BS! You can't patch a double-read vulnerability by checking for a capability; that's not a thing that works. So either the description is wrong, or the patch is wrong, or both.

And the point of the reverts is that the kernel maintainers don't have the unlimited time that would be necessary to re-review all of these questionable patches for probable malicious underhanded C, so they are reverted for now for triage (not permanently).

For the linked patch, I would judge it possibly malicious as it leaves the identified vulnerability in the kernel for later exploit by the attackers, namely, the UMN research team.

Re: UMN CS&E Statement on Linux Kernel Research

#215

I think everybody is missing the point. If one grad student was able to do this, imagine what a team of dozens of well-paid, well-equipped, and highly experienced security experts could do. In other news, we just learned that any half-decent security agency has already injected their own vulnerabilities and back-doors in OSS.

There are so many security flaws in critical software that you really don't need to inject vulnerabilities. You just need your engineers to find, catalog, and script exploits for them - ready to use whenever needed.

If you do inject vulnerabilities you need to assume your adversaries will find, catalog, and script an exploit for it. And you risk your reputation loss if you do get caught. So I'm sure it has happened, but I bet not that often.

Re: UMN CS&E Statement on Linux Kernel Research

#216

Earlier quoted context omitted.

I disagree. There's not a single word of apology in it.

They don't have to, it's the ,,redearcher'' who has to apologize. The University has to do exactly what they have done and follow up, to keep their reputation.

They have to investigate and also apologize accordingly in the name of the university.

Saying the researcher is the only responsible of a work that is managed by the university (with things such as probably funds and for sure resources) is just wrong.

Re: UMN CS&E Statement on Linux Kernel Research

#218
post #208

Can someone explain why engineering of bugs into products is bad but hacking to find software defects is good. I think trying to do this sort of research is good because obviously it presents a vector for malicious actors we should all be aware of. It’s good that the Linux team found these issues but I don’t see the intention as being any different than any other kind of hacking, just like some organisations will sen…

Society works because of trust. Activities like these erode trust. It's like "let's try and pour a bottle of acid into the freshwater storage facility".

[deleted]

Re: UMN CS&E Statement on Linux Kernel Research

#219
post #99

Earlier quoted context omitted.

It is a good statement, and I believe they'll follow through, but it's missing something important that is often missing from otherwise professional communication. The last line is "We will report our findings back to the community as soon as practical." It should be followed by "and we will provide an update in no more than 30 days". Without any explicit time frame, holding them publicly accountable becomes trickier…

It is a good PR statement, but it doesn't touch on any of the Linux Kernel community's concerns. It makes no committment to working with the community or, like you said provide any kind of explicit time frame. Instead, the statement is there to prevent journalists from putting "UWN puts the entire internet at risk" on their front page. Instead, it frames the incident into a boring "Students offended the Linux Kernel…

Well put. It’s taken me the last hour to realise that it really is refreshingly transparent.

To me, it’s like the distinction between offence caused and actually showing some genuine reflection as to why there might be offence caused. This statement, to me, is firmly in the former camp.

Post reply on HN