linux-hardening - Re: [PATCH v10 0/5] Introduce mseal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 14 May 2024 17:47:30 -0600
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Matthew Wilcox <willy@...radead.org>,
    Jonathan Corbet <corbet@....net>, jeffxu@...omium.org,
    keescook@...omium.org, jannh@...gle.com, sroettger@...gle.com,
    gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
    usama.anjum@...labora.com, Liam.Howlett@...cle.com,
    surenb@...gle.com, merimus@...gle.com, rdunlap@...radead.org,
    jeffxu@...gle.com, jorgelo@...omium.org, groeck@...omium.org,
    linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
    linux-mm@...ck.org, pedro.falcato@...il.com, dave.hansen@...el.com,
    linux-hardening@...r.kernel.org
Subject: Re: [PATCH v10 0/5] Introduce mseal

Andrew Morton <akpm@...ux-foundation.org> wrote:

> > I worry that the non-atomicity will one day be used by an attacker.
> 
> How might an attacker exploit this?

Various ways which are going to be very application specific. Most ways
will depend on munmap / mprotect arguments being incorrect for some
reason, and callers not checking the return values.

After the system call, the memory is in a very surprising configuration.

Consider a larger memory region containing the following sections:

  [regular memory]  [sealed memory]  [regular memory containing a secret]

unmap() gets called on the whole region, for some reason.  The first
section is removed.  It hits the sealed memory, and returns EPERM.  It does
not unmap the sealed reason, not the memory containing the secret.

The return values of mprotect and munmap are *very rarely* checked,
which adds additional intrigue. They are not checked because these
system calls never failed in this way on systems before Linux.

It is difficult to write test programs which fail under the current ENOMEM
situation (the only current failure mode, AFAIK).  But with the new mseal()
EPERM condition, it will be very easy to write programs which leave memory
behind.

I don't know how you'll document this trap in the manual page, let me try.

    If msealed memory is found inside the range [start, start+len], 
    earlier memory will be unmapped, but later memory will remain unmapped
    and the system call returns error EPERM.

    If kernel memory shortage occurs while unmapping the region, early
    regions may be unmapped but higher regions may remain mapped, and
    the system call may return ENOMEM.

I feel so gross now, time for a shower..