User: Password:
|
|
Subscribe / Log in / New account

An ancient kernel hole is closed

An ancient kernel hole is closed

Posted Aug 20, 2010 9:50 UTC (Fri) by chad.netzer (subscriber, #4257)
In reply to: An ancient kernel hole is closed by PaXTeam
Parent article: An ancient kernel hole is closed

> you mean the one that he had to fix like 3 times?

How irrelevant. I suppose you just give up after the first try? They touch completely different sets of files, which context allows you to understand is the point. AA's patch was more intrusive.

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

"404 - Unknown commit object"

>with due respect to Andrea's efforts, there was really no need to touch arch
>specific code

So you admit the patch shouldn't have been accepted.

> it's still the right idea and approach

You just admitted that it was the wrong approach, since it touched arch files it didn't need to, etc.

Which vendor or distro included AA's 2004 patch, since you now claim it is "the right approach"? If you've got a (working) link to a vendor commit, from a long time ago, you will begin to have a better argument.

> [a compelling case was presented] in 2004-2005 already

You've previously claimed that Linus and the other kernel developers are "not qualified" to make judgements about security patches "due to lack of expertise".

http://lwn.net/Articles/373896/

So, what have the security "experts" come up with that is better than Linus's solution, and why not 5 years ago when they discussed it? Where is the non-butt-ugly-hack fix that you advocate?


(Log in to post comments)

An ancient kernel hole is closed

Posted Aug 20, 2010 11:56 UTC (Fri) by PaXTeam (guest, #24616) [Link]

> How irrelevant.

it'd be relevant if you hadn't carefully omitted some bits of my response ;). you see, those bugs could have been found and fixed before committing the patch had they been discussed publicly. there's some irony in that it was you in the first place who was asking about "the security community nagging LKML about this issue that whole time" and now you find it irrelevant that discussion of this long sought-after fix missed LKML.

> They touch completely different sets of files

so you admit that your claim of "Linus's patches, which *only* touch mm/memory.c" is flat out false.

> AA's patch was more intrusive.

how do you measure intrusiveness? but besides that, whether something is more or less intrusive is of secondary importance when it comes to correctness (and not to mention that ugly hack about lying about vma boundaries).

> "404 - Unknown commit object"

oops, a stray 'v' slipped into the url, here's the correct one: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... .

> So you admit the patch shouldn't have been accepted.

not at all. what often happens is that a problem gets fixed and later refined, even simplified. just look at the evolution of rmap, there were quite a few rounds of complexity added only to be removed later. it also happens sometimes that a problem gets fixed on a specific arch only then gets generalized (and simplified) for all/most archs. the need for evolution is not a reason to prevent code from entering the tree.

> You just admitted that it was the wrong approach, since it touched arch files it didn't need to, etc.

Chad, i think you should stop commenting on issues you clearly have no idea about. 'approach' here means solving the heap/stack gap problem by either stopping stack growth at the automatic vma expansion level or detecting stack expansion attempts at the lower guard page access level. it's an implementation detail where you add the detection logic in either case and can of course always be discussed/refined/etc (something that didn't really happen for either approach).

> Which vendor or distro included AA's 2004 patch, since you now claim it is "the right approach"? If you've got a (working) link to a vendor commit, from a long time ago, you will begin to have a better argument.

it's irrelevant to correctness who included it but it was present in -mm of the time and also SuSE, IIRC, but you'll have to do the digging yourself i'm afraid.

> You've previously claimed that [...]

How irrelevant. (tm)

seriously, do you understand the difference between being able to *recognize* a security issue in *existing* code and *writing* *new* kernel code to solve problems? by the look of it, you still don't quite get it.

> So, what have the security "experts" come up with that is better than Linus's solution, and why not 5 years ago when they discussed it? Where is the non-butt-ugly-hack fix that you advocate?

now that you (hopefully) understand what 'approach' means in this context, i believe you can answer these questions yourself.

An ancient kernel hole is closed

Posted Aug 20, 2010 17:47 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

> it'd be relevant if you hadn't carefully omitted some bits of my response ;).

Your response was "you mean the one that he had to fix like 3 times?" It didn't seem worth repeating; now you forced me to...

> you see, those bugs could have been found and fixed before committing the patch had they been discussed publicly.

Oh, so instead of being a snarky response to *my* comment that you quoted immediately prior, about comparing the two approaches, it was an unrelated response to a *completely* different issue; I should have guessed you'd bait-n-switch on me. Why'd you quote me if your response wasn't the issue you were replying to?

As I said, it was an irrelevant response.

> so you admit that your claim of "Linus's patches, which *only* touch mm/memory.c" is flat out false.

Hold on, your link was broken, and I now learned that the web engine doesn't automatically match prefixes. A "git log d7824370e" would have worked had I been near my repo at the time.

Ohhhh, so *now* you mean that a follow up patch, which is not actually the security fix, also touches 2 more files, and *that* is what I should have mentioned? The patch which has *no equivalent* in the 2004 AA patch, so it wasn't necessary to point out in my comparison (thus I didn't link to it)? Pathetic. That patch is explicitly mentioned in the article, you only needed to have said that (ie, I had already seen it).

[SNIP]

> Chad, i think you should stop commenting on issues you clearly have no idea about.

Oh, yes sir.

Understanding the security issue isn't hard; the article explains it nicely. But it isn't the guard page (or gap) itself that is the issue of discussion here (clearly those involved see that as a solution), it is the means of implementing that solution in code in a way that could make its way upstream in a decent timeframe.

> it's irrelevant to correctness who included it but it was present in -mm of the time and also SuSE, IIRC, but you'll have to do the digging yourself i'm afraid.

So you claim the 2004 patch *was* accepted and included by a vendor (I'll accept that claim on faith). THAT is the whole point. If there was an implementation not only proposed, but also accepted and put in use (ie. tested), then that is (finally) evidence there was a fix in use in the field, that wasn't filtering up into Linus's tree. That is clearly a problem, I concede that. Why couldn't you just say that?

> How irrelevant. (tm)

You are unoriginal.

> by the look of it, you still don't quite get it.

And condescending. Since it was *you* who mentioned the butt-uglyness of the implementation of the accepted solution, it is perfectly reasonable to assume you have issues with the coding details of the guard page/gap solution (not the guard/gap concept itself), which *again* was what my response was specifically addressing. So now you re-define what I meant by 'approach'; that's dishonest.

> now that you (hopefully) understand what 'approach' means in this context

The 'approach' in this discussion was NEVER about the issue of whether the guard page/gap concept itself is the right fix. So why are you mentioning that now, and presuming it is *me* who doesn't understand? You wanna claim that the security expert's job is to "recognize" issues in existing code, and not "write new kernel code" to fix it, then stop yammering about the coding details of the solution UNLESS you are claiming that it is insecure? Is it?

Your ego based, toxic form of communication is a thread killer, and it wasn't worth initially responding to. I thought you'd shed some light. If you are at all representative of how insanely frustrating it must be for implementers to get security feedback on their code, it helps explain why there can be such a long disconnect. I guess that is somewhat enlightening in itself.

An ancient kernel hole is closed

Posted Aug 20, 2010 18:40 UTC (Fri) by sbishop (guest, #33061) [Link]

Your ego based, toxic form of communication is a thread killer, and it wasn't worth initially responding to. I thought you'd shed some light.

Yeah, it's funny given the Latin meaning of "pax".

I remember when PaXTeam and spender first showed up here and we thought they were the same person. The difference seems to be that spender can be worth engaging. PaXTeam seems to be a symbolic link to /dev/vitriol.

An ancient kernel hole is closed

Posted Aug 20, 2010 20:30 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

Check out their commenting on Joanna Rutkowska's blog posting (if you like watching these kind of train wrecks).

http://theinvisiblethings.blogspot.com/2010/08/skeletons-...

An ancient kernel hole is closed

Posted Aug 21, 2010 14:31 UTC (Sat) by PaXTeam (guest, #24616) [Link]

hey, i got an ever better one you can chew on: http://lists.immunitysec.com/pipermail/dailydave/2010-Aug... ;)

An ancient kernel hole is closed

Posted Aug 20, 2010 20:32 UTC (Fri) by zakalwe2 (guest, #50472) [Link]

PaXTeam is a gentleman and a scholar. Every time I have had an issue with PaX on a new kernel release he extremely helpful and a fountain of knowledge. Your fanboy defence of linus was worthy of attack by someone who has worked tirelessly to improve the real security of linux and got nothing but grief for his efforts. It is only because of spender and the pax team that the upstream kernel developers stubborn, cavalier attitude towards security is being eroded and the real security of your systems being improved.

An ancient kernel hole is closed

Posted Aug 20, 2010 21:13 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

Whatever. Give them credit for their work where it is due (absolutely). But people who hijack threads with twisted misrepresentations of what is being discussed are ruinous to the value of this site.

My "defense" of Linus against what seems an unwarranted accusation is justified since no one has adequately explained why the 2004 patch didn't get reworked into an acceptable solution that then got promoted upstream. It now seems less of a technical issue, and more of a communication issue, and I'm seeing *ample* evidence to suggest what kind of factors may have led to that unfortunate situation.

On a side note, to both 'cde' and 'avik', I appreciate your input. In particular 'cde', whom I took issue with stating this was a problem of "priority". This further convinces me it isn't a matter of priorities, but personalities, and "we" may indeed have been denied an earlier fix solely because of it. Thankfully, the right personalities belatedly addressed this particular issue.

An ancient kernel hole is closed

Posted Aug 20, 2010 21:12 UTC (Fri) by spender (subscriber, #23067) [Link]

Here's a question: before entering in a discussion with the PaX Team, did you bother to do any research of your own? Did you, for instance, read Gael Delalleau's 2005 presentation? Did you specifically read slide 24 and onward? Did you bother to read any of the news articles recently that had mentioned that SuSE has had the fix since SuSE Linux Enterprise 9 (released in 2004)? Had you bothered to create the following test application for instance and see how it happily accesses over the stack gap (using gcc 4.3.2 here but it applies to every other gcc version)?

int main(void)
{
char buf[4096];
char buf2[4096];

strcpy(buf2, "hello");

printf("%s\n", buf2);

return 0;
}

You'll notice the beginning of main() gets compiled by gcc to:
lea ecx, [esp+0x4]
and esp, 0xfffffff0
push dword ptr [ecx-0x4]
push ebp
mov ebp, esp
push ecx
sub esp, 0x2014 <--- look here
mov dword ptr [esp+0x8], 0x6 <--- and now here
mov dword ptr [esp+0x4], 0x80484f0

See, if you had done any research, you would have known about this behavior and known why then a single hardcoded guard page isn't acceptable in certain contexts for security. You'd know that Windows and MSVC don't have these problems. You would also have known about the additional hacks Linus added specifically to account for an incompatibility with an LVM app (after the stable kernels were already released and his buggy patch was pushed out without community review, causing oopses on some machines in addition).

From all of these reasons you would have known why the PaX Team objected to the patch itself and the way it was created and could have engaged in a reasonable discussion, yet with no knowledge and no intention of obtaining any on your own (you decided to take it "on faith" that Andrea's patch was used by SuSE) you chose to argue.

Why is it that people like you choose to engage in heated arguments with people who *have* done their research when it's evident that you've done absolutely none? How about taking responsibility for your own actions and behavior?

-Brad

An ancient kernel hole is closed

Posted Aug 20, 2010 21:39 UTC (Fri) by chad.netzer (subscriber, #4257) [Link]

Since you're the expert, is the current kernel fix adequate, or not? If not, what can be done to fix it?

I'm not the one claiming to be the security coding expert, but I *AM* now claiming that some of these experts are apparently an enormous pain to have to deal with.

> you decided to take it "on faith" that Andrea's patch was used by SuSE

I said that specifically *because* that was what PaXTeam claimed and *I* was giving him credit for probably being correct! I was attempting to be cordial on that point. And now you take umbrage, and try to hang me for it...

I'm done. You've successfully shouted down another inquisitor. Thanks for all your efforts with improving Linux security (sincerely; I can see you have enormous talent), but I don't need to put up with your distortions of my meaning, intent, and words.

An ancient kernel hole is closed

Posted Sep 3, 2010 0:20 UTC (Fri) by nix (subscriber, #2304) [Link]

You would also have known about the additional hacks Linus added specifically to account for an incompatibility with an LVM app
Well, the LVM app was doing something sufficiently bizarre that if you'd asked me beforehand, I'd have said of course nobody would do anything like that. (I mean, parsing /proc/self/maps and mlock()ing everything you see? Why not mlockall()? Why would it fail for the guard page yet not for the vdso or vsyscall pages? Well, now we know.)

So, Linus didn't test every single app in the entire world before releasing a security fix. He didn't even test every ramification of every app on his machine. That's simply terrible. He should be publically whipped.

An ancient kernel hole is closed

Posted Aug 21, 2010 14:29 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> Your response was "you mean the one that he had to fix like 3 times?"

i know what my response was but it wasn't the only thing what i was referring to (piece of advise, if i may: when you read some text next time, try to see the forest for the trees ;). if you parse your own statements in context in this thread, you'd have realized that you'd previously asked about the security fix being discussed on LKML:

> Was the security community nagging LKML about this issue that whole
> time? (if they were, I'll gladly retract my claims that this is BS).

now my comment you called irrelevant was merely hinting at the fact that this rush of fixes on top of fixes (which made it into the -stable trees after a week only btw, what's your take on that?) could have been avoided had the discussion actually taken place in public on LKML. i see that you still haven't connected the dots though, but i was actually saying that yes, you are right to raise the issue: what you were asking about (public discussion) would actually have been important (something i explained in my previous response too, apparently to no avail). man, i'm beginning to wonder if i'll ever be able to please you! ;)

> Oh, so instead of being a snarky response to *my* comment that you
> quoted immediately prior, about comparing the two approaches, it was an
> unrelated response to a *completely* different issue;

comparing two approaches involves more than the raw code itself, the design/submission/discussion/refinement/etc processes are all part of it. you know, it's called software development. and yes, the two approaches went through quite a different development process.

> Hold on, your link was broken, and I now learned that the web engine
> doesn't automatically match prefixes.

it does, you just have to supply it with a valid prefix (a 'v' isn't part of it).

> Ohhhh, so *now* you mean that a follow up patch, which is not actually
> the security fix, also touches 2 more files, and *that* is what I should
> have mentioned?

what you call a follow up patch (btw, did you see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... ?) would actually have been part of the actual security fix had the problems with it been recognized originally. you know, as it normally happens in the public discussion/review process that kernel developers use for, well, development.

> The patch which has *no equivalent* in the 2004 AA patch, so it wasn't
> necessary to point out in my comparison (thus I didn't link to it)?

it has no equivalent because his approach didn't need such crap workarounds. speaking of comparisons, do you realize that comparing things involves pointing out both similarities and differences? unless of course you want to have a skewed one.

> Pathetic.

looks like i must have touched on a nerve ;).

> That patch is explicitly mentioned in the article, you only needed to
> have said that (ie, I had already seen it).

are you implying that you read everything else explicitly mentioned in the article, including Gaël's paper? ;)

> But it isn't the guard page (or gap) itself that is the issue of
> discussion here (clearly those involved see that as a solution),

yes, that is exactly the issue here. you either prevent the stack VMA from growing next to another VMA for good, or you allow that growth but prevent actual use of the stack guard page (ideally, that'd be 'pages', but let's not digress). clearly, Linus didn't like the first approach for some reason we'll probably never learn, so he implemented something else instead.

> it is the means of implementing that solution in code in a way that
> could make its way upstream in a decent timeframe.

implementation details are just that, details. first comes overall design and obviously you don't get to write code until there's agreement on the 'right approach'. now as far as we know, such discussion never took place in public for Linus's solution, it just magically happened (and got fixed like 3 times, and broke all -stable releases in one fell swoop, for a week). call it what you want, i find *that* pathetic.

> So you claim the 2004 patch *was* accepted and included by a vendor (I'll accept that claim on faith).

no need to, you can just dig out the SuSE kernel trees of the time (and ever since, i hear) and see for yourself. or you can just take *their* claims on faith: http://support.novell.com/security/cve/CVE-2010-2240.html .

> That is clearly a problem, I concede that. Why couldn't you just say that?

uhm, say what exactly?

> You are unoriginal.

well, what can i say, it was your term, not mine, so suit yourself ;).

> And condescending. Since it was *you* who mentioned the butt-uglyness of
> the implementation of the accepted solution, it is perfectly reasonable
> to assume you have issues with the coding details of the guard page/gap
> solution (not the guard/gap concept itself), which *again* was what my
> response was specifically addressing. So now you re-define what I meant
> by 'approach'; that's dishonest.

Chad, before indulging in more name calling, you might pay attention to what i've been trying to explain to you already: there is *no* guard/gap concept per se. these are *two* *different* concepts. you either have an enforced address space gap *or* you don't but have a guard page instead at the boundary. can you understand this?

> The 'approach' in this discussion was NEVER about the issue of whether
> the guard page/gap concept itself is the right fix. [...]

since these are two different concepts, of course the discussion was always about which one was better.

> So why are you mentioning that now, and presuming it is *me* who doesn't understand?

because you obviously didn't understand the conceptual (let alone implementation) difference between the two. heck, you apparently believed that they were the *same*.

> You wanna claim that the security expert's job is to "recognize" issues
> in existing code, and not "write new kernel code" to fix it, then stop
> yammering about the coding details of the solution UNLESS you are
> claiming that it is insecure? Is it?

i tried to parse this a few times but still can't figure out what you were trying to say here, but back to your original statement:

> You've previously claimed that Linus and the other kernel developers
> are "not qualified" to make judgements about security patches "due to
> lack of expertise".

instead i said this:

> [..]they're simply not qualified to make such judgement calls due to
> lack of expertise.

now what was the judgement call to make in question? quoting dlang:

> the kernel developers and stable team have decided not to try and judge
> which patches are security fixes and which are merely bugfixes.

so what i said was about deciding whether any given patch (newly written code) has security implications or not (i.e., it fixes a security problem, and then let's not get started about recognizing patches that introduce said problems...). i never once mentioned 'security patches' in there, something you were trying to (mis)attribute to me. think about it, if a patch is known to be a 'security patch' (assuming you mean a patch that fixes a known security issue such as this heap/stack gap issue) then there's no need to judge anything, it is a security fix and that's it (mind you, as Jake pointed it out as well, Linus conveniently 'forgot' to omit this little fact from the commit).

so what security experts do is recognize security issues in code (among others), whereas kernel developers write that code (including security fixes, that then gets analyzed by security experts, ad infinitum). it's two very different mindsets, although there're some people who are good at both.

> Your ego based, toxic form of communication is a thread killer, and it
> wasn't worth initially responding to. I thought you'd shed some light.

i explained a few times already what you don't understand, but then i guess there's only so much one can do ;). when you get over yourself, you might realize that if you stop acting like an RVI, you won't be treated as one.

An ancient kernel hole is closed

Posted Aug 21, 2010 20:39 UTC (Sat) by chad.netzer (subscriber, #4257) [Link]

This 'fisking' style of back and forth responses to specific lines of text doesn't seem to be helping.

Basically, there is a response to a specific point with a new point (or implied new point), without enough context to show how it's related, and there's just a pointless adversarial back and forth.

One of your recurring points in this thread is there was no public discussion of this new patch (or series of patches, really). Which is a fine point to raise, and worth a thread of its own (as it's mentioned in the LWN article). I don't disagree with the criticism of that point. But working it in as a response to an unrelated (IMO) one line quote, is not useful. Rather than a discussion on a good new, and related issue, it leads to a confused argument.

Note, I gave you credit (I felt) for answering my question about which vendors had already guarded against this (SuSE), and I conceded that that was damning evidence about the development and upstreaming process, and a *core* point to make. So, thanks for that.

I'm done with the arguing. I learned a few things, I hope it wasn't a waste of space for the site. However, I am not continuing it.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds