linux-kernel - Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

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]

Message-Id: <01A133F4-27DF-4AE2-80D6-B0368BF758CD@gmail.com>
Date:   Mon, 26 Mar 2018 22:45:31 +0300
From:   Ilya Smith <blackzert@...il.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Matthew Wilcox <willy@...radead.org>, rth@...ddle.net,
        ink@...assic.park.msu.ru, mattst88@...il.com, vgupta@...opsys.com,
        linux@...linux.org.uk, tony.luck@...el.com, fenghua.yu@...el.com,
        ralf@...ux-mips.org, jejb@...isc-linux.org,
        Helge Deller <deller@....de>, benh@...nel.crashing.org,
        paulus@...ba.org, mpe@...erman.id.au, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, ysato@...rs.sourceforge.jp,
        dalias@...c.org, davem@...emloft.net, tglx@...utronix.de,
        mingo@...hat.com, hpa@...or.com, x86@...nel.org,
        nyc@...omorphy.com, viro@...iv.linux.org.uk, arnd@...db.de,
        gregkh@...uxfoundation.org, deepa.kernel@...il.com,
        Hugh Dickins <hughd@...gle.com>, kstewart@...uxfoundation.org,
        pombredanne@...b.com, Andrew Morton <akpm@...ux-foundation.org>,
        steve.capper@....com, punit.agrawal@....com,
        aneesh.kumar@...ux.vnet.ibm.com, npiggin@...il.com,
        Kees Cook <keescook@...omium.org>, bhsharma@...hat.com,
        riel@...hat.com, nitin.m.gupta@...cle.com,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Jan Kara <jack@...e.cz>, ross.zwisler@...ux.intel.com,
        Jerome Glisse <jglisse@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Oleg Nesterov <oleg@...hat.com>, linux-alpha@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        linux-snps-arc@...ts.infradead.org, linux-ia64@...r.kernel.org,
        linux-metag@...r.kernel.org, linux-mips@...ux-mips.org,
        linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
        sparclinux@...r.kernel.org, Linux-MM <linux-mm@...ck.org>
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.


> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@...nel.org> wrote:
> 
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>> 
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@...radead.org> wrote:
>>> 
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>> 
>>> Why should this be done in the kernel rather than libc?  libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible IMO;
> 
> Is this really so helpful?

Yes, ASLR is one of very important mitigation techniques which are really used 
to protect applications. If there is no ASLR, it is very easy to exploit 
vulnerable application and compromise the system. We can’t just fix all the 
vulnerabilities right now, thats why we have mitigations - techniques which are 
makes exploitation more hard or impossible in some cases.

Thats why it is helpful.

> 
>> 2. User mode is not that layer which should be responsible for choosing
>> random address or handling entropy;
> 
> Why?

Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn’t be 
exposed to attacker anyhow, the best case is to get it from kernel. So this is
a syscall.
2. You should have memory map of your process to prevent remapping or big
fragmentation. Kernel already has this map. You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map.
This one also decrease performance cause you any way call syscall_mmap 
which will try to find some address for you in worst case, but after you already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.

> 
>> 3. Memory fragmentation is unpredictable in this case
>> 
>> Off course user mode could use random ‘hint’ address, but kernel may
>> discard this address if it is occupied for example and allocate just before
>> closest vma. So this solution doesn’t give that much security like 
>> randomization address inside kernel.
> 
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
> 

This algorithm should track current memory. If he doesn’t he may cause
infinite loop while trying to choose memory. And each iteration increase time
needed on allocation new memory, what is not preferred by any libc library
developer.

Thats why I did this patch.

Thanks,
Ilya