To defeat code injection attacks, in addition to DEP, Alice proposed an approach

Question

To defeat code injection attacks, in addition to DEP, Alice proposed an approach called instruction set randomization(ISR).
The basic idea of ISR is to randomize the instruction set(e.g., a MOV instruction at attacker's machine maybe different
compared to the victim's machine). To deploy her ISR, she used a virtual machine monitor that translates each instruction
to appropriate form under her control(e.g., think about an XOR operation), thereby the injected shell code will be
translated incorrectly if attacker doesn't know how the translation is performed. Please justify the defense of this
approach, e.g., the pros and cons of this approach.

Explanation / Answer

Code-injection attacks attempt to deposit e x ecutable code (typically machine code, b ut there are cases where intermediate or inter -preted code has been used) within the address space of the victim process, and then pass control to this code. These attacks can only succeed if the injected code is compatible with the execution en- vironment. F or example, injecting x86 machine code to a process running on a SUN/SP ARC system may crash the process, but will not cause a security breach. Notice that in this example, there may well exist sequences of bytes that will crash on neither processor . Our approach leverages this observation: we create an execution environment that is unique to the running process, so that the attacker does not know the “language” used and hence cannot “speak” to the machine. We achieve this by applying a reversible transfor - mation between the processor and main memory . Effectively , we create new instruction sets for each process executing within the same system. Code-injection attacks against this system are unlikely to succeed as the attacker cannot
guess the transformation that has been applied to the currently executing process. Of course, if the attack ers had access to the machine and the randomized binaries through other means, the y could easily mount a dictionary or known-plainte xt attack against the transformation and thus “learn the language”. However , we are primarily concerned with attacks against remote services Vulnerabilities in this type of server allow external attacksand thus enable large scale exploitation. Protecting against internal users is a much more difficult problem, which we do not address in this work.

Advantage

bringing diversity into computer systems, and lik ens the ef fects to that which diversity helps cause in biological systems. The y observed how the lack of di v ersity among computer systems can facilitate lar ge-scale replication of exploits due to the identical weakness being present in all instances of the system. Some ideas are presented regarding using randomized compilation to introduce sufficient diversity among softw are systems to severely hamper large-scale spreading of exploits. Among these, the ones most relevant to this paper involve transformations to memory layout. There has been considerable research in pre v enting b uf fer o v er - flo w
attacks. Broadly , it can be classified into four cate gories: safe languages and libraries, source code analysis, process sandboxing, and,for lack of a better term, compiler tricks.

Diadvantage

main drawback of our approach as applied to code that is meant to e x ecute on a processor is the need for special sup- port by the processor . In some programmable processors, it is pos- sible to introduce such functionality in already-deployed systems. However , the v ast majority of current processors do not allow for such flexibility . Thus, we are considering a more general approach of randomizing softw are as away of introducing enough diversity.among different instances of the same version of a piece of popular software that large-scale exploitation of vulnerabilities becomes infeasible. We view that work, which is still in progress,

A second drawback of our approach is that applications have to be statically linked, thus increasing their size.we worked around this issue by using a single-image v ersion of OpenBSD. In practice, we w ould seek to randomize only those programs that are exposed to remote exploits,network daemons, thus minimizing the overall impact of static linking to the system. Furthermore, it must be noted that avoiding static linking is going to help reduce only the disk usage,not the runtime memory requirements.

Also note that our form of code randomization effectively precludes polymorphic and self-modifying code, as the randomization key and relevant code would then have to be encoded inside the program itself, potentially allo wing an attacker to use them. Instruction randomization should be viewed as a self-destruct mechanism: the program under attack is likely to go out of control and be terminated by the runtime environment. Thus, this technique cannot protect against denial of service attacks and should be considered as a safe guard of last resort,it should be used in conjunction with other techniques that prevent vulnerabilities leading to code-injection attacks
from occurring in the first place. Debugging is made more difficult by the randomization process, since the debugger must be aware of it. The most straightforw ard solution is to derandomize the executable prior to debugging; the debugger can do this in a manner transparent to the use, since the secret key is embedded in the ELF executable. Similarly , the debugger can use the key to de-randomize core dumps. Finally , our approach does not protect against all types of buffer overflow attacks. In particular , overflows that only modify the contents of variables in the stack or the heap and cause changes in the control flow or logical operation of the program cannot be defended against using randomization. Similarly , our scheme does not protect against attacks that cause bad data to propagate in the system, not checking for certain Unix shell characters on input that is passed to the
system() call. None of the systems we e xam- ined in Section 5 protect against the latter , and very few can deter the former type of attack. A more insidious overflow attack would transfer the control flow to some library function. T o defend against this, we propose to combine our scheme with randomizing the layout of code in memory at the granularity of in- dividual functions,thus denying to an attacker the ability to jump to an already-known location in existing code.

Related Questions

Navigate

• Browse (All)
• Browse T
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.