Format Strings: Is Objective-C Objectively Safer?

[Nytro]

[h=1]Format Strings: Is Objective-C Objectively Safer?[/h]HP_SSR| August 9, 2012 - last edited August 15, 2012

With the explosion of mobile devices came mobile applications, and with the mobile applications came a plethora of new security and privacy concerns. If you've been following this blog or our products, you probably know that we just released our first Objective-C rulepacks, with a lot more support planned in the future. To kick things off, let's talk about one of the vulnerabilities that our Objective-C rulepacks can detect: format string flaws.

A common misconception is that Objective-C is a newer language compared to C and C++, and is therefore immune to many of the classic C vulnerabilities such as buffer overflows. In the C and C++ world, one cousin of the well-known buffer overflow exploit is format string attacks. Since Objective-C also supports format strings, does that mean that its applications are vulnerable as well? Let's first review how C/C++-style format string attacks work, then compare these to what Objective-C lets us do.

A string format function, such as printf(), takes in a format string and a variable list of arguments. Normally (with the exception of the %n specifier—more on that later), the format specifiers in the string is replaced with the values of the respective arguments. What happens if there are more specifiers than there are arguments?

For example,

   printf("%d%d%d%d%d\n", val);

C and C++ will gladly continue to pop values off the stack until it fills in every value for every format specifier. What if an attacker is able to control the format string? At best, the program will crash or function incorrectly due to the damaged call stack. At worst, it can reveal sensitive information stored in local variables or passed as arguments to functions.

The story gets worse. C and C++ support the %n specifier, which writes a value—namely, the number of bytes written thus far—back to the corresponding variable. By controlling the number of bytes written and storing the value of %n, we can write any value back to the stack, including the address of any attacker-controlled malicious code. (To avoid having to write millions of characters just to form a 32-bit address, we can instead write %n four times, a single byte at a time.) If we can also manipulate the stack to fool the program into treating the value as the return pointer, then we can force the program to run our malicious code—not unlike a buffer overflow exploit.

So how much of this applies to Objective-C? The good news is that format string methods introduced by Objective-C do not allow the %n specifier, so there are no known ways to execute arbitrary code using format strings. The bad news is that Objective-C attempts to be backwards-compatible with C/C++ libraries, continuing to allow the old %n-style code execution exploits.

Nonetheless, even for the newer Objective-C-specific format string methods, using excess format specifiers to pop values off the stack still works:

   void myfunc(NSString *in) {
       NSLog(in);
       NSLog(@"Inside myfunc");
   }

   int main(int argc, char *argv[])
   {
       NSString *test = @"%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x\n%08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x\n";
       myfunc(test);
       return NSApplicationMain(argc,  (const char **) argv);
   }

The output is as follows:

   (gdb)
   2012-02-13 22:12:12.525 objc[12983:a0f] 5fbff860.5fbff870.5fbff928.00000012.00000000.00000000.00002070.5fbff840
   000017e8.5fbff860.00000000.5fbff848.00002070.5fbff850.00001784.00000000
   (gdb) info args
   in = (NSString *) 0x100002070
   (gdb)

Note the address of the string test, 00002070, gets printed twice in the output, presumably because it is passed twice as an argument—once to myfunc, and again to NSLog. I should also note that in constructing the above test code, the program has also crashed several times with an EXC_BAD_ACCESS signal, further suggesting that the format string is corrupting the stack pointer.

I hope the above evidence is convincing enough to show that Objective-C does not perform any safety checks on format strings, letting them manipulate the call stack easily. The next reasonable question, how exactly can this be exploited? What might vulnerable code in an application look like? Consider the following code snippet:

    - (BOOL)application:(UIApplication *)application
            openURL:(NSURL *)url
            sourceApplication:(NSString *)sourceApplication
            annotation:(id)annotation {
        // Write to debugging log
        NSLog(@"++ Entered application");

        NSString *urlquery = [url query];
        NSLog(urlquery);
        ...
    }

This is one of the most common mistakes when using NSLog, which in turn can lead to a format string vulnerability. According to the official documentation, NSLog()'s first parameter is not a simple string, but in fact a format string. A rogue (or compromised) process might take advantage of this vulnerability by launching the app via its registered URL scheme and supply a URL with extraneous format specifiers. When the program reaches the line NSLog(urlquery), the NSLog() method now expects the values to fill in for these specifiers. It does this by gladly reaching backwards into the call stack, which corrupts the state of the stack. This causes the rest of the program to run incorrectly or eventually crash.

So in short, while Objective-C format strings manage to avoid some of the more heinous exploits that allow for arbitrary code execution, they are still vulnerable to stack manipulation. Attackers can still crash your program at best, and dump sensitive data at worst. Avoid using legacy C/C++ format string methods if possible; these are still vulnerable to the code execution exploits of old. In general, be careful when working with format strings; always make sure there are equal numbers of format specifiers and arguments. More importantly, do not let sources outside of your control, such as data and messages from other applications or web services, control any part of your format strings.

Posted by sarah at 12:00 PM

Sursa: HP Communities - Format Strings: Is Objective-C Objectively Safer? - Enterprise Business Community