Food for thought
NOTE: in order to avoid the whole copyright mess, most of the files listed here are not actually hosted on this website. I tried to make sure that I only link to legal sources (e.g. USENIX's open access library, an author's own pre-print version), but if you think I was in error someplace, drop me an email and we'll sort it out. I have made some exceptions and locally mirrorred articles which I was afraid would become unavailable (e.g. hosted on personal websites or blogs). If you are the author of one of these articles, or otherwise hold copyright on it, and want the copy removed, just let me know.
ODINI: Escaping Sensitive Data from Faraday-Caged, Air-Gappedd Computers via Magnetic Fields
A remarkably simple (conceptually speaking) method of exfiltrating data from air-gapped, Faraday-caged computers, which relies on modulating low-frequency magnetic fields. Low-frequency magnetic fields are not efficiently contained by Faraday cages. Previous attempts to use them, however, relied on hard disks' magnetic heads, achieving low bit rates over very small distances, whereas these folks cleverly used the CPU's current consumption (directly correlated with its workload) to generate steady magnetic fields by Ampere's law.
The achievable bit rates are fairly low, but sufficient to exfiltrate encryption keys or compressed images. Mounting the attack also require fairly elaborate access; but what is truly fascinating about this attack is how beautifully simple the exfiltration technique is. I could verify it using nothing but my ancient cell phone and a free Android sensor-reading app.
On the Power of Optical Contactless Probing: Attacking Bistream Encryption of FPGAs
A very interesting attack: the authors achieve full bitstream extraction by non-invasive examination of an FPGA chip. They do so by identifying the blocks responsible for configuration, decryption and plaintext outputs, and then retrieve the plaintext as it is being applied. This attack requires only very little physical intervention, none of which endangers the device itself, and can be carried out even with an optical resolution that does not even remotely approach the technology size (1 micrometer resolution vs. 28-nm transistors)
CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management
A fascinating type of attack which exploits the power management subsystem of modern big.LITTLE architectures to (among others) extract cryptographic keys from Trustzone, by manipulating clock frequency and voltages in order to screw up the digital logic in a useful way. It requires a pretty high-profile attack vector (a malicious kernel module), a level of control at which far more trivial attack methods are efficient enough for most attackers, but it is a fascinating hack and certainly a work that opens up a great deal of new possibilities.
Not an academic paper; it's more or less of a marketing document, but interesting nonetheless. It details a remarkable microcontroller architecture, xCORE-200, which tries to address the most stringent scheduling and predictability problems of real-time systems while remaining C-programmable. I haven't actually worked with this architecture, but I sure would like to!
The Internet's Gilded Age
A very interesting parallel between the "gilded age" of the 19th century industrial USA and today's Internet age. Turns out Mark Twain is still relevant, a testament not only to his relentless insight, but also to our collective idiocy.
Intel MPX Explained: An Empirical Study of Intel MPX and Software-based Bounds Checking Approaches
Download: Download page
It is not so much what this paper contains, or what the described approaches allow for, but the shortcomings that it describes and the questions it raises that are interesting. The paper is otherwise relatively modest in terms of original contribution, but is not a bad study at all, and reading it won't be a waste of time.
Food for thought: how would you do these things in hardware:
- Implement hardware memory protection for in-struct memory access?
- Implement hardware protection against post-free() access?
ASLR on the Line: Practical Cache Attacks on the MMU
This paper describes a remarkably effective attack against ASLR which exploits the fact that the data necessary for the virtual:physical mapping, while randomized, is shuffled around through cache memory that all processes share and over which all processes can indirectly exert a certain degree of control.
What makes this technique remarkable among its peers is the fact that it does not rely on any software faults, which could be patched or mitigated. Its foundation is, essentially, the way modern commodity hardware works.
POSIX Has Become Outdated
This is a very interesting high-level study about how POSIX is being used in popular modern applications on OS X, Android and Linux. It reveals that a great deal of POSIX functions are not used anymore; the ones that are used largely fall in four categories: memory, threading, filesystem access primitives, and — possibly as a testament to POSIX's insufficiency at this level — ioctl.
The title is probably more sensational than it's worth (especially considering that the study is heavily skewed towards a certain type of applications), but some of the conclusions are interesting nonetheless. Perhaps the most interesting ones are the divergence in IPC methods, especially as — due to the modern trend towards sandboxing — IPC is becoming increasingly critical in application development today, and the developments in how asynchronous I/O is being used.
While the study is heavily skewed by the way applications are chosen (the authors picked the top N applications in each platform's app store), its conclusions are worth giving some thought.
Early Detection of Configuration Errors to Reduce Failure Damage
This paper presents a fascinatingly clever solution to the problem of checking configuration parameters before a misconfiguration gets a chance to wreck havoc in a system. Ideally, one would check for configuration problems or outright errors as early at startup as possible, but unless a program is designed and written in this fashion from the very beginning, this never happens, and the way you find out that the configuration is wrong is through an assertion failure halfway through the process of applying it. Even if a program does get designed and written like this, manually encoding the constraints that separate a "good" configuration from a "bad" one is tedious and, like everything which involves meatbags, prone to failure due to laziness, lack of sleep and lack of intelligence.
Xu et al. show a clever solution to both problems: they develop a tool which isolates the code that checks the configuration of the program at runtime, sandboxes it and runs the current configuration through it. In essence, it captures all the implicit rules, encoded in isolated checks throughout the code and in failure codes returned by system-level functions (e.g. failure to open a file due to a misspelled path), and turns them into a "verification suite" that can be run prior to applying a potentially disastrous configuration.
Needless to say, the result is only as robust as the inline checks and the underlying runtime, but it is certainly an improvement over nothing at all. Furthermore, it is a remarkably clever way to bring some order in the wisdom of legacy code. One could always insist that it would be far simpler to write good code from the very beginning, but when the very beginning was twenty years ago, this is not as easy as it sounds.