4

I'm doing a study on Memory Corruption. I need to compile a list of all the exploitable memory corruption issues that have been recognized till date and provide a sample vulnerable code for it.

I need help from the community. I tried searching but was unable to find any such list.

Things that I have compiled

  1. Stack Overflow
  2. Heap Overflow
  3. Off by One Byte
  4. Uninitialized variable memory bug exploitation
  5. Signed/Unsigned bugs
  6. User after free
  7. Double Free
  8. ?????

Please correct me if the list is wrong. I need a list of all the exploitable bugs in software written in C/C++.

Thanks.

john4tech
  • 151
  • 3
  • updating an object simultaneously from multiple threads without proper synchronization can also result in memory corruption. –  May 23 '14 at 11:49
  • using a variable after it went out of scope ( like when returning a pointer to a local variable –  May 23 '14 at 11:51
  • "updating an object simultaneously from multiple threads without proper synchronization can also result in memory corruption" Race condition? –  May 23 '14 at 12:06
  • Format string bugs might affect memory as well. But, it might be seen as a side effect. – perror May 23 '14 at 12:27
  • There's also NULL dereference. – toasted_flakes May 27 '14 at 08:10
  • If you’re differentiating stack overflow from heap overflow, you should probably also include overflow within the .bss section, relevant to ELF files. This is where static variables live – adam Jun 04 '22 at 18:23

3 Answers3

3

You might want to check the CWE (Common Weakness Enumeration) catalog for this type of research: http://cwe.mitre.org/index.html

The closest entry is probably CWE-633: CWE-633: Weaknesses that Affect Memory

I really like the CWE when it comes to categorize bugs (also check the "Relationships" for each entry). Each entry comes with an explanation and possible CVEs.

The CAPEC might also be interesting: (capec.mitre.org/index.html)

Note that integer coercion (CWE-192) or integer overflow (CWE-190) might just lead to bad calculation but not necessarily to a memory problem (see CWE-680).

Neitsa
  • 131
  • 3
1

Race conditions, NULL pointer dereferences, format string vulnerabilities, integer overflows but there are a near infinite number of possible vulnerabilities, these are all just categories. For example, binary parsers often trust memory offsets within files to go to: what category would you put that in? It's not really a buffer overflow, but it is a memory corruption bug.

And if you're going to list all the locations that a buffer can exist you might be there for a while (you're just listing memory regions), but .bss buffer overflows is another one.

Also the proper name for 4) is "use before initialization".

offbyseveral
  • 11
  • 1
  • Type-confusion is one more. Depending on the vulnerability, type confusions may be more of an exploitation method/primitive than a vulnerability, but there are some cases where the primary vulnerability is type confusion; MS11-093 comes to mind. They’re also more common in type-safe/memory-safe languages (Flash, Java, C#) but they do happen in C++ as well. One could probably also call this a “logic bug” but I think it deserves its own mention – adam Jun 04 '22 at 18:37
0

The subject is quite large. This article can help, it covers some interesting aspects. You should also check Valgrind and its documentation.

For exploitation I would recommend this talk, and this paper. They could help you with your search.

Also, there is a new technology called MPX from Intel to protect memory from malicious exploitation. You should go over the Intel doc & this GCC link if you want to dig further into it.