CS110L L1 - Safety in System Programming

• Learning Advanced Mathematics is just too boring, I need something interesting.

---

Warning

If someone is reading this blog, please be aware that the writer did not consider the experience of the other readers.
After all, the most important part is about writing things down for better memorization.

Why not C/C++?

• Severe security problem could happen if C/C++ code is not carefully handled.

• For example, a classic buffer overflow attack might happen during the runtime of the code below:

  #include <stdio.h>
  #include <string.h>
  
  int main() {
      char s[100];
      printf("\nEnter a string: ");
      gets(s);
  
      for (int i = 0; s[i] != '\0'; i++) {
          // ...
      }
  
      printf("\nString in Upper Case = %s", s);
      return 0;
  }

• The general idea of a buffer overflow attack is to fill the buffer out of its intended size, in which case malicious data could grow from low addresses to high addresses, potentially overriding the return address of the currently executing function.

• The famous Morris Worm virus took advantage of this ‘feature’ of C, and took down thousands of computers back in 1988.

---

• You might argue that well nowadays programmers are aware of those holes, and they would handle their code well that does not involve any of these issues. Or is it that ‘Professional engineers don’t make such silly mistakes’ you might consider.

• Fact is that countless real-world examples have shown that even the big tech company like Google/Microsoft who had invested a lot in security still include many of those ‘simple’ mistakes in their products. Not because they are silly, it’s just that the buffer-overflow issue could happen anywhere and hard to mitigate.

• See this example below:

  char buffer[128];
  
  int bytesToCopy = packet.length;
  if (bytesToCopy < 128) {
      strncpy(buffer, packet.data, bytesToCopy);
  }

• At first glance the code is fine, with proper boundary check and using strncpy instead of strcpy.

• Turns out the problem in this code lies in the type of variable bytesToCopy: it’s an int type, while strncpy‘s third parameter takes in a size_t type, which is an unsigned integer. If the attacker transfer a packet with a ‘negative length’, the if-check would pass and strncpy would allow for a really large string copy which could eventually overflow the 128-byte buffer created in stack for the packet data.

Why not GC Language?

• Simple reason: they’re slow.

• Plus, they’re not necessarily safe as well.