Data Lifetime (64 61 74 61)

Data Lifetime is a system problem

Any piece of software we build has a possibility of being vulnerable to either
a known flaw or a zero day vulnerability. Using such malicious parties will continue to gain access to the machine. Although it’s highly impossible to become immune to such attacks, we could build systems putting our best effort to minimize the impact of such critical compromises.

Reducing the risk of sensitive data exposure is an essential part of this process.how do we do that, you might ask. To be frank most of the compromises that happen are related to common sense.

~ Encryption Keys

~ Passwords / Multi-Factor Authentication

~ Financial Documents

~ Medical Information

In a system at any point of execution, such sensitive data could be leaked. The duration of time given for the sensitive data remains in a system and its propagation through the system as Data Lifetime. A Data Lifetime and the risk of exposure is directly proportional. If a piece of data is stored in a device for a relatively long period of time the risk of that being exposed increases along with the time.

These issues are not usually taken seriously by the people, the data lifetime issue also receives much less attention than vulnerabilities, this lead to rarely addressed cases in OS, Programming Languages etc.

Data Lifetime Problems:
Usually when a Data is deleted it’s not actually deleted instead the system just ignores the binary value of that data in the hardware. These binary value can be read, which could lead to recover the data unless those binary values are tampered or replaced with a different sets of values. We define the lifetime of sensitive data in_terms of the following components.

~ Where copies of this data endup

~ How long these copies survive before being cleared or otherwise destroyed.

The persistence of the binary values in the hardware (i.e. HDD, SSD, RAM, etc). Whenever you copy a piece of data they need not be identical to each other. E.g. : A password could have different encodings in its lifetime

A same password in a windows machine could have a LM hash value or an NTLM hash value. In a Linux machine it would be as a shadow file, or each time you copy this piece of pass text it could end up as Unicode, ASCII, UTF-8, Keyboard scan cases, base-6e encoded etc.

The death of the data is usually when the encoding pattern is forgot or the encryption key is lost in such a way that the original data is unreadable or not recoverable or the data was overwritten.

Propagation:
~ Sensitive data propagates through many parts of the system leaving traces behind, few of them are listed below.

~ Interrupt context keyboard queue: Linux reads keystrokes during a hardware interrupt and appends them to a circular queue

~ Process “tty” buffer: The OS copies characters from the interrupt-context queue into a tty buffer.

~ Window system event queue: The X server reads characters from the tty buffer into its own event queue.

~ Network buffer, Widget Buffer, String Buffers are few more additions.

None of these data is erased as soon as they were used, these were only erased to make room for the next incoming data. If there wasn’t any other process that required the buffer memory these data would be there for ages.

Data can also propagate to the persistent storage through a range of mechanisms:

~ Core dump

~ Hibernation

~ Checkpointing

~ Paging

~ Application Specific

Possible Outsider Threats:

~ Online remote attacks : Example Bluekeep Vulnerability

~ Offline Physical attack : EG, Improper depose of unencrypted devices.

~ Online Physical attacks : EG, tap buses, read memory etc

~ Accidental Leakage : E.g., Human error, Insider threat

Possible fix for Data Lifetime threats:

Reducing Data Lifetime:

~ Make Data clearing automatic : Data stored in the buffers should be validated for their needs from time to time and should be flushed if they are no longer required.

~ Provide Policy trade-offs : Encryption, Zeroing or pinning would be helpful.

~ Design for data lifetime : Program design could have a positive impact, for instance a program should validate passwords each time rather than storing them in the cache.

~ Identify sensitive data : Components that care about data lifetime must be treated as sensitive and proper care should be taken care off.

Provide Secure defaults : Impose minimal security features for every sensitive function.

Although there is a long way towards a secure the way that we interact these small implications would be beneficial. Its time to considered even the fractional part of the vulnerability such as Data lifetime to be highly important.

Reference : https://benpfaff.org/papers/dlsp.pdf
Link to original post : https://blankdash.wordpress.com/2019/12/23/data-lifetime-64-61-74-61/

  • blankdash
3 Likes

This topic was automatically closed after 121 days. New replies are no longer allowed.