A kernel ban and trust in open source

I think the University of Minnesota researchers asked a reasonable question, and I think Greg Kroah-Hartman was right to ban them. Both of those can be true.

Quick version of the story, for anyone who missed last week. A UMN group wrote a paper, due at IEEE S&P this year, on what they called “hypocrite commits”: small patches that look like bug fixes but quietly introduce a vulnerability, sent to see whether maintainers would catch them. The kernel community was annoyed about that paper back when it surfaced last year. Then this month another member of the same group sent in a batch of patches that Greg described as obviously incorrect, and when Greg challenged them, the student who sent them accused him of making wild accusations bordering on slander. Greg’s reply on the 21st included the line “Our community does not appreciate being experimented on”, banned all future contributions from the university, and posted reverts for roughly 190 earlier patches from umn.edu addresses so they could be re-reviewed. The department said it had suspended the research. On Saturday the researchers sent an apology to the mailing list, and Greg pointed them to a letter from the Linux Foundation listing what the university needs to do before anything changes.

Whether a determined attacker can get a bad patch into a big open source project is a real question, and the answer is obviously yes. I wrote about a stranger getting publish rights to an npm package a couple of years ago, and that took no subtlety at all, just asking nicely. In the kernel’s case, review is done by a few hundred overloaded people reading diffs in email, and a use-after-free introduced by one extra, plausible-looking cleanup call in an error path is exactly the kind of thing that slips through. We knew that. Heartbleed sat in OpenSSL for two years. I don’t think the paper told the maintainers anything they didn’t already lose sleep over.

The cost landed on the maintainers. The thing the experiment consumed was maintainers’ time and trust, and maintainer time is the scarcest resource in open source. Greg and the subsystem maintainers didn’t sign up to be research subjects. As I understand it the university’s review board decided the study wasn’t human-subjects research, because it was about the software and not the people, which is a strange reading of an experiment whose entire point is whether particular people notice something. And the cost didn’t stop with the original patches. Every patch from that university, including the good ones (and from what’s being said on the list, most of them look fine), now has to be checked again by somebody who has better things to do.

There was an ethical way to do this, and it’s the way every penetration test I’ve ever been involved in works. You ask the owner first. Get Greg, or a couple of senior maintainers, to agree, keep the reviewers in the dark if that’s the point, and have someone in on it who can pull the patch before it lands in a release. Red teams do this all the time. It’s slower and less dramatic, and you wouldn’t have a front-page story out of it, which may be part of why it didn’t happen.

A blanket ban on a whole university feels harsh, and some students there who’ve never heard of this paper are going to get caught in it. But the kernel runs on trust in who sent a patch at least as much as on reviewing what’s in it, and once a group has run one experiment on you without asking, there isn’t a lot else you can do when another batch of bad patches arrives from the same place. The cost I’d actually like to see counted is the hours spent on those 190 re-reviews, and I doubt anyone will bother.