Date: Sun, 04 Jun 2017 21:21:09 -0400 From: Daniel Micay <danielmicay@...il.com> To: Brad Spengler <spender@...ecurity.net> Cc: kernel-hardening@...ts.openwall.com, pageexec@...email.hu Subject: Re: Stop the plagiarism On Sun, 2017-06-04 at 20:12 -0400, Brad Spengler wrote: > > And yes my "excuse" is consistent with what I said on GitHub. I > > became > > of the stack canary issue when Jann Horn told me about it months > > ago. I > > might have IRC logs from back then. I then assumed it was going to > > get > > fixed and promptly forgot about it as I do with pretty much every > > other > > specific bug. I noticed it again when making related changes in > > CopperheadOS but: that's a 3.18 LTS kernel and 3.10 LTS kernels for > > older devices, so it didn't occur to me than Jann might not have > > gotten > > it fixed in master, and arm64 doesn't use the per-task canaries so I > > didn't need to fix that or add the zero byte there yet. Not sure > > what is > > so hard to understand about that. I noticed it still wasn't fixed > > when > > first making linux-hardened by porting those changes ahead. > > > > If I *had* done research into the issue to point to when it had been > > first discovered by someone, I wouldn't have found PaX. You don't > > have > > You wouldn't have found PaX eh? I'm stating that I wouldn't have found PaX as the origin, as I've said several times. You linked me to an early mention from 2007 on a mailing list after deciding to throw a fit about this on IRC. That mailing list post from 2007 with a fix for this doesn't mention PaX. > Here's some more history then: > From "months ago", October 2016: > https://patchwork.kernel.org/patch/9405499/ > Here's a thread where Jann submitted the same patch as you, where he > mentions it's from PaX (just that PaX used pax_get_random_long()). > You participated in this thread, it's even in the reply context your > reply includes -- look for yourself. Here's a direct link: > http://firstname.lastname@example.org/msg1262143.ht > ml He doesn't say it's *from* PaX. He states that the change is already in PaX. My understanding then was that Jann found the problem. That's why I talked to Jann about it when I stumbled on it again and noticed it hadn't been fixed. As far as I was concerned, it was one of his bug finds since that's what he does: finding bugs in the Linux kernel, including ones that he reported to you for grsecurity features. > Then you submitted it upstream and took credit for yourself: > https://marc.info/?l=linux-kernel&m=149390477311752&w=2 I submitted that patch after talking to Jann about it again. I am not 'taking credit' for discovering anything by submitting a one line change migrating it to get_random_long to the write people with a justification for doing it. We both simply wanted to get a one line change fixing it landed upstream. The change in PaX isn't even the same thing: pax_get_random_long is not a CSPRNG, get_random_long is a CSPRNG (since recently at least). > > You don't have > > patches uploaded on the site from before the earliest mailing list > > post > > that you pointed me at, which doesn't mention PaX. > > There are no patches currently on the website that you can download at > all, > does it mean it's fine to take credit for everything in PaX because of > that? > Sorry but this is a really lame excuse. I didn't take this change from PaX. What actually happened != an excuse. I'm also simply not going to do deep research into whether someone else has made tiny changes like this before. I didn't do any research into whether anyone had previously fixed the assorted buffer overflows that needed to be fixed for FORTIFY_SOURCE either. I'm not concerned with whether someone else found one of those bugs before and didn't get a fix for it landed upstream. If I'm actually using their fix for it, I'll credit them for it. I'm pointing out that if for some reason I HAD felt like wasting my time doing research into it, Google wouldn't have found what you're pointing to. At best I would have found the mailing list post you showed me. > You can agree that 2006 is < 2007 Sure, but I don't agree that there's any relevance to who actually found this bug first. What if someone found it even earlier than PaX and suddenly shows up here claiming that? Is that relevant? No. The fix didn't come from them, and it didn't come from PaX. If you were so concerned about getting credit for this, you could have gotten the bug fixed upstream. > established that on github No, we didn't. You also deleted your GitHub account so I wasn't able to look back at what you said anymore. I have no idea what you said there. I remember you saying PaX fixed it in January 2007 and then it seems someone else found and fixed it independently later in 2007. > wouldn't have led to PaX. So let me show you for future reference how > trivial this is: > https://github.com/linux-scraping/linux-grsecurity/blame/grsec-test/ke > rnel/fork.c > ctrl+f get_random_long > note: "11 years ago" on the left > That took all of 10 seconds. > > Again not that any of this matters, it's one of many stupid security > weaknesses upstream developers never cared to fix for years, but if > we're going to be making up stories as excuses, let's at least get it > right. So can we agree it's a case of cryptomnesia, or at minimum you > remembered the facts wrong? I'm not making excuses, lying, or forgetting why I was aware of this. It's fine if you don't believe me and you want to believe that there was a conspiracy to steal credit for this from you. > BTW while doing research I found: > http://linux-arm-kernel.infradead.narkive.com/mAf9QhdP/patch-1-5-rando > m-stackprotect-introduce-get-random-canary-function > which credits "ascii armor" to execshield and PaX/grsecurity. > We've never done ascii armoring in PaX/grsecurity and the technique > was > created by solar designer in 1997: > http://insecure.org/sploits/linux.libc.return.lpr.sploit.html > Exec Shield arrived at least 5 years later. > > -Brad I've never written a commit message referencing 'ascii armor' or 'exec shield'. Not something that's ever been on my radar, unlike glibc using the leading zero byte for the SSP canary even on 32-bit.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.