On 03.04.2019 22:25, Matthew Garrett wrote:
On Wed, Apr 3, 2019 at 11:47 AM Igor Zhbanov <i.zhbanov@xxxxxxxxxxxx> 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.
