[kernel-hardening] Legitimate use of /proc/PID/mem,maps and smaps

[kernel-hardening] Legitimate use of /proc/PID/mem,maps and smaps

[Marian Marinov]

Hi guys,
after dirtyCoW me and colleges of mine started discussing different vectors of exploiting applications and we noticed that a lot of the exploits we were discussing relied on /proc/PID/mem or mpas or smaps to be readable by the same user.

We started thinking of legitimate use of these files (lsof, gdb with plugins and valgrind). Are there any other legitimate users of these files, maybe X?

I'm considering writing a patch, which will make sure that nobody, even the owner of the process, can't open these files and only root or users with CAP_DAC_OVERRIDE and/or CAP_SYS_ADMIN can see these files.
For everyone that is not root and lacks DAC_OVERRIDE and SYS_ADMIN the files should not exists.

What do you think about this?

Best regards,
Marian

Re: [kernel-hardening] Legitimate use of /proc/PID/mem,maps and smaps

[Dave Tian]

> On Nov 1, 2016, at 11:42 PM, Marian Marinov <mm-l@yuhu.biz> wrote:
> 
> Hi guys,
> after dirtyCoW me and colleges of mine started discussing different vectors of exploiting applications and we noticed that a lot of the exploits we were discussing relied on /proc/PID/mem or mpas or smaps to be readable by the same user.
> 
> We started thinking of legitimate use of these files (lsof, gdb with plugins and valgrind). Are there any other legitimate users of these files, maybe X?
> 
> I'm considering writing a patch, which will make sure that nobody, even the owner of the process, can't open these files and only root or users with CAP_DAC_OVERRIDE and/or CAP_SYS_ADMIN can see these files.
> For everyone that is not root and lacks DAC_OVERRIDE and SYS_ADMIN the files should not exists.
> 
> What do you think about this?
> 
> Best regards,
> Marian

I do not see a problem of a process looking into its own address space. The root cause of dirtycow is not the permission of accessing /proc/self/mem, which only provides a trigger, same as ptrace(), but the race condition between the cowed page and unmmap, although I do agree if there is a better/reasonable way to limit the attack surface, just like limiting perf, without breaking user-space tools.

-daveti

Re: [kernel-hardening] Legitimate use of /proc/PID/mem,maps and smaps

[Adam Sampson]

Marian Marinov <mm-l@yuhu.biz> writes:

> Are there any other legitimate users of these files, maybe X?

This is the kind of question that Debian Code Search is useful for
(although it's not exhaustive):
https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fmem&perpkg=1
https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fmaps&perpkg=1
https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fsmaps&perpkg=1

>From my bug-hunting experience, programs use /proc/self/maps for all
sorts of weird things -- e.g. working out the full path of the
executable, or what version of a shared library they've been linked
against, or guessing whether some random value is a valid pointer. Many
have embedded copies of code from gettext or BinReloc that uses it.

On the other hand, many of these don't actually need all the information
in /proc/self/maps, so you could get away with a simplified version that
only had valid filenames.

-- 
Adam Sampson <ats@offog.org>                         <http://offog.org/>

Re: [kernel-hardening] Legitimate use of /proc/PID/mem,maps and smaps

[Marian Marinov]

On 11/02/2016 06:10 PM, Adam Sampson wrote:
> Marian Marinov <mm-l@yuhu.biz> writes:
>
>> Are there any other legitimate users of these files, maybe X?
> This is the kind of question that Debian Code Search is useful for
> (although it's not exhaustive):
> https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fmem&perpkg=1
> https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fmaps&perpkg=1
> https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fsmaps&perpkg=1
>
> >From my bug-hunting experience, programs use /proc/self/maps for all
> sorts of weird things -- e.g. working out the full path of the
> executable, or what version of a shared library they've been linked
> against, or guessing whether some random value is a valid pointer. Many
> have embedded copies of code from gettext or BinReloc that uses it.
>
> On the other hand, many of these don't actually need all the information
> in /proc/self/maps, so you could get away with a simplified version that
> only had valid filenames.
>
Hmm I probably did not explained what I want. I know I can not (easily)limit a program to access its own memory(that would be stupid).

Pretend that user joe is running top and his top has pid of 1154. Now joe runs a php script and that script wants to open /proc/1154/maps and so on.

I believe that the kernel should not allow the php process(even thou it is from the same user to read those files, that are private to the top application). Actually I would like to make them invisible for all processes and users except the program 
that is the actual owner of the files and privileges users.

Does that seam logical to you guys?


Marian

Re: [kernel-hardening] Legitimate use of /proc/PID/mem,maps and smaps

[Dave Tian]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Nov 2, 2016, at 8:54 PM, Marian Marinov <mm-l@yuhu.biz> wrote:
> 
> On 11/02/2016 06:10 PM, Adam Sampson wrote:
>> Marian Marinov <mm-l@yuhu.biz> writes:
>> 
>>> Are there any other legitimate users of these files, maybe X?
>> This is the kind of question that Debian Code Search is useful for
>> (although it's not exhaustive):
>> https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fmem&perpkg=1
>> https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fmaps&perpkg=1
>> https://codesearch.debian.net/search?q=%2Fproc%2Fself%2Fsmaps&perpkg=1
>> 
>> >From my bug-hunting experience, programs use /proc/self/maps for all
>> sorts of weird things -- e.g. working out the full path of the
>> executable, or what version of a shared library they've been linked
>> against, or guessing whether some random value is a valid pointer. Many
>> have embedded copies of code from gettext or BinReloc that uses it.
>> 
>> On the other hand, many of these don't actually need all the information
>> in /proc/self/maps, so you could get away with a simplified version that
>> only had valid filenames.
>> 
> Hmm I probably did not explained what I want. I know I can not (easily)limit a program to access its own memory(that would be stupid).
> 
> Pretend that user joe is running top and his top has pid of 1154. Now joe runs a php script and that script wants to open /proc/1154/maps and so on.
> 
> I believe that the kernel should not allow the php process(even thou it is from the same user to read those files, that are private to the top application). Actually I would like to make them invisible for all processes and users except the program that is the actual owner of the files and privileges users.
> 
> Does that seam logical to you guys?
> 
> 
> Marian


Sounds reasonable. However, this still does not solve the dirty cow case where a thread is able to access its own mem to access whatever shared by the main thread.

-daveti


[-- Attachment #2: Type: text/html, Size: 8472 bytes --]