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 doesnt 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, zeros
  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 wont help us understand whats 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) dont take
  appropriate measures to erase sensitive data
  before releasing it to the operating system.