security implications of NULL dereference

Question

Suppose we have code like this:

struct somedata {
   int a;
   int b;
};
struct somedata *data;
/* ... */
data = malloc(sizeof(struct somedata));
data->a = something;

Now, as you can see, NULL pointer check is missing. The question is - does this have security implications in case malloc fails? Let's assume the process exiting on SEGV by itself is not a problem in this case. Is there any other way this can be trouble from security standpoint? The application containing this code is not SUID or having any elevated privileges, but does process external input, so some parts of its memory can be user-controlled.

P.S. I am aware of CWE-476 but there the security implications are described in a very vague way ("In very rare circumstances and environments, code execution is possible" - which circumstances? which environments? How rare - meteor-hitting-you-in-the-head rare or once-a-year rare?) and I'd like to see some more specific info on what the threat is.

Answer 1

"The process exiting on SEGV by itself is not a problem in this case": this is already a large assumption. Whatever the process was doing will not be finished; the caller gets an error code; if the process had created temporary files then those files do not get erased. Making sure that there really is no problem is tricky.

Also, what creates the SEGV is the access to a memory area which the operating system has deliberately marked as invalid; namely, the first "page" of the address space (a page being 4096 bytes on a PC). Consider the following:

data = malloc(1000000 * sizeof(struct somedata));
data[800000].a = something;

If struct somedata has length 8 bytes, and the allocation fails, then the code will try to write something at address +6400000. Even if the OS did not map the first 4096 bytes, it is quite possible that the address 6400000 is valid and used for something else, which gets silently overwritten. At that point, anything goes. There again, knowing whether a given NULL returned by malloc() would imply immediate segfault or silent corruption can be difficult.

If the process has no special rights and the attacker already has the power to run executable files with the same privileges, then not checking the value returned by malloc() does not uncover new security issues. It is just sloppy.

Answer 2

In kernel code, this bug is a serious vulnerability. User code can request to remap the page starting at address 0, and that mapping will apply to kernel code as well. So, if this happens, the kernel is now reading from (or writing to) user-controlled memory instead of kernel-controlled memory, which might violate the integrity (or confidentiality) of the kernels' computation. For instance, if the kernel reads a pointer from this page and then dereferences it, very bad things can happen. Thus, this kind of bug can enable privilege escalation, enabling a malicious non-root user process to attack the kernel and do stuff it shouldn't be allowed to do.

In user-level application code, this bug is usually not a security problem, because there is no way an attacker can re-map page zero without the application's cooperation. (Exception: There are a few very applications that themselves deliberately remap the page starting at address 0. I'm thinking, for example, of Wine. I don't know if there are any security implications for those exceptional applications.)

Thanks to @this.josh for the link to an explanation of the vulnerability in kernel-level code.