Papers - January 2016 January 11, 2016
Second installment of the Papers series. Be sure to read the first one from a couple of months ago!
> The Limitations of Deep Learning in Adversarial Settings (2015)
Adversarial samples are samples produced in such way that they differ minimally from beneign samples. Even though humans still correctly classify them, a DNN fails and produces class labels controlled by the adversary. Well written, understandable paper. Impressive.
> Mind your language(s): A discussion about languages and security (2014)
LangSec is a hugely important part of InfoSec that does not currently receive the attention it deserves. Absence of type-checking, (implicit) casts and overloading all constitute possible security problems that need to be carefully addressed. The paper is full of interesting tidbits, quotes and rather amusing vulnerabilities (Try to rm a file called -rf for instance).
> Going Bright: Wiretapping without Weakening Communications Infrastructure (2013)
“Taking advantage of [existing vulnerabilities] is far preferable to introducing new vulnerabilities into other applications or infrastructure […]”. Better, yes, but not good. Also somewhat related.
> ret2dir: Rethinking Kernel Isolation (2014)
Interesting, practical paper doing useful research. The authors, which were also nominated for a Pwnie, also released all source code.
> ROPecker: A Generic and Practical Approach for Defending Against ROP Attacks (2014)
Cool research on ROP attack mitigations. Does not modify the binary - neither on disk or at runtime - and is thus much more suited to general application. Unfortunately only protects user-space code and there are a few ways to bypass the techniques. Fortunately, these techniques greatly increase the cost of an adversary, reducing the likelyhood you will fall victim to an attack.
> Protecting Android Apps Against Reverse Engineering by the Use of the Native Code (2015)
The authors propose techniques to raise efforts needed to reverse engineer Android applications by introducing one native function responsible for field accesses, method call indirection and opaque predicates. Not a huge fan, considering the performance (and therefore battery) impact is on the order of 10x to 30x.
Also worth reading: