Abstract
In computer science and fashion alike, comebacks are often unavoidable, yet not always desirable
(think “mullet”). But while the vagaries of fashion are impenetrable, trends in computer security
follow logical rules. For instance, the implementation of mitigation technologies in modern OS
(such as DEP and ASLR on Windows) has made leveraging a memory corruption bug into a
working exploit a tremendously difficult task today. As a consequence, ancient exploitation
techniques that don’t rely on memory corruption seem to become popular again. The
DLL-Preload Attack is one of such.
This attack relies on a MS Windows system feature, which, in certain circumstances (read: when
an application developer lacked caution or knowledge. But who never does?) can be abused to
achieve escalation of privilege. Combined with either another exploit or simply a pinch of social
engineering, it can even perfectly lead to execution of arbitrary code on the system by a remote
attacker.
This paper’s aim is twofold: raise awareness on the issue - although this attack is not new, many
applications, including very high profile ones, are subject (i.e. “vulnerable”) to it - and foster best
practice for developers and testers.
Both aims are addressed by highlighting 7 typical mistakes in the development/QA process of
applications that lead them to be vulnerable, identified via the analysis of 7 previously
un-released instances of the vulnerability, in the following applications/OS: [pending disclosure],
[pending disclosure], [pending disclosure], [pending disclosure], [pending disclosure], [pending
disclosure], and [pending disclosure].
The paper concludes on the responsibility of application vendors in future instances of the
vulnerability, as a system-wide solution that would not break backward compatibility is unlikely
to exist.
more here......http://www.fortiguard.com/files/DLL-Preload_Attack.pdf
In computer science and fashion alike, comebacks are often unavoidable, yet not always desirable
(think “mullet”). But while the vagaries of fashion are impenetrable, trends in computer security
follow logical rules. For instance, the implementation of mitigation technologies in modern OS
(such as DEP and ASLR on Windows) has made leveraging a memory corruption bug into a
working exploit a tremendously difficult task today. As a consequence, ancient exploitation
techniques that don’t rely on memory corruption seem to become popular again. The
DLL-Preload Attack is one of such.
This attack relies on a MS Windows system feature, which, in certain circumstances (read: when
an application developer lacked caution or knowledge. But who never does?) can be abused to
achieve escalation of privilege. Combined with either another exploit or simply a pinch of social
engineering, it can even perfectly lead to execution of arbitrary code on the system by a remote
attacker.
This paper’s aim is twofold: raise awareness on the issue - although this attack is not new, many
applications, including very high profile ones, are subject (i.e. “vulnerable”) to it - and foster best
practice for developers and testers.
Both aims are addressed by highlighting 7 typical mistakes in the development/QA process of
applications that lead them to be vulnerable, identified via the analysis of 7 previously
un-released instances of the vulnerability, in the following applications/OS: [pending disclosure],
[pending disclosure], [pending disclosure], [pending disclosure], [pending disclosure], [pending
disclosure], and [pending disclosure].
The paper concludes on the responsibility of application vendors in future instances of the
vulnerability, as a system-wide solution that would not break backward compatibility is unlikely
to exist.
more here......http://www.fortiguard.com/files/DLL-Preload_Attack.pdf