Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 Nov 2016 11:00:20 -0400
From: Dave Tian <dave.jing.tian@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: Legitimate use of /proc/PID/mem,maps and smaps

> On Nov 1, 2016, at 11:42 PM, Marian Marinov <mm-l@...u.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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.