flink() at last?
flink() at last?
Posted Aug 12, 2013 20:55 UTC (Mon) by luto (guest, #39314)In reply to: flink() at last? by spender
Parent article: flink() at last?
I presume that 51f7f259cb6a0d5e380dcd2286c64118809d8df19761c1699b60001d55126c0b is the sha256 hash of something. If so, it will establish that you know something now, but it's not helping me or the other kernel contributors.
In any case, if you can explain what's wrong with my patch and if I fix it, I will certainly attribute it properly.
Posted Aug 12, 2013 22:33 UTC (Mon)
by PaXTeam (guest, #24616)
[Link] (8 responses)
kernel devs who censor security related information from patches. (e.g., what happened to the CVE that was already assigned by the time the patch got written?)
> The advisory came to (at least) me and Oleg via Petr Matousek [...]
and what did his email start with? let's see:
> spender reported [...]
that and the link to his twitter weren't enough to figure out who to credit?
> Maybe we were supposed to figure out what "b836010000bb00000010cd80ebf2" meant?)
not sure who 'we' is, but Petr did that work for you regardless and if you hadn't quoted him selectively you'd have also realized what it meant:
> b836010000bb00000010cd80ebf2 is for(;;)unshare(1<<28);
can't be more concise, can it? one wonders how you were able to pull off that vsyscall change 2 years ago (nice not crediting me there btw) when you seemingly don't even recognize x86 asm.
> If so, it will establish that you know something now, but it's not helping me or the other kernel contributors.
yes, that's kinda the point behind publishing hashes only. as for helping you, we won't disclose such information because it would then be censored (just look at what happened recently with rmk's arm fixes) which is a game we will never play. this is not negotiable.
Posted Aug 13, 2013 0:50 UTC (Tue)
by luto (guest, #39314)
[Link]
Posted Aug 13, 2013 5:05 UTC (Tue)
by alonz (subscriber, #815)
[Link] (4 responses)
You've joined the dark side. Completely.
Posted Aug 13, 2013 13:14 UTC (Tue)
by spender (guest, #23067)
[Link] (3 responses)
The main point was the complete absence of any mention of security impact in the commit message (what the "censorship" of disclosure) was referring to. Choosing not to attribute it as well was just the icing on the spite cake.
Here are the facts:
No CVE or impact at all was mentioned in the commit
Since when does my sphere of responsibility extend beyond my own users? Any direct reporting we've done is not under any kind of obligation (of the kind upstream has to the code they distribute), and you should understand it in that context. We find and fix tons of problems in the upstream kernels, including finding many security fixes that fall through the backporting cracks (due in large part to the active cover-up policy) -- this is but one minor example because I chose to directly report it due to the apparent complete absence of QA regarding the use of unprivileged user namespaces. As I mentioned in my commit message, it's a trivial, 22 character local DoS (which I think may be the smallest ever reported).
Now, try hard to think about this as a smart person would: if some group were consistently finding vulnerabilities in my software, would it not be wise to monitor that code to spot those things, given that they're not being obfuscated at all? Apparently in 13 years, the Linux kernel devs still have not figured this one out. "That's work they shouldn't have to do!" a hypocrite might say. Yes, just as I shouldn't have to be scouring upstream commits (across all developers, not just us two, so there's quite some asymmetry of effort here) to find the silent security fixes falling through the cracks.
I believe in the old adage that actions speak louder than words. I've "joined the dark side" because I refuse to support and enable a system actively engaged in pulling the wool over your eyes as to the security of their code? Apparently as the arbitrator of ethics and morality, do you suggest I continue to piss away one-off vulnerabilities so they can be fixed in a one-off fashion with the associated coverup? Do you not see the long-term ramifications of that in pursuit of some short-term benefit?
-Brad
Posted Aug 13, 2013 15:07 UTC (Tue)
by idle (guest, #5017)
[Link] (2 responses)
Well, the changelog explains that we leak the memory. Doesn't
I do not think that the fact it was reported via oss-sec list
But. I am really sorry I didn't add Reported-by tag, seriously.
Posted Aug 13, 2013 15:41 UTC (Tue)
by spender (guest, #23067)
[Link] (1 responses)
There is only vague mention of unspecified "side effects" that need "taking care of" in response to a function failure. Failures can be of the unfailable kmalloc+GFP_KERNEL kind, after all. I wonder how anyone, not already knowing about the CVE and public disclosure from elsewhere, would have any clue what the impact of that fix is.
Are you really trying to say the commit message was written with clarity and transparency of the impact of the fix in mind, without some Linus-enforced brain filter on what words you're allowed to use to describe the "bug"?
-Brad
Posted Aug 13, 2013 16:07 UTC (Tue)
by idle (guest, #5017)
[Link]
I thought that "take care of" should be clear enough, and it
> There is only vague mention of unspecified "side effects"
This just tries to explain why the patch didn't change the
> Are you really trying to say the commit message was written
OK. When I reread it I agree, it could be more clear. Trust me,
It would be just silly, exactly because it was not me who founf
> Linus-enforced brain filter on what words you're allowed to
What are you talking about ;) Nobody will ever try to force you
Posted Aug 13, 2013 8:14 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Aug 13, 2013 8:41 UTC (Tue)
by PaXTeam (guest, #24616)
[Link]
not the least because an assembler (a tool) is a very different animal from assembly (a language) and my use of 'asm' didn't refer to either ;).
flink() at last?
I didn't write the patch, so I had rather little to do with crediting anyone. And I completely failed to parse Petr's explanation. Sorry.
flink() at last?
By saying "we won't disclose such information because it would then be censored" you're revealing your true face—helping the community is a minor goal compared to the fame you get by being credited for all the security bugs.
flink() at last?
flink() at last?
I reported this directly to Petr on IRC
I had already fixed the vulnerability myself in the one affected grsecurity patch the night before, with an unmistakable commit message
Security impact was known at the time the patch was created
A CVE had already been allocated prior to the patch being created
It seems that despite a bug being a bug (according to Linus) the advice from Andrew Morton (https://lkml.org/lkml/2012/6/13/502) continues to be ignored quite often specifically for security vulnerabilities
https://git.kernel.org/cgit/linux/kernel/git/stable/linux...
Everyone whose name appears on that commit is complicit in the behavior, no matter what they say about how they really feel about the upstream security disclosure policies on private mailing lists or in private mail because they don't want to upset Linus' silent-fix campaign.
flink() at last?
> security impact in the commit message
this obviously mean the bad impact?
does matter, the bug is bug. In fact I didn't even notice this
list in CC.
This is only because I didn't know whom should we thank. I sent
the patch for review and I specially asked about the reporter,
but the patch was merged immediately and I could not update the
changelog.
flink() at last?
flink() at last?
> in the commit message.
mentions put_cred().
caller instead, the patch would be even simpler.
> with clarity and transparency of the impact of the fix in mind
this was not intentional. I did not try to "hide" the fact this
patch fixes the easily triggable memory leak.
the bug!
> use to describe the "bug"?
obfuscate the changelog.
There's a difference between recognizing x86 machine code and recognizing x86 assembler; it's not like it's a PDP-11 where the octal dump is human-readable with only a modicum of skill.
flink() at last?
flink() at last?