Software flaw #6: Solution

Vulnerability

Flaw covered this week is classical example of format string vulnerability.

Problem is that the whole format string provided to printf function is user controlled, so one has total control over it: he can make it look like this: %s%s%s%s or this %s%s%s%s%s%s%s%s%s%s%s%s%n. That's not good.

Exploitation

Formt string vulnerability is quite severe and could lead to overwriting arbitrary memory address with user controlled value - which ultimately leads to taking over process's execution flow typically by overwriting .dotrs section or overwriting entry in GOT table.

Exploitation of these kind of problems take advantage of %n format specifier in printf function (and it's derivatives). More detalis can be found here.

The only not so obvious (at least at first spot) part in this week's vulnerable piece of code is this line:

if(argc) exit(0);

Basically it prevents us from providing input data via command line arguments. Therefore it seems that we can't take advantage of format string flaw from next line:

printf(argv[3]);

To overcome this inconvenience one has to realize that in absence of command line arguments program's execution parameters will look like this:

argv[0]env[0]env[1]env[2]env[3]...env[n]
                     ^
                     |
                  argv[3]

so argv[3] will point to env[2] environment variable which can be used as source of input data.

Mitigation

The obvious fix is to replace this line:

printf(argv[3]);

with the following:

printf("%s", argv[3]);

This way format string won't be controlled by the user and therefore code won't be vulnerable anymore.

To partially harden your Linux platform against these type of attacks one can compile program with -Wl,-z,relro flags which will prevent from overwritng GOT table entries (which is commonly used in exploiting this type of flaws as mentionted in Exploitation section). Additionally compiling with _FORTIFY_SOURCE=2 flag will warn about misuses of function which use format strings.

Software flaw #6

Vulnerable C code from one of overthewire.org levels:

#include <stdlib.h>

int main(int argc, char **argv)
{
    if(argc) exit(0);
    printf(argv[3]);
    exit(EXIT_FAILURE);
}

Vulnerability

What type of vulnerability is this? Why this code is vulnerable?

Exploitation

How one could exploit this code? What could be achieved by the exploit?

Mitigation

How to fix this vulnerability? What countermeasure(s) could be put in place in order to make exploitation harder (or impossible)?

Solution will be published on 28.09.2014.

Software flaw #5: NUL byte off-by-one overwrite into the heap

CVE-2014-5119 vulnerability was reported in glibc by Tavis Ormandy member of Google's Zero Project.

Vulnerability

Vulnerable code lies in glibc's internal function __gconv_translit_find, here's vulnerable part (from glibc's bugzilla):

[...]
cp = __mempcpy (__stpcpy ((char *) newp->fname, runp->name),
                  trans->name, name_len);
if (need_so)
    memcpy (cp, ".so", sizeof (".so"));
[...]

cp points after the NUL terminator, so the memcpy call does not actually append ".so", but copies four bytes starting after the terminating NUL character, not changing the string at all - and writing a single NUL byte after the end of the buffer.

Exploitation

Zero Project Team released PoC exploit for this innocent looking flaw.

pkexec binary is chosen as a target of this PoC. Main idea behind it is to take advantage of so called backward consolidation of a heap but since the size of chunk is fixed and always the same (".so" as 32bit pointer is equal to 0x6f732e00), so also memory leak found in pkexec had to be used to spray the heap.

Monthly threat update #15: August

• This month we have learnt about two interesting NSA/GCHQ capabilities: ORBs (Operational Relay Boxes) harvesting by 5-eyes and GCHQ catalog of exploit tools which sheds some light on GCHQ cyber capabilities.

• Verizon RISK Team blogged about particulary interesting defense concept.