Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy

From: Brad Spengler (spender_at_grsecurity.net)
Date: 01/27/05

  • Next message: Michal Zalewski: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy" 
    Date: Thu, 27 Jan 2005 13:21:45 -0500
To: Arjan van de Ven <arjanv@redhat.com>

    > I think the joke is on you in this case. There is a large patch series of
    > which you judge the first steps only. Those steps introduce the
    > infrastructure and concepts into the kernel, and later patches will tweak
    > the exact numbers to values with more entropy. ONCE THEY EXISTING
    > INFRASTRUCTURE IS ACCEPTED AND DEBUGGED.
    >
    > Maybe you don't understand that, I assume a lot of the other readers of this
    > list do. You don't plop a huge patch in the linux kernel in one chunk. You
    > do it in nice small, incremental and debuggable steps.

    If Exec-shield is any model for what you plan to turn this into, my
    comments still apply. If you like, I'll simply send out the same email
    months from now when you "finalize" this patch into the level of
    security you claim it to be able to provide (which will never happen,
    since you won't be providing any bruteforce deterrence, so it doesn't
    matter if you increase the randomization by a couple more bits).

    I should also add that the stack randomization present in this patch and
    that in exec-shield can be bypassed by tossing enough data into the
    stack, like "/bin/sh" over and over, since the amount of randomization
    is smaller than the stack itself. I should also note that the latest
    output of paxtest I could find against exec-shield shows that the amount
    of randomization for shared libraries is the same as in the patch you
    sent to LKML. So if your argument is that you agree these values are
    stupidly low, you're not saying much about your own "enterprise-grade"
    software ;)

    I would also like to correct a mistake in my previous mail. The glibc
    issues are indeed fixed in the latest FC3 glibc, which was released on
    December 27th, 2004, nearly 3 1/2 months after the bug was initially
    reported. The glibc update was not released as a security update
    however, so many users are still affected (like the two Fedora
    developers I contacted).

    -Brad

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Michal Zalewski: "Re: [Full-Disclosure] "Advances in Security" in the Linux Kernel and RedHat idiocy"

    Relevant Pages

    • Re: [PATCH] OpenBSD Networking-related randomization port
      ... > on it and also studying what features of grSecurity can be implemented ... > concrete it adds support for TCP ISNs randomization, ... > and also for future patch submissions), ... and the security threat reduction. ...
      (Linux-Kernel)
    • [PATCH] OpenBSD Networking-related randomization port
      ... Attached you can find a split up patch ported from grSecurity, ... Linus commented that he wouldn't get a whole-sale patch, ... concrete it adds support for TCP ISNs randomization, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH] [RESEND] PIE executable randomization
      ... below is a respin of the patch for executable code address randomization ... reverted because of bugreports stating that klibc binaries segfault due to ... This patch is using mmap's randomization functionality in such a way ...
      (Linux-Kernel)
    • Re: [PATCH][RESEND] PIE randomization
      ... randomization _is_, nor why the kernel would want to do it. ... I could reverse-engineer that info from the patch, I guess, but I'd prefer ... executables) and brkrandomization still seem to be missing to make it ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)
    • Re: [PATCH][RESEND] PIE randomization
      ... This patch is using mmap's randomization functionality in such a way ... ET_DYN binaries onto a random address is allowed ... Then load_addr (it is a load bias actually) returned from load_elf_interp ...
      (Linux-Kernel)