[llvm-bugs] [Bug 26639] New: ControlFlowIntegrity: ban address-taken mmap, mprotect, etc
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Feb 16 11:19:16 PST 2016
https://llvm.org/bugs/show_bug.cgi?id=26639
Bug ID: 26639
Summary: ControlFlowIntegrity: ban address-taken mmap,
mprotect, etc
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: peter at pcc.me.uk
Reporter: kcc at google.com
CC: eugeni.stepanov at gmail.com, kcc at google.com,
llvm-bugs at lists.llvm.org
Classification: Unclassified
In most cases ControlFlowIntegrity will protect from indirectly
calling mmap/mprotect when it is undesired, however if mmap/mprotect is
address-taken
in the application, the protection becomes weaker.
Consider this code:
int (*F)(void *, size_t, int);
...
int some_user_function(void *, size_t, int);
...
F f = &some_user_function;
...
f();
...
// unrelated code
... = &mprotect;
Here, some_user_function and mprotect will be in the same function signature
bucket for CFI and thus the call to f() will allow mprotect.
For stronger security we probably want to disallow indirect calls to scary
functions like mprotect completely.
The simplest way is to implement yet another blacklist: any function in
it will cause a compiler warning/error if address-taken.
We can also introduce a function attribute that leads to a warning
if the function is address-taken.
(This is a no-rush feature request)
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160216/88a0c293/attachment.html>
More information about the llvm-bugs
mailing list