Tracking Sensitive Data in Real World Systems

1. Tracking Sensitive Data in Real World Systems Keith Harrison, Dr. Shouhuai Xu

2. Introduction • Knowing where sensitive data, such as private cryptographic keys, propagates to within a system is important! • Real world hardware and software is very complex. • In order to ensure that software and hardware are taking the necessary steps to minimize security risks a tool is needed to examine where exactly sensitive data propagates to

3. The Problem • Sensitive data may be compromised a number of ways • Application Vulnerabilities • Hardware/Kernel Vulnerabilities • Insecure System Setup • Poor physical security

4. Application Vulnerabilities • Buffer Overflows • Heap Overflow • Format String Vulnerabilities • Many possibilities…

5. Hardware Kernel Vulnerabilities • Could allow an unprivileged process to read data from another process space • Kernel or Kernel module bug • Hardware bug

6. Insecure System Setup • Poor file permissions • “Would you like Windows to remember this password for you?” • Automatic Logins

7. Poor Physical Security • An unprivileged user may have unsupervised physical access to the box • Use of boot disks • Non-password protected bios

8. What to do? • The naïve approach would be to hide the sensitive data. • But this doesn’t work! • In “Playing ‘Hide and Seek’ with Stored Keys” by Adi Shamir and Nicko van Someren. They show that hidden private keys can easily be found even if the public key is not known by identifying sections of high entropy.

9. Take Preventative Action! • Limit the exposure of sensitive data as much as possible so that if an adversary finds a vulnerability the chance of compromising the sensitive data is as low as possible.

10. How? • Reduce the number of copies of the sensitive data on disk and in memory as much as possible. • Use mlock() to avoid sensitive data being swapped out. • Make sure and clear the memory before releasing it back to the operating system.

11. This is still not enough. • It would be very hard to guarantee that every program that handles sensitive data an your system will do this. • Even if a program, in its source code, zero’s memory before releasing it to the operating system compiler optimizations may omit the instruction to do this in favor of speed. • In some High level languages like python or java you may not be able to zero a list or a string because a copy may be made without your knowledge.

12. First Step • As a first step in understanding the problems associated with protecting sensitive data in real world systems we need to find a way to analyze where in the system the sensitive data propagates to. • Many possibilities: registers, cache, hard disk, memory, swap space.

13. Previous and Concurrent Work • All previous and concurrent work found in this area make use of a whole system simulator such as the open source Bochs IA32 Emulator used by Jim Chow et al in “Understanding Data Lifetime via Whole System Simulation”

14. But what about a real system? • Any simulator, no matter how clever, may not precisely duplicate a real system. • Application developers and home users would not want to run a slow simulator in order to see what's going on inside their application. • I focus on memory, hard drive, and swap space since those are the most vulnerable in real systems.

15. Naïve Approach: • Directly read the device i.e. /dev/hda1 • Directly read through the file system • Read from /dev/mem or /proc/kcore • But this is a very bad idea because reading via a file descriptor in any manner will inadvertently create copies of what your reading (i.e. the sensitive data) in memory. • This won’t help us understand what’s really going on!

16. RSA private keys • Say for example we wanted analyze the data lifetime of a RSA private key for Apache or OpenSSH. • The key exists in only one place in the file system so this part is trivial. • But what about memory and swap space?

17. Analyzing Memory • Write two kernel modules! • One kernel module will read physical memory directly via a pointer and find where exactly in physical memory this data exists. • The other kernel module will find all physical memory pages accessible by all process. • Correlating the results of these two modules we can see which processes have access to the sensitive data and if any sensitive data exists which is not accessible by any process.

18. Analyzing Swap • Read the device directly, however this interferes with memory so we are forced to analyze swap space separately from the analysis of memory

19. Simulations • In order to test the tool simulations were run on both Apache and OpenSSH • OpenSSL is used by both Apache and OpenSSH • An Isolated LAN was used for the simulations • Linux 2.6 Kernel • Gentoo Distribution

20. Simulation Outline • T1 – Daemon Started • T4 – Transactions Started • T7 – Transactions Increased • T10 – Transactions Stopped • T13 – Daemon Stopped • T16 – Free Memory Cleared • T19 – Simulation End

21. Apache

22. OpenSSH

23. Swap • In all recent simulations run the RSA private key has never appeared in swap space. • This is most likely because the RSA private key is frequently used making it a poor choice to swap to disk.

24. Advantages of this Approach • Can monitor location of sensitive data in real time. • No special software or hardware required. • Only thing required is kernel module support which is default for almost every Linux distribution.

25. Limitations of this Approach • Our algorithm is fast but it still takes anywhere from 5-30 seconds to run depending on the amount of memory we have and the number of processes running. • Since we can not, and would not want to stop context switches in this time our analysis can not be counted on to be perfectly accurate. • But its still a Great Tool for visualizing and analyzing what exactly is going on!

26. Continuing Work • Find Why the RSA private key is not being erased before it is being released back to the operating system and correct this! • Implement in-kernel algorithms to better remove sensitive data that is not properly cleared before being released back to the operating system as outlined in “Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation” by Jim Chow et al.

27. Future Work • Find a way to access swap space from kernel space. • Perhaps there is a method to reverse lookup which processes have access to which memory pages, this would speed the algorithm considerably making it much more accurate.

28. Conclusion • Tracking Data Lifetime is Important! • Simulators are a useful tool, but they are not a REAL system. Real world systems may behave differently! • Apache and OpenSSH (or OpenSSL) don’t take appropriate measures to erase sensitive data before releasing it to the operating system.