Did CVE-2016-2324 allowed remote code execution?

Question

Let’s say I have this kind of code :

// In revision.c
char *path_name(const struct name_path *path, const char *name) // by design, name_path->len is a 32 bits int, but this doesn’t concern name
{
      const struct name_path *p;
      char *n, *m;
      int nlen = strlen(name); // the size is converted to a positive number (the correct size was allocated previously with an unsigned long). I got 705804100
      int len = nlen + 1;

      for (p = path; p; p = p->up) { //loop is skipped (except in another case fixed since 2.7.1)
          if (p->elem_len)
              len += p->elem_len + 1;
      }
      n = xmalloc(len); // if len is negative, it will also be converted to a negative 64 bits integer *(which explains it is normally trying to allocate serveral Pb of ram most of the time)* which will be read as positive after that. // but this isn’t the run case that is interesting here.
      m = n + len - (nlen + 1); // the size of m is lower than name
      strcpy(m, name); // strcpy rely on the null terminating character. The result is written in an unallocated memory from heap. This is the definition of heap overflow enabling server side remote code execution if name[] contains assembly, and have the correct size. This open the way to defeat canaries aslr, and nx combined see http://security.stackexchange.com/q/20497/36301#comment182004_20550
      for (p = path; p; p = p->up) {
          if (p->elem_len) {
              m -= p->elem_len + 1;
              memcpy(m, p->elem, p->elem_len);
              m[p->elem_len] = '/';
          }
      }
      return n;
}

Could there be a case where the system let the overflow happen while keeping the path to remote code execution completely closed ?

A crafted path in a git database (a git tree) should contains binary code for performing the remote code execution. However, a path can’t contains thenulbyte (since it’s used as a delimiter in a git tree).

If a specific case is needed, it’s Ubuntu with linux version <3.16 and all security protections enabled (I mean nx aslr and dep combined but canaries excepted). The architecture is x86_64. libc is an old (but security patched) version of glibc.

Update :

Now, creating a proof should be easier.

Answer 1

A buffer overflow (of the "write" kind) gives any advantage to an attacker only if the attacker can arrange for the overflow to spill over other bytes that are used for something else. At any time, the process runs in an address space, most of which being unallocated. If the buffer which is overflown is at the end of the address space, or is followed only by unused bytes then an unmapped page, then the overflow won't help the attacker.

I remember a case with the rlogin command-line tool on SunOS 4.1.4 (sparc systems). It was root suid, and you could get it to segfault if the TERM environment variable contained a string longer than 64 characters. However, the overflown buffer was at the very end of the data section, and there was nothing beyond that to overwrite.

Mind, though, that malloc() may use extra bytes before and after each allocated block to keep track of which blocks are allocated. Depending on the implementation of malloc(), modifying these bytes may or may not help the attacker. The bottom-line is that while some buffer overflows cannot be exploited, it is usually very hard to make sure that a buffer overflow cannot be exploited. It is safer to assume that any buffer overflow can lead to drastic consequences, and not allow them to happen at all.

Answer 2

Not all buffer overflows lead to remote code execution. It depends on how the buffer is allocated, and if the instruction pointer can be controlled by the attacker. There are many factors that go into whether or not remote code execution is a possibility.

Answer 3

Ubuntu uses data execution protection. This stops code being executed from memory in the data portion of the process. This will effectively make code injected via a buffer overflow impossible to be executed. So the overflow can occur though execution cannot. Techniques such as ROP are used to work around DEP.