Re: Limited/Broken functionality of ASLR for Libs >= 2MB

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Sam James]

mail@horotw.com writes:

> Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> only arises if a lib is over 2MB).
> I confirmed this for myself but only for the 64bit case.
>
> I saw that this issue is being tracked by ubuntu
> (https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1983357).
> If this is the wrong place and I should instead report it elsewhere I
> am very sorry.

See also https://bugs.debian.org/1024149. Unfortunately, I don't
think the issue found its way upstream until now (thanks).

CCing relevant maintainers (per the Debian bug).

>
> Sources:
> https://zolutal.github.io/aslrnt/  # the page of the original
> discoverer of the bug - as far as I know
> https://infosec.exchange/@wdormann/111744168574317113
>
> How I checked that this issue is present (I used bat because it
> includes libcrypto which is a lot bigger than 2MB and not on the edge
> of 2MB like libc):
> ```python
> from subprocess import check_output
>
> def check_bit_usage(cmd):
>     res = 0x0
>     for _ in range(0, 1000):
>         out = check_output(cmd, shell=True).decode()
>         base_address = int(out.split("-")[0], 16)
>         res |= base_address
>     return hex(res)
>
> result = check_bit_usage("cat /proc/self/maps | grep ld-linux | head
> -n1")
> print(f"Result for ld-linux (smaller than 2MB): {result}")
>
> result = check_bit_usage("bat /proc/self/maps | grep libcrypto | head
> -n1")
> print(f"Result for libcrypto (bigger than 2MB): {result}")
> ```
>
> Output:
> ```
> Result for ld-linux (smaller than 2MB): 0x7ffffffff000
> Result for libcrypto (bigger than 2MB): 0x7fffffe00000
> ```
>
> This is my first time reporting an issue to the kernel so if anything
> is inappropriate please let me know.

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Matthew Wilcox]

On Mon, Jan 15, 2024 at 04:40:36PM +0000, Sam James wrote:
> mail@horotw.com writes:
> > Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> > 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> > only arises if a lib is over 2MB).
> > I confirmed this for myself but only for the 64bit case.
> >
> > I saw that this issue is being tracked by ubuntu
> > (https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1983357).
> > If this is the wrong place and I should instead report it elsewhere I
> > am very sorry.
> 
> See also https://bugs.debian.org/1024149. Unfortunately, I don't
> think the issue found its way upstream until now (thanks).
> 
> CCing relevant maintainers (per the Debian bug).

You know, my email address is all over that commit and the doofus who
"discovered the vulnerability" didn't even have the courtesy to let
me know.  I've had several private emails about this over the last few
days and I just don't care.  Who's running 32-bit code and cares about
security?  32-bit kernels are known-vulnerable to all kinds of security
problems, and I think this is the least of your worries.

This was intended to happen, it's not a surprise.

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[mail]

Am 15.01.2024 17:52, schrieb Matthew Wilcox:
> On Mon, Jan 15, 2024 at 04:40:36PM +0000, Sam James wrote:
>> mail@horotw.com writes:
>> > Hey, I read that ASLR is currently (since kernel >=5.18) broken for
>> > 32bit libs and reduced in effectiveness for 64bit libs... (the issue
>> > only arises if a lib is over 2MB).
>> > I confirmed this for myself but only for the 64bit case.
>> >
>> > I saw that this issue is being tracked by ubuntu
>> > (https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1983357).
>> > If this is the wrong place and I should instead report it elsewhere I
>> > am very sorry.
>> 
>> See also https://bugs.debian.org/1024149. Unfortunately, I don't
>> think the issue found its way upstream until now (thanks).
>> 
>> CCing relevant maintainers (per the Debian bug).
> 
> You know, my email address is all over that commit and the doofus who
> "discovered the vulnerability" didn't even have the courtesy to let
> me know.  I've had several private emails about this over the last few
> days and I just don't care.  Who's running 32-bit code and cares about
> security?  32-bit kernels are known-vulnerable to all kinds of security
> problems, and I think this is the least of your worries.
> 
> This was intended to happen, it's not a surprise.

Hi,
first of all I am very sorry, I didn't realize I should have contacted 
you
first (I'm not the one who found the bug initially), I will do it
differently in the future.

Unfortunately, my knowledge is not sufficient to judge how bad it is 
that
32bit effectively has no ASLR support anymore.

64bit is also affected, even though there are probably more than enough
bits left there? I have since seen that both Arch and Ubuntu seem to 
have
"patches" in place 
(https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/3904bcb32cc58c10232fb618bf96c1b43b0bc9d7)
in which they set the `CONFIG_ARCH_MMAP_RND_BITS=32` and
`CONFIG_ARCH_MMAP_RND_COMPAT_BITS=16`, I'm not sure if this is a good
result or if it will cause other problems.

Again, I apologize if I caused any inconvenience.

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Matthew Wilcox]

On Mon, Jan 15, 2024 at 07:21:19PM +0100, mail@horotw.com wrote:
> Am 15.01.2024 17:52, schrieb Matthew Wilcox:
> > On Mon, Jan 15, 2024 at 04:40:36PM +0000, Sam James wrote:
> > > mail@horotw.com writes:
> > > > Hey, I read that ASLR is currently (since kernel >=5.18) broken for
> > > > 32bit libs and reduced in effectiveness for 64bit libs... (the issue
> > > > only arises if a lib is over 2MB).
> > > > I confirmed this for myself but only for the 64bit case.
> > > >
> > > > I saw that this issue is being tracked by ubuntu
> > > > (https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1983357).
> > > > If this is the wrong place and I should instead report it elsewhere I
> > > > am very sorry.
> > > 
> > > See also https://bugs.debian.org/1024149. Unfortunately, I don't
> > > think the issue found its way upstream until now (thanks).
> > > 
> > > CCing relevant maintainers (per the Debian bug).
> > 
> > You know, my email address is all over that commit and the doofus who
> > "discovered the vulnerability" didn't even have the courtesy to let
> > me know.  I've had several private emails about this over the last few
> > days and I just don't care.  Who's running 32-bit code and cares about
> > security?  32-bit kernels are known-vulnerable to all kinds of security
> > problems, and I think this is the least of your worries.
> > 
> > This was intended to happen, it's not a surprise.
> 
> Hi,
> first of all I am very sorry, I didn't realize I should have contacted you
> first (I'm not the one who found the bug initially), I will do it
> differently in the future.

I'm not annoyed *at you*.  I'm annoyed at the guy who first "discovered"
it.  I'm annoyed at the people who are running around with their hair
on fire.  I'm annoyed at all the people who *didn't* contact me.

> Unfortunately, my knowledge is not sufficient to judge how bad it is that
> 32bit effectively has no ASLR support anymore.
> 
> 64bit is also affected, even though there are probably more than enough
> bits left there? I have since seen that both Arch and Ubuntu seem to have
> "patches" in place (https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commit/3904bcb32cc58c10232fb618bf96c1b43b0bc9d7)
> in which they set the `CONFIG_ARCH_MMAP_RND_BITS=32` and
> `CONFIG_ARCH_MMAP_RND_COMPAT_BITS=16`, I'm not sure if this is a good
> result or if it will cause other problems.

Yeah, I don't know either.  Outside my scope of expertise.

I received a suggestion off-list that we only do the PMD alignment on
64-bit, which seems quite reasonable to me.  After all, I don't care
about performance on 32-bit just as much as I don't care about security
on 32-bit.

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Ard Biesheuvel]

(cc Kees, LAKML)

https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com

On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox <willy@infradead.org> wrote:
>
...
> Yeah, I don't know either.  Outside my scope of expertise.
>
> I received a suggestion off-list that we only do the PMD alignment on
> 64-bit, which seems quite reasonable to me.  After all, I don't care
> about performance on 32-bit just as much as I don't care about security
> on 32-bit.
>

For context, the culprit is

commit 1854bc6e2420472676c5c90d3d6b15f6cd640e40
Author: William Kucharski <william.kucharski@oracle.com>
Date:   Sun Sep 22 08:43:15 2019 -0400

    mm/readahead: Align file mappings for non-DAX

    When we have the opportunity to use PMDs to map a file, we want to follow
    the same rules as DAX.

    Signed-off-by: William Kucharski <william.kucharski@oracle.com>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

which affects *all* 32-bit architectures not just i686. 32-bit ARM
user space is still being deployed widely, even on arm64 Chromebooks
running 64-bit kernels (at least up until recently) so unfortunately,
we're not quite at the point yet where we can just let it rot.

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Kees Cook]

On Tue, Jan 16, 2024 at 09:09:45AM +0100, Ard Biesheuvel wrote:
> (cc Kees, LAKML)
> 
> https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com
> 
> On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox <willy@infradead.org> wrote:
> >
> ...
> > Yeah, I don't know either.  Outside my scope of expertise.
> >
> > I received a suggestion off-list that we only do the PMD alignment on
> > 64-bit, which seems quite reasonable to me.  After all, I don't care
> > about performance on 32-bit just as much as I don't care about security
> > on 32-bit.
> >
> 
> For context, the culprit is
> 
> commit 1854bc6e2420472676c5c90d3d6b15f6cd640e40
> Author: William Kucharski <william.kucharski@oracle.com>
> Date:   Sun Sep 22 08:43:15 2019 -0400
> 
>     mm/readahead: Align file mappings for non-DAX
> 
>     When we have the opportunity to use PMDs to map a file, we want to follow
>     the same rules as DAX.
> 
>     Signed-off-by: William Kucharski <william.kucharski@oracle.com>
>     Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> 
> which affects *all* 32-bit architectures not just i686. 32-bit ARM
> user space is still being deployed widely, even on arm64 Chromebooks
> running 64-bit kernels (at least up until recently) so unfortunately,
> we're not quite at the point yet where we can just let it rot.

Is this related at all to this thread as well?
https://lore.kernel.org/lkml/20220809142457.4751229f@imladris.surriel.com/

Can we avoid this on 32-bit or at least not mislead userspace about the
available entropy visible in /proc/sys/vm/mmap_rnd*_bits ?

-Kees

-- 
Kees Cook

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Yang Shi]

On Tue, Jan 23, 2024 at 2:37 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Tue, Jan 16, 2024 at 09:09:45AM +0100, Ard Biesheuvel wrote:
> > (cc Kees, LAKML)
> >
> > https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com
> >
> > On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > ...
> > > Yeah, I don't know either.  Outside my scope of expertise.
> > >
> > > I received a suggestion off-list that we only do the PMD alignment on
> > > 64-bit, which seems quite reasonable to me.  After all, I don't care
> > > about performance on 32-bit just as much as I don't care about security
> > > on 32-bit.
> > >
> >
> > For context, the culprit is
> >
> > commit 1854bc6e2420472676c5c90d3d6b15f6cd640e40
> > Author: William Kucharski <william.kucharski@oracle.com>
> > Date:   Sun Sep 22 08:43:15 2019 -0400
> >
> >     mm/readahead: Align file mappings for non-DAX
> >
> >     When we have the opportunity to use PMDs to map a file, we want to follow
> >     the same rules as DAX.
> >
> >     Signed-off-by: William Kucharski <william.kucharski@oracle.com>
> >     Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> >
> > which affects *all* 32-bit architectures not just i686. 32-bit ARM
> > user space is still being deployed widely, even on arm64 Chromebooks
> > running 64-bit kernels (at least up until recently) so unfortunately,
> > we're not quite at the point yet where we can just let it rot.
>
> Is this related at all to this thread as well?
> https://lore.kernel.org/lkml/20220809142457.4751229f@imladris.surriel.com/

Yes

>
> Can we avoid this on 32-bit or at least not mislead userspace about the
> available entropy visible in /proc/sys/vm/mmap_rnd*_bits ?

https://lore.kernel.org/linux-mm/20240118133504.2910955-1-shy828301@gmail.com/

This patch basically made thp_get_unmapped_area no-op on 32 bit.

>
> -Kees
>
> --
> Kees Cook
>

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Kees Cook]

On Tue, Jan 23, 2024 at 05:04:22PM -0800, Yang Shi wrote:
> On Tue, Jan 23, 2024 at 2:37 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Tue, Jan 16, 2024 at 09:09:45AM +0100, Ard Biesheuvel wrote:
> > > (cc Kees, LAKML)
> > >
> > > https://lkml.kernel.org/r/69fa6015256613ed10aee996e181ebd4%40horotw.com
> > >
> > > On Mon, 15 Jan 2024 at 21:46, Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > ...
> > > > Yeah, I don't know either.  Outside my scope of expertise.
> > > >
> > > > I received a suggestion off-list that we only do the PMD alignment on
> > > > 64-bit, which seems quite reasonable to me.  After all, I don't care
> > > > about performance on 32-bit just as much as I don't care about security
> > > > on 32-bit.
> > > >
> > >
> > > For context, the culprit is
> > >
> > > commit 1854bc6e2420472676c5c90d3d6b15f6cd640e40
> > > Author: William Kucharski <william.kucharski@oracle.com>
> > > Date:   Sun Sep 22 08:43:15 2019 -0400
> > >
> > >     mm/readahead: Align file mappings for non-DAX
> > >
> > >     When we have the opportunity to use PMDs to map a file, we want to follow
> > >     the same rules as DAX.
> > >
> > >     Signed-off-by: William Kucharski <william.kucharski@oracle.com>
> > >     Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > >
> > > which affects *all* 32-bit architectures not just i686. 32-bit ARM
> > > user space is still being deployed widely, even on arm64 Chromebooks
> > > running 64-bit kernels (at least up until recently) so unfortunately,
> > > we're not quite at the point yet where we can just let it rot.
> >
> > Is this related at all to this thread as well?
> > https://lore.kernel.org/lkml/20220809142457.4751229f@imladris.surriel.com/
> 
> Yes
> 
> >
> > Can we avoid this on 32-bit or at least not mislead userspace about the
> > available entropy visible in /proc/sys/vm/mmap_rnd*_bits ?
> 
> https://lore.kernel.org/linux-mm/20240118133504.2910955-1-shy828301@gmail.com/
> 
> This patch basically made thp_get_unmapped_area no-op on 32 bit.

Ah-ha! Okay, thanks very much. I missed this landing. :)

-- 
Kees Cook

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

[Florian Weimer]

* Matthew Wilcox:

> I received a suggestion off-list that we only do the PMD alignment on
> 64-bit, which seems quite reasonable to me.  After all, I don't care
> about performance on 32-bit just as much as I don't care about security
> on 32-bit.

Perhaps we can we repurpose MAP_DENYWRITE to disable this?

For shared objects as loaded by a dynamic linker, the alignment is
pointless in many cases even if the original mapping is quite a bit
larger than 2 MiB because the individual LOAD segments and their
protection settings are smaller than 2 MiB, so hugepages cannot be used
in the end after all.  The dynamic linker knows the LOAD segments, so it
can drop MAP_DENYWRITE if it determines that hugepages could be
beneficial.  (Current glibc sets MAP_DENYWRITE for historic reasons.)
On the other hand, I wouldn't object to more explicit control over mmap
pointer alignment, either, for anonymous mappings as well.

There are some binutils versions that produce 2 MiB aligned file layout
on x86-64, but that change was reverted, presumably because kernel
hugepage support for non-anonymous memory wasn't available.  But there
are likely some iffy details that make these binaries unusable for
hugepages in practice, like lack of hugepage alignment at the end of
LOAD segments.  Unfortunately, BFD ld tends to produce approximate
PT_LOAD and PT_GNU_RELRO and relies on the dynamic loader to round
things up and down in somewhat questionable ways.

Thanks,
Florian