Date: Sun, 4 May 2003 14:19:09 +0300 (IDT)
From: Yoav Weiss <ml-lkml@unpatched.org>
To: mingo@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Announcement] "Exec Shield", new Linux security feature
Message-ID: <Pine.LNX.4.44.0305041337590.31429-100000@marcellos.corky.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1347
Lines: 34

On Fri, 2 May 2003, Ingo Molnar wrote:

> Furthermore, the kernel also remaps all PROT_EXEC mappings to the
> so-called ASCII-armor area, which on x86 is the addresses 0-16MB.

I don't see how the case of mprotect(HIGH_ADDRESS, LEN, PROT_EXEC) be
handled.  Unlike mremap, mprotect doesn't offer a way to inform the user
about a change of address.

If I understand correctly, such case will cause a call to
arch_add_exec_range(current->mm, vma) without any remapping, thus breaking
the protection.

One case where this would happen is some of the ancient loaders.  IIRC,
libc4's loader did just that.  (right, nobody uses it anymore :)

btw, I guess that now, at least when X_workaround==1, exploits will focus
on getting iopl(2) called before they get the actual shellcode called.
In some cases it may be easy to cause a call to iopl (param doesn't matter
as long as its not zero).  Once this is achieved, protection is disabled.

For that reason, maybe X_workaround should be controlled per-executable
by another ELF flag and not as a system-wide property.

	Yoav Weiss

--
Please CC me on any reply.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/