LWN: Comments on "A /proc/PID/mem vulnerability"

A /proc/PID/mem vulnerability

alonz — Sat, 11 Feb 2012 19:56:59 +0000

Yes, the changelog doesn't competently hide that there are security issues.

But it does hide the specific vulnerability in the previous code. So it's really useless for educating the next generation. (Unless you believe whoever next touches this code will magically understand what the real issue is…?)

A missed point

kevinm — Thu, 09 Feb 2012 11:45:58 +0000

In particular, *any* wild pointer write or use-after-free bug in any random driver should be considered a security bug.

A /proc/PID/mem vulnerability

Duncan — Wed, 08 Feb 2012 07:41:34 +0000

Not that many will ever read this far down even if they come across the article via google or whatever at this late date, but...

What is there about ...

"isn't very robust.. doesn't match the permission checking... This changes ... permission checks"

... that does not SCREAM security vuln? To me it certainly does!

I mean, what is one /doing/ "permissions checks" for if not for security? Otherwise they'd be something else, data validity checks, maybe. But if they're permissions checks, then by implications there's something there to be secured BY those permissions checks.

And if the simple phrase "permission checks" isn't enough to get someone investigating, surely adding "isn't very robust... changing" to the mix, when the context is "permission checks" should do so!

If I say my bank account isn't very robust and that I'm working to change it, who wouldn't read that as a saying I lack money but am trying to change it? If I say the permission checks aren't very robust and that they're being changed, how on earth can it mean anything BUT "THIS COMMIT HAS POTENTIAL SECURITY IMPLICATIONS!"? (Yes, to me it's SHOUTING, so the caps are warranted.)

Duncan

A /proc/PID/mem vulnerability

landley — Mon, 06 Feb 2012 16:01:52 +0000

The black hats already have an easy source of security bugs: look at the "stable" releases and see what the diff is from last time. The majority of those are going to be security fixes, because if they weren't they would wait until the next quarterly release.

When Linux first grew "1.2.3.x" level releases, they would stop doing them as soon as a new kernel came out, and there was a gap between the last stable and the new kernel. I asked for one more release worth of overlap, so people stuck on old kernels could see what the fixes in need of backporting were without losing some in each gap between the last dot-release in the old kernel and the new quarterly kernel release. Greg agreed and started doing that.

(Since then various people have tried to do long term support for Random Kernels Your Vendor Did Not Provide, which is utterly useless to anybody using a board support package in the embedded space, and yet they keep hoping that If We Build It, They Will Stop Using The Thing The Other Guy Already Built. But the extra overlap closing the gap for the stable releases is still a good thing anyway.)

The danger with what Linus is doing is if he DOESN'T forward that commit to the stable guys. But presumably he did that.

Rob

Editorial section?

liljencrantz — Wed, 01 Feb 2012 23:01:31 +0000

A value LWN both for it's unbiased reporting of facts and for it's well reasoned opinions, but (as you say) they must be clearly separated. Unfortuatly, while I happen to agree with your opinion i this case, I kind of feel you kind got it mixed into the facts. The two last paragraphs are clearly opinion, but I could feel the article leading up to that opinion just a few paragraphs into the «The fix and reactions» section, and it seems I'm not the only one.

Remaining completely neutral in situations where you have a strong opinion is (in my opinion) impossible, but I urge you to keep trying.

A /proc/PID/mem vulnerability

malor — Tue, 31 Jan 2012 05:48:04 +0000

I mean, that's the Catholic Church approach to computer security -- the reputation of the ~~church~~ kernel is much, more more important than protecting ~~children~~ users.

A /proc/PID/mem vulnerability

malor — Tue, 31 Jan 2012 05:45:28 +0000

and commenting bugs too early damages Linux security reputation.

A better summation would be tells the truth, and we can't have users knowing the TRUTH, because they might not use Linux.

Much, much better to lie to them, to get users to use your code.

Well, better for you, anyway.

A /proc/PID/mem vulnerability

alonz — Mon, 30 Jan 2012 09:43:54 +0000

What's really sad is that the exact same vulnerability was already known when the “fix” to relax the permissions was made (see references in this linux-kernel message from Alan Cox). Had the issue been clearly documented in comments / changelog messages, and not just on the mailing list, it would not have been lost.

And now the new patch is in place, and again the security implications are not documented where they will be seen by future developers. So we can certainly expect someone to ~~“fix”~~ break this again one day, just because critical information was withheld from the changelog.

A missed point

PaXTeam — Sat, 28 Jan 2012 00:54:53 +0000

Linus' argument isn't about being secure/insecure by selectively backporting patches per se (it's not a boolean property) but whether one's more or less secure/insecure by doing selective backporting or just flowing with his git HEAD. by covering up security fixes he effectively makes that choice for everyone, and that doesn't fly well with people who believe they know better (by virtue of not providing kernels based on his git HEAD to their users, which i believe covers about 99.99999% of all linux users).

A missed point

neilbrown — Sat, 28 Jan 2012 00:50:29 +0000

This is undoubtedly true.

As a general rule, many commit messages are not as informative as they could be or should be. Andrew Morton regularly rants about this. I personally find that writing a good commit message helps me find problems with the commit often enough that it is clearly worth while. It seems that others don't :-(

So commit messages don't guarantee anything, and they could certainly be better.

But that doesn't excuse removing security related information from commit messages, or deliberately leaving it out. We should always include anything useful that we know. We cannot justify leaving info out because some other commit message doesn't have that kind of info.

So sure: if people only back-port commits which say "bug fix" or "security issue" in the commit message, then they are being foolish. But it is not our place (or Linus' place) to stop people from being foolish.

It *is* our place to make the code and the code-history as easy to understand and maintain as possible.

A missed point

zlynx — Fri, 27 Jan 2012 23:59:41 +0000

If I recall it correctly from back when Linus had this discussion way back when, one of the points he made that this article didn't bring up is that there are hundreds of Linux bugs and bug fixes which aren't known to be security holes and security fixes at the time they are fixed.

Therefore, if you are relying on commit messages to have a big "Security Fix Here" tag so that you know when to upgrade your kernel, you will be insecure anyway.

A /proc/PID/mem vulnerability

PaXTeam — Thu, 26 Jan 2012 23:01:01 +0000

> [...]who do exactly that?

err, i obviously meant 'who do exactly the opposite' ;).

A /proc/PID/mem vulnerability

PaXTeam — Thu, 26 Jan 2012 22:34:20 +0000

> "There is a exploit out for a widely-discussed security bug" is not the
> same as "there is an expoit out there for each and every security bug."

strawman and also an irrelevant tautology.

> As long as you can't reasonably know if to publish any hint of possible
> security impact or just keep it quiet is the better course of action.

real life says that you can reasonably know that there's an entire industry, both visible and invisible, out there that is watching and writing exploits as soon as they can get their hands on a bug, be that at bug commit time or later (the sooner the better as the value of 0-day beats anything else).

on the other hand the best course of action for users of said buggy code to save themselves is to fix the bugs (yes, i'm stating this myself despite being deeply involved in intrusion prevention technologies). for that they need to know about them, simple as that. covering up security fixes is diametrically opposite to that goal as it makes it much harder for users to reverse engineer the information from the commits whereas said industry has the brainpower to see through these silly attempts (as i said above, commits from Linus and certain other individuals draw immediate attention these days, witness what happened to this /proc/pid/mem bug).

btw, if you think keeping quiet about security impact information is the right course of action, what do you think about companies (linux vendors included) who do exactly that?

PS: i'm glad you stopped doubting that there *is* a coverup. you've come a long a way ;).

A /proc/PID/mem vulnerability

vonbrand — Thu, 26 Jan 2012 20:06:00 +0000

Oh, come on. "There is a exploit out for a widely-discussed security bug" is not the same as "there is an expoit out there for each and every security bug." As long as you can't reasonably know if to publish any hint of possible security impact or just keep it quiet is the better course of action.

Editorial section?

nix — Thu, 26 Jan 2012 17:30:57 +0000

You think you're joking, but I've been on one site, nameless to protect the guilty, where the sysadmins did not (for stupid political reasons) have the ability to change the password, and had long forgotten what that password was, and where auditors forbade the installation of additional privileged binaries -- so, rather than use sudo or something like that, they kept an exploit binary around to give them a root shell 'because it works as long as we don't upgrade the kernel'.

(I pointed out how stunningly unwise this was, and was told that this was the way they'd always done it and they weren't going to change.)

Editorial section?

emk — Thu, 26 Jan 2012 16:07:27 +0000

I appreciate LWN's mix of facts and analysis, even on those rare occasions where I disagree with your analysis. You're usually pretty clear about which is which, and you make an effort to get the facts right.

Please keep up the good work. :-)

A /proc/PID/mem vulnerability

ortalo — Thu, 26 Jan 2012 14:47:23 +0000

In my humble opinion, the full disclosure debate is only useful when it opposes to the unlawful attitude of some vendors who tries to negate the existence of vulnerabilities in their own products.

Outside of that situation, it seems (to me) to be a little pointless because focussed on a too small perimeter.

First I think at least as much, and possibly more energy should be spent on preventing the introduction of vulnerabilities than on setting up infrastructure or procedures for correcting them. For example, more talking on coding practices, auditing techniques, architectures with several layers of proection or the associated tools that prevent the introduction of bugs with a security impact; than on how to acquire/propagate the information concerning vulnerabilities. In short: work not to introduce vulnerabilities as much as removing them.

Furthermore, the information needed by an attacker is not necessarily the same as the information needed by a security officer, so the content of the disclosure information should be taken into account in the debate. But there is certainly little ROI to expect from this additional effort on writing vulnerability notes, esp. given the previous point.

Finally, the actual impact of full disclosure or embargo depends on the final security needs of a specific system: at home, maybe I am not so much impacted, at work on a highly valuable system, maybe I am. Or maybe the opposite, because the involved software is used at home and not at work. So, trying to get a definitive answer on the best procedure is most certainly impossible in the general case. Fortunately, there are many other things to do.

A /proc/PID/mem vulnerability

PaXTeam — Thu, 26 Jan 2012 14:11:49 +0000

> Well, kernels are more painful to upgrade than most other software
> (since you pretty much have to reboot).

well, there is ksplice...

> If someone is malicious and knows about what's going on in advance,
> you're stuffed whatever Linus chooses to write in the commit message.

blackhats don't work based off the fix, they work based on the original commit that *introduces* the bug, weeks/months/years before the fix happens (if it happens at all, there's always 0-day out there). and for the people who do work based off the fix, this very bug and its fix is proof that no amount of coverup helps: there're already at least 4 public and 2 private exploits out there for it that i know of. what was the point of the coverup then? it most definitely failed to achieve the goal of "try not to help black hats".

> There are a *lot* of patches going into the kernel each day: without
> a "OOH LOOK, THIS IS FOR HAXXORS" message

at this point *any* commit from Linus directly referencing a non-public message is an immediate red flag. he has achieved the exact opposite he wished for.

> [...]I find it hard to believe that staring at kernel commits is a good way to find vulnerabilities.

(un)fortunately, blackhats don't share your belief. remember http://seclists.org/fulldisclosure/2010/Sep/268 ?

A /proc/PID/mem vulnerability

PaXTeam — Thu, 26 Jan 2012 11:24:30 +0000

> Your article has a major error [...]

does it? let's see the timeline:

1. original bugreport: Tue, 17 Jan 2012 07:38:51 +0200
2. Linus' commit: Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)
3. Eugene's mail on oss-sec: Wed, 18 Jan 2012 10:25:55 +0800
4. CVE assigned by Kurt: Tue, 17 Jan 2012 19:30:33 -0700
5. Red Hat bugzilla #782681: 2012-01-18 02:09:22 EST
6. Fedora fix by Josh Boyer: Wed, 18 Jan 2012 15:08:53 +0000 (10:08 -0500)
7. Kees' mail on oss-sec: Wed, 18 Jan 2012 12:43:28 -0800
8. Kees' mail on the 'secret' vendor list: Thu, 19 Jan 2012 00:06:50 -0800

you're saying that something else happened between 2 and 3 on linux-distros? evidence wants to be seen! i'm also wondering how Eugene had gotten wind of the security related impact of the commit before anyone else did.

A /proc/PID/mem vulnerability

rswarbrick — Thu, 26 Jan 2012 10:28:21 +0000

... Torvalds is treating security bugs differently. They are no longer "just bugs" because some of the details of the bug are being purposely omitted. That may make it difficult for "black hats"—though it would be somewhat surprising if it did—but it definitely makes it more difficult for those who are trying to keep Linux users secure.

Well, kernels are more painful to upgrade than most other software (since you pretty much have to reboot). As such, there's always going to be a bigger window between patches going out and machines being patched. If someone is malicious and knows about what's going on in advance, you're stuffed whatever Linus chooses to write in the commit message.

However, if someone malicious is grepping through kernel commits for "suid", "privilege escalation" or the like, it doesn't make much sense to point out bugs for them. There are a *lot* of patches going into the kernel each day: without a "OOH LOOK, THIS IS FOR HAXXORS" message, I find it hard to believe that staring at kernel commits is a good way to find vulnerabilities.

A /proc/PID/mem vulnerability

danielpf — Thu, 26 Jan 2012 08:53:44 +0000

Between Torvald's attitude to not elaborate on security bugs and the security expert attitude to fully explain the bugs rather sooner than later, an intermediate attitude should be to comment security bugs gradually in depth once the patches have been applied to a reasonable fraction of users. LWN editorials do a great contribution in this direction. Not commenting bugs prevent developers to learn on the long term, and commenting bugs too early damages Linux security reputation.

A /proc/PID/mem vulnerability

kurtseifried — Thu, 26 Jan 2012 07:07:23 +0000

So I emailed this in and had an email conversation with Jake, but apparently it is not possible to amend the story to include updates/factual corrections (and Jake suggested I post this as a comment):

-----

Your article has a major error (well several but this is one of the
biggest):

"The first indication that other distributions had was likely from Red
Hat's Eugene Teo's request for a CVE on the oss-security mailing list."

Sigh. No. This issue was discussed on the vendor sec list (a list
specifically created for Linux distribution security people so they can
notify each other of embargoed issues and co-ordinate things, share
fixes, workarounds, etc.) and all the main Linux distributions (well
anyone that cares enough about security to have a security person sign
up for the vendor-sec list) knew about this issue in advance of the
public CVE request to OSS-sec.

For more information on the closed list please see:

http://seclists.org/oss-sec/2011/q2/4

if you go through the archives (look for subject line "Closed list" or
"Re: Closed list" and you'll find pretty much every major Linux vendor
is on there.

Kurt Seifried / Red Hat Security Response team

Editorial section?

nevets — Thu, 26 Jan 2012 01:26:51 +0000

If somebody actually finds a load where this matters, we'll need to revert this commit

I'm surprised someone didn't respond to this saying:

"Hey! My rootkit no longer works. Please revert this commit."

Editorial section?

PaXTeam — Thu, 26 Jan 2012 01:12:36 +0000

> I guess the question is, was it really a cover up?

that's easy to answer. using your example, you're saying that it is a matter of opinion whether a security fix says 'security fix' or just 'fix'. by that logic it is also a matter of opinion whether a filesystem corruption fix simply says 'filesystem corruption fix' or 'fix'. we know from existing commits that this opinion thing favours the first kind of description for filesystem corruptions. why does the same opinion favour the second kind then for security fixes? isn't a bug a bug after all? and let's not forget that security bugs (e.g., memory corruption ones) can very well cause filesystem corruption, one would think that they would at least be described as such in the commit, but not even that happens. inquiring minds would like to know the reason for these seemingly inconsequential decisions ;).

> One would not want to revert a commit that is a security fix.

i don't think he said everything he wanted to. my guess is that he would have continued with '...and fix it another way' but that would have given away even more hints as to the severity of the situation (it would have shown that one way or another, something really truly must be done here whereas a casual 'we will revert if needed' will make the less observative reader think that 'ok, nothing really important is going on here, at most i will see a revert in the coming days').

Editorial section?

nevets — Thu, 26 Jan 2012 00:45:17 +0000

Yeah, I could read that you were uncomfortable with this.

We'll have to discuss it over a beer at ELC in a few weeks ;-)

Editorial section?

nevets — Thu, 26 Jan 2012 00:42:36 +0000

I guess the question is, was it really a cover up? As I read what Linus wrote in the commit log, where he mentions both "/proc/<pid>/mem" and "doesn't match the permission checking" as well as "if you hold the file descriptor open over an execve(), you'll continue to read from the _old_ VM", that to me reads security vulnerability all over it.

He mentioned this as a bug fix, not a security fix. Does he really need to specify "this fixes a privilege escalation vulnerability"? Some say yes, some say no, but both choices are *opinions*!

Actually, what was left out of the article is more damning to Torvalds than what was in the article. I just read the full commit log, and if anything, this part I would consider the most incriminating against him:

"If somebody actually finds a load where this matters, we'll need to revert this commit"

One would not want to revert a commit that is a security fix. And even Linus stated that once.

I'm friends with Jake, and have had many a beer with him discussing lots of topics. As I read this article, I could hear his opinion slipping into what he wrote. Maybe, it's just me. Jake's a good guy, but he also human (that's a strike against us all). I was just stating that this article seemed to have a little more opinion in it than in other articles.

Still, I find Jake's writing superb.

Editorial section?

jake — Thu, 26 Jan 2012 00:30:25 +0000

> Jake, this article has a bit more "opinion" in it than just the facts.

I think it is not uncommon for our articles to offer an opinion, so long as it's clearly separated from the factual part. I think this is. And, no, I'm not at all comfortable with seeing information on bugs covered up. I can't really see any upside at all.

jake

A /proc/PID/mem vulnerability

PaXTeam — Thu, 26 Jan 2012 00:29:39 +0000

a technical comment:

the open permission checks play no role here because /prod/pid/mem is opened *before* the suid execve, therefore the given process has every right to do it by design. the real problem is that the open gives access to an object (mm_struct) that is then *replaced* by the execve and the read/write accessors used the new object (that open can't have seen and denied access to). in other words there was an underlying assumption (fd = content) that wasn't true and the fix ensures this assumption now.

Editorial section?

PaXTeam — Thu, 26 Jan 2012 00:13:57 +0000

i find it perfectly reasonable to describe a coverup of this magnitude and importance as 'sad' (i'm pretty sure i have used much stronger words in the past myself ;). but perhaps you can show a counter example where this kind of behaviour is not sad but a good thing? and if you think that this coverup (which somewhat ironically has already become a much bigger circus than what he so despises) is in the best interest of the kernel community, and let's not forget the users, then i'd like to hear your justification for it, as in, what do you/they gain by this (certainly no praise as i'm sure you're aware of the past flamewars ;).

Editorial section?

nevets — Thu, 26 Jan 2012 00:09:55 +0000

Maybe it's because I've had too many "beer conversations" with Jake, that I read into what he writes a bit too much ;-)

Seriously though, I didn't look at the author of the article as I read it. As I was more than half way down, I was thinking "hmm, this has the sound of Jake's opinions", and then I scrolled back up, and sure enough it was him.

Editorial section?

raven667 — Wed, 25 Jan 2012 23:56:54 +0000

I think this is well within the best standards of journalistic integrity and is not an opinion piece by the author although the second half is reporting on the opinions of others which may have confused you.

Editorial section?

nevets — Wed, 25 Jan 2012 23:37:32 +0000

By deliberately omitting important information about the bug, which is not done for most or all other bugs, perhaps they aren't so much silent as they are "muted" or, sadly, "covered up". There is definitely a lot of validity to Torvalds's complaints about the security "circus", but his reaction to that circus may not be in the best interests of the kernel community either.

Jake, this article has a bit more "opinion" in it than just the facts. It almost sounds like this is a sore topic for you.