[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