Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 4 Jun 2017 20:12:25 -0400
From: Brad Spengler <spender@...ecurity.net>
To: Daniel Micay <danielmicay@...il.com>
Cc: kernel-hardening@...ts.openwall.com, pageexec@...email.hu
Subject: Re: Stop the plagiarism

> 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?

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://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262143.html
Then you submitted it upstream and took credit for yourself:
https://marc.info/?l=linux-kernel&m=149390477311752&w=2

> 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.

You can agree that 2006 is < 2007 right?  I thought we had already
established that on github, but now you're claiming any amount of research
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/kernel/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?

BTW while doing research I found:
http://linux-arm-kernel.infradead.narkive.com/mAf9QhdP/patch-1-5-random-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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

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.