kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Brad Spengler <spender@grsecurity.net>
To: Daniel Micay <danielmicay@gmail.com>
Cc: kernel-hardening@lists.openwall.com, pageexec@freemail.hu
Subject: Re: [kernel-hardening] Stop the plagiarism
Date: Sun, 4 Jun 2017 20:12:25 -0400	[thread overview]
Message-ID: <20170605001225.GA23953@grsecurity.net> (raw)
In-Reply-To: <1496585753.11788.1.camel@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]

> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2017-06-05  0:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03 11:30 [kernel-hardening] Stop the plagiarism Brad Spengler
2017-06-03 13:53 ` Daniel Micay
2017-06-03 14:21   ` Brad Spengler
2017-06-03 15:55     ` Daniel Micay
2017-06-04  3:28       ` Brad Spengler
2017-06-04 14:15         ` Daniel Micay
2017-06-05  0:12           ` Brad Spengler [this message]
2017-06-05  1:21             ` Daniel Micay
2017-06-05  1:44               ` Daniel Micay
2017-06-04 12:49       ` Brad Spengler
2017-06-04 13:48         ` Hector Martin
2017-06-04 14:44           ` Brad Spengler
2017-06-04 16:59             ` Hector Martin
2017-06-03 15:08 ` Lionel Debroux
2017-06-03 15:16 ` Matt Brown
2017-06-03 17:32 ` Rik van Riel
2017-06-04  7:16 ` Kees Cook
2017-06-04 11:43   ` Brad Spengler
2017-06-06  0:29     ` Kees Cook
2017-06-06 13:05     ` [kernel-hardening] " Jonathan Corbet
2017-06-05 17:43   ` [kernel-hardening] " Pavel Labushev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170605001225.GA23953@grsecurity.net \
    --to=spender@grsecurity.net \
    --cc=danielmicay@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=pageexec@freemail.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).