As a Georgia Tech OMSCS student as well as working software professional, advanced security topics are always something I want to learn more about. Georgia Tech’s Institute for Information Security & Privacy is presenting a weekly Cybersecurity Lecture Series on Fridays this fall, and being a local I’ve started attending them. Here are my quick (albeit not necessarily complete) notes from this week’s presentation by Joel Odom of CipherLab @ GTRI.

Highlights of the 1940’s

• Dawn of the nuclear age
• Birth of modern computing (Turing, Shannon)
• Formation of the coolest model railroad club ever
  • Came up with cool “hacks” to fix railroad infrastructure
  • Roots of MIT hacking labs
• Eventually led to “hackers” becoming more criminal in nature during the 1980’s…

What is software assurance?

“Software assurance relates to the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software.”

Even embedded real-time and enterprise operating systems are vulnerable.  Some food for thought:

• The Linux kernel contains over 19m lines of code
• It was written by more than 14k contributors
• Runs on CPUs that typically contain ~1b logic gates
• What could possibly go wrong?

Common vulnerabilities

Common vulnerabilities & exposures  (CVE) trending up year-over-year

Bugs –> vulnerabilities –> exploits

Biggest culprits:

• Memory mismanagement
  • Buffer overflow/overread
• Misuse of cryptography or security protocols
  • Failure to validate security certs
  • Attempt to one-up existing security libraries (I can write it better!)
• Misconfiguration
  • Weak or default passwords
  • Leaving on debugging/testing features
• Race conditions
  • Time of check vs time of use

Notable exploits

• Morris Worm (1988)
  • Stack smashing
• Heartbleed (2014)
  • Allowed access to all memory on the affected server
  • Protocol request number of bytes + sample data
  • Malicious client would request up to 64k of heap memory, including requested payload

Fuzzing as a Search Problem

• Starts with a set of seed inputs
• Permute seed inputs until the software crashes
• Find a way to exploit crash, remediate if possible
• Code reviews only find ~10-15% of vulnerabilities
• Symbolic analysis can find a lot more
• Fuzzing can examine a larger hypothesis space

Key points from “top ten” public list of what devs can do:

• Use effective QA techniques
  • Hammer on it!  Break it!
• Minimize attack surface
  • Reduce opportunities for hackers to exploit
• Don’t trust anyone
  • Validate data/binaries no matter where it came from – both code and data!