Re: Should mprotect(..., PROT_EXEC) be checked by IMA?

From: Igor Zhbanov <i.zhbanov@omprussia.ru>
To: Matthew Garrett <mjg59@google.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Kees Cook <keescook@chromium.org>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Paul Moore <paul@paul-moore.com>,
	John Johansen <john.johansen@canonical.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	Jann Horn <jannh@google.com>,
	linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
Date: Thu, 4 Apr 2019 14:44:59 +0300	[thread overview]
Message-ID: <925634dc-7983-9da9-6d25-d9e0e052e4b7@omprussia.ru> (raw)
In-Reply-To: <CACdnJutN3415jtt+kaz-zxyAw0V9-0x0_YGWpxBXWYseD5Z7uA@mail.gmail.com>

On 03.04.2019 22:25, Matthew Garrett wrote:
> On Wed, Apr 3, 2019 at 11:47 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> On 03.04.2019 21:19, Matthew Garrett wrote:
>>> There's two possible cases here:
>>>
>>> 1) The application is legitimate but can be convinced to open and
>>> execute malicious code. There should be no such applications that
>>> download code from the internet and execute it directly, so this can
>>> be prevented by requiring that files be signed (which has to be done
>>> to protect against attackers just using an interpreted language
>>> instead)
>>> 2) The application is actively malicious. In this case this approach
>>> is insufficient - an actively malicious application can interpret code
>>> rather than executing it directly. This can only be prevented by not
>>> signing malicious applications.
>>>
>>> When you talk about "staying below the radar" it implies that you're
>>> talking about case 2, but the proposed solution is only a speed bump
>>> rather than a blocker.
>>
>> But what about buffer/stack overflow? The application doesn't need to be
>> malicious. It could be just a web-browser or e-mail client processing
>> some evil file.
> 
> Executable pages shouldn't be writable?

Shouldn't. But I think about following:

1) Small ROP part downloads bigger portion of code to RW page.
2) Then it switches it to RX page with mprotect.

And this bigger downloaded code could try to steal data or to probe for
another holes. I believe that it's very hard to implement big ROP exploit.
It's easier to implement it in parts: smaller one takes control and downloads
the bigger one.