The Craft of System Security |
 |
| 13 Nov 2007 | SearchSecurity.com and Addison-Wesley |
|
|
The following is an excerpt from the book, The Craft of System Security. In this section of Chapter 16: Hardware-Based Security (.pdf), authors Sean Smith and John Marchesini explain how an adversary can extract data from a device, even after that information has supposedly been 'erased.'
Historically, nonvolatile magnetic media, such as disks or once ubiquitous tapes,
have been notorious for retaining data after deletion. On a physical level, the contents
of overwritten cells have been reputed to be readable via magnetic-force microscopy;
however, a knowledgeable colleague insists that no documented case exists
for any modern disk drive. Nonetheless, researchers (e.g., [Gut96]) and government
standards bodies (e.g., [NCS91]) have established guidelines for overwriting cells
in order to increase assurance that the previously stored data has been destroyed.
(The general idea is to write a binary pattern, then its complement, then repeat
many times.)
A complicating factor here is the existence of many layers of abstraction between
a high-level request to delete data and what actually happens on the device in
question. In between, many things could cause trouble.
- For example, a traditional filesystem usually breaks a file into a series of
chunks, each sized to occupy a disk sector, and distributes these chunks on the
disk according to various heuristics intended to improve performance. Some
type of index table, perhaps in a sector of its own, indicates where each chunk
is. In such a system, when the higher-level software deletes or even shrinks a
file, the filesystem may respond by clearing that entry in that file's index table
and marking that sector as "free." However, the deleted data may remain on
the disk, in this now-free sector. (Issues such as this led to the object reuse
worries of the Orange Book world of Chapter 2.)
- Journaling filesystems, a more advanced technology, make things even worse.
Journaling filesystems treat the disk not as a place to store files so much as a
place to store a log of changes to files. As with Word's Fast Save option (see
Chapter 13), the history of edits that resulted in a file's current state may be
available to the adversary inspecting the disk itself.
- Computing hardware has seen a sort of trickle-down (or perhaps smarting-down)
effect, whereby traditionally "dumb" peripherals now feature their
own processors and computing ability. Disk controllers are no exception to
this trend, leading to yet another level of abstraction between the view the
computing system sees and what actually happens with the physical media.
FLASH
In recent years, semiconductor FLASH memory (e.g., in USB thumbdrives) has
probably become more ubiquitous than magnetic media for removable storage.
FLASH is also standard nonvolatile storage in most embedded devices, such as cell
phones and PDAs. The internal structure of a FLASH device is a bit more complex
than other semiconductor memories (e.g., see [Nii95]). FLASH is organized into
sectors, each usually on the order of tens or hundreds of kilobytes. When in "read"
mode, the device acts as an ordinary ROM. To write a sector, the system must put
the FLASH device into write mode, which requires writing a special sequence of
bytes, essentially opcodes, to special addresses in the FLASH device. Typically, the
stored bits can be written only one way (e.g., change only from 0 to 1). To erase a
sector (e.g., clearing all the bits back to 0), another sequence of magic bytes must
be written. Often, FLASH devices include the ability to turn a designated sector
into ROM by wiring a pin a certain way at manufacture time.
FLASH gives two additional challenges for system implementers. First, writing
and erasing sectors both take nontrivial time; failure, such as power interruption,
during such an interval may lead to undetermined sector corruption. Second, each
FLASH cell has a relatively small (e.g., 10,000) lifetime of erase-write cycles.
These technical limitations lead to incredible acrobatics when designing a
filesystem for FLASH (e.g., [GT05, Nii95]). In order to avoid wearing out the
FLASH sectors, designers will use data structures that selectively mark bits to indicate
dirty bytes within sectors and rotate usage throughout the sectors on the device.
For fault tolerance, designers may try to make writes easy to undo, so that the old
version of a file can be recovered if a failure occurs during the nontrivial duration
of a write. Even relatively simple concepts, such as a directory or index table, get
interesting—if you decide to keep one, then you'll quickly wear out that sector, even
if you're clever with the rest of the files.
FLASH architecture has several consequences for security.
- Because of these log-structured and fault-tolerant contortions, old data may
still exist in the device even if the higher levels of the system thought it was
erased.
- Because an error in a product's ROM can be expensive, at least one vendor
includes an undocumented feature to rewrite the ROM sector by writing a
magic series of bytes to the chip. (The complexity of the legitimate magic-byte
interface makes it hard to otherwise discover such back doors.)
- Because of the large market demand for low-cost thumbdrives and the
smarting down of computation into peripherals, much engineering has gone
into commercial FLASH drives, leading to a gap between even the API the
encapsulated device provides and the internal state.
Read the rest of Chapter 16: Hardware-Based Security.
Reproduced from the book The Craft of System Security Copyright [2007], Addison Wesley Professional. Reproduced by permission of Pearson Education, Inc., 800 East 96th Street, Indianapolis, IN 46240. Written permission from Pearson Education, Inc. is required for all other users.
|
|
|
|
