Date: Thu, 15 Feb 2024 19:08:07 -0700
From: n132 <y0un9n132@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: security@...nel.org, linux-hardening@...r.kernel.org
Subject: Re: Two Seucrity Issues for arch_randomize_brk(arch/x86/kernel/process.c)

On Wed, Feb 14, 2024 at 3:31 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Wed, Feb 14, 2024 at 01:31:47PM -0700, n132 wrote:
> > Dear Linux Kernel Security Team,
> >
> > I am writing to bring to your attention some security vulnerabilities I
> > have discovered in the `*arch_randomize_brk*` function located in `
> > *arch/x86/kernel/process.c*`. This function is critical for generating a
> > random offset used as the heap space offset for programs in user space. My
> > concerns are twofold:
>
> Thanks for bringing this up. FWIW, I don't think it needs to be private.
> The limitations of the brk randomization is understood. Regardless, some
> comments below:
>

Thanks for your attention to this issue.

> >
> > *tl;dt*: Heap can connect to bss's end and the offset between heap and .bss
> > is in the range of 0x2000 pages.
> >
> > 1. *Insufficient Randomization*: The current implementation, which relies
> > on a 0x2000 page offset, does not provide adequate randomness. This
> > limitation could allow attackers to brute force the heap or Position
> > Independent Executable (PIE) addresses if they acquire one of the base
> > addresses. The predictability of the offset significantly lowers the effort
> > required for successful exploitation.
>
> The brk randomization entropy was originally chosen on ia32 and came
> with some concerns about programs where randomization broke assumptions
> they had about distances between various allocations.
>
> See commit c1d171a00294 ("x86: randomize brk")
>
> This is using 13 bits of entropy, which isn't terrible. On x86_64 it's
> not as high as stack (28) and mmap (20), so I'm not convinced it's
> "insufficient" (brk is used for somewhat limited purposes). Perhaps we
> could raise this to 20 bits on x86_64? (Totally untested...)
>

20-bit entropy (same as mmap) is not bad for x64 and it's okay to keep 13-bit
entropy for x86 since the limited memory space.

> > 2. *Lack of Guard Page*: In certain instances (with a probability of
> > 1/8192), there is no guard page between the .bss segment and the heap. This
> > absence facilitates an attacker's ability to overflow from the .bss segment
> > into the heap, thereby extending the attack surface.
>
> Getting allocated next to .bss is certainly not ideal. It should be
> possible to trivially add a guard page here with something like this
> (totally untested):
>
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index ab49ade31b0d..1489829e86e2 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -1030,7 +1030,7 @@ unsigned long arch_align_stack(unsigned long sp)
>
>  unsigned long arch_randomize_brk(struct mm_struct *mm)
>  {
> -       return randomize_page(mm->brk, 0x02000000);
> +       return randomize_page(mm->brk + PAGE_SIZE, 0x02000000);
>  }
>
>  /*
>

It looks good. That is also what was in my head. Can't find another
simple and effective solution to this issue.
I did some tests for this modification, finding this can set a guard
page between BSS and heap.
Also, this modification doesn't influence other parts of the kernel
(since it just avoids one possible case).

> >
> > Given the complexity of the necessary modifications and my limited
> > experience in kernel patching, I am reaching out to seek your expertise and
> > assistance in addressing these vulnerabilities. I am looking forward to
> > your feedback and am willing to provide any further information or
> > assistance required to resolve these issues.
>
> What results would you see as solving the issues you detailed? (And feel
> free to bring this up on linux-hardening@...r.kernel.org)
>

Your fix looks good to me. We can try to solve the "bss overflow to
heap" issue first and figure out a way to
add entropy later. I also cc this email to the hardening team.

Thanks so much for your help!
- Neil

> Thanks!
>
> -Kees
>
> --
> Kees Cook

Powered by blists - more mailing lists