[Fiware-defcamp-challenge] Ionut Ambrosie - my quick findings

[Ionut Ambrosie]

Hi guys,

Given the time frame, I have decided to focus on finding vulnerabilities in
the source code pointed to in the received document, namely the source code
available in the following repository:
https://github.com/telefonicaid/fiware-orion

I will now describe my main finding.

After glancing over the source code, I have identified a systematic
_misuse_ of the strncat function.

According to http://en.cppreference.com/w/cpp/string/byte/strncat, strncat
has the following declaration:

char *strncat( char *dest, const char *src, std::size_t count );

where the count parameter is not the size of the dest buffer, but rather
the size of its remaining part (also, the terminator character is counted
implicitly).

As a short example, consider the following code:

iambrosie at xxx:~/Documents/Fiware/Test$ cat strncat.cc
#include <cstring>
#include <cstdio>

int main()
{
    char paResultString[10] = "BBBBBBBB";
    char s[150] =
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
    std::printf("[*BEFORE STRNCAT*]\nstring s: %s\npaResultString: %s with
length %lu\n", s, paResultString, strlen(paResultString));
    std::strncat(paResultString, s, sizeof(paResultString) - 1);
    std::printf("[*AFTER STRNCAT*]\ns: %s\npaResultString: %s with length:
%lu\n", s, paResultString, strlen(paResultString));
}

which, after compilation with the following command:

iambrosie at xxx:~/Documents/Fiware/Test$ clang -O1 -g strncat.cc -o strncat

results in the following output:

iambrosie at xxx:~/Documents/Fiware/Test$ ./strncat
[*BEFORE STRNCAT*]
string s:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
paResultString: BBBBBBBB with length 8
[*AFTER STRNCAT*]
s:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
paResultString: BBBBBBBBAAAAAAAAA with length: 17

Clearly, the paResultString, which in this case acts as the dest buffer in
the strncat declaration, has been overflowed. Thus, we're talking about a
buffer overflow vulnerability.

Now, in the source code from the repository whose analysis we were tasked
with, I have identified _21_ instances of this usage pattern which I am
going to list here:

   1. lib/logMsg/logMsg.cpp, line 2476
   2. lib/logMsg/logMsg.cpp, line 495
   3. lib/parseArgs/paUsage.cpp, line 265
   4. lib/logMsg/logMsg.cpp, line 2508
   5. lib/logMsg/logMsg.cpp, line 2522
   6. lib/logMsg/logMsg.cpp, line 2498
   7. lib/parseArgs/paUsage.cpp, line 327
   8. lib/parseArgs/paParse.cpp, line 393
   9. lib/logMsg/logMsg.cpp, line 2491
   10. lib/parseArgs/paParse.cpp, line 616
   11. lib/parseArgs/paParse.cpp, line 398
   12. lib/logMsg/logMsg.cpp, line 493
   13. lib/parseArgs/paUsage.cpp, line 542
   14. lib/logMsg/logMsg.cpp, line 500
   15. lib/parseArgs/paParse.cpp, line 391
   16. lib/parseArgs/paUsage.cpp, line 293
   17. lib/parseArgs/paUsage.cpp, line 548
   18. lib/parseArgs/paParse.cpp, line 619
   19. lib/logMsg/logMsg.cpp, line 2483
   20. lib/parseArgs/paParse.cpp, line 611
   21. lib/logMsg/logMsg.cpp, line 2514

In case you're wondering whether you should you care about this, you should
know that stack-base buffer overflows (as is the case here) are a memory
safety violation that lead to crashes and can often can be used to execute
arbitrary code. When the consequence is arbitrary code execution, this can
(sometimes) be used as a means for privilege escalation. Thus, sometimes,
stack-based buffer overflows can be used to subvert any other security
service of a system.

Potential Mitigations which might already be in place are compiler-based
canary mechanisms such as StackGuard, ProPolice. Also, running the
application with as low privilege as possible is always a good idea.

As recommendation for eliminating this vulnerability from the source code,
I suggest you replace  'sizeof(dest) - 1' with 'sizeof(dest) - strlen(dest)
- 1' or, if possible, replace strncat with 'strlcat'.

Anyway, if you're interested in details about stack-based buffer overflows,
https://cwe.mitre.org/data/definitions/121.html is a good place to start.

Cheers,
Ionut Ambrosie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-defcamp-challenge/attachments/20151120/02a3b5e1/attachment.html>