October 31st, 2024

Almost Secure (2011)

The blog post outlines classic vulnerabilities in devices, including mass storage issues, inadequate cryptographic practices, poor input sanitization, risks from /dev/mem, and boot sequence failures that expose systems.

Read original articleLink Icon
Almost Secure (2011)

The blog post discusses several classic vulnerabilities that can affect various devices, particularly those that handle mass storage and cryptographic functions. It highlights the ext2 symlink directory traversal vulnerability, which allows unauthorized access to a device's filesystem through improperly managed mass storage. The post also addresses issues with cryptographic modes, particularly the use of AES in CBC mode, which lacks integrity checks and can lead to data recovery by attackers. Additionally, it emphasizes the dangers of inadequate sanitization of configuration strings, which can lead to arbitrary code execution. The existence of /dev/mem in Linux systems is noted as a potential risk, allowing attackers to access sensitive memory areas. Other vulnerabilities include write-only registers that can be exploited for key recovery and the reliance on success in boot sequences, which can inadvertently expose systems to remote access. The author stresses the importance of understanding these vulnerabilities to enhance device security.

- Classic vulnerabilities can affect many devices, especially those with mass storage.

- Inadequate cryptographic practices can lead to data breaches.

- Poor sanitization of user input can result in security exploits.

- The presence of /dev/mem can facilitate unauthorized access to system memory.

- Boot sequence failures can inadvertently expose systems to remote access.

Link Icon 2 comments
By @upofadown - 3 months
Talking about the idea of using plain AES-CBC for disk encryption:

>He can then inject arbitrary sectors into this file, dump the file, and recover plaintext.

You wouldn't recover any plaintext here unless you could create an actual oracle based on that plaintext. It is unclear to me how you could generically do that with a disk encryption situation. You would have to do something like triggering errors based on the decrypted and modified plaintext. How would the attacker get access to these errors? The real problem is the ability to create valid changes to the disk (malleability).

>There are cryptographic modes (like XTS) which fix these problems.

XTS is malleable at the block level. CBC is malleable at the bit level but that isn't really a lot worse for whole disk encryption. XTS is still better, so yes, you should still prefer XTS over CBC. Integrity checking requires extra data. For full disk encryption there is no obvious place to put such data. So the common practice is to just not worry about integrity.

>In CBC, the chaining aspect will screw up the first block only, and even that can be manually fixed since the ciphertext is known.

The screwed up block shows up as decrypted plaintext. So you can't get around the bad blocks on the edges of splices with knowledge of the ciphertext.