Obstacle to execution of dynamic libraries functions from data and stack memory

The essence of a method consists basically functioning Windows NT. Any program is carried out in non-privileged 3th ring of protection of the processor. Itself the operational system and drivers works in a 0-ring. Therefore to perform any operations of interaction with external devices and with privileged memory, i.e. practically of any not computing operation the application should use service functions of operational system, that is showed at the following figure.

System services calls

As you see from a figure, the applications and subsystems function at non-privileged mode of the user, and OS kernel with its services at a mode of a kernel. The Win32 subsystem is formed by KERNEL32. DLL and some other libraries which uses the OS interface given NTDLL.DLL. NTDLL.DLL call OS services through interruption 2E. The application also may call directly NTDLL.DLL and cause int 2E. Interruption handler working in a kernel mode, defines a entry point of required service by the system services table and go to it. The required service code is defined by EAX register.

So the essence of the given protection method consists the code introduced attacking in the buffer, as well as any other program, usually must call dynamic library functions. Thus, it is possible to produce protection if to each exported dynamic library function add a check code that checks call address. The call address corresponds to the return address of called external function. Therefore arrangement of the return address in data or stack is a attack sign.

The addition of a check code is carried out by means of updating an binary file of dynamic library. And, the updating is reliable and produced by changes of exported functions DLL changes and original code isn't mentioned.

The complexity represents only introduction to an binary file of dynamic library of a check code. Nice exploit does not depend on DLL versions and works through the import table of the attacked program or receives function addresses of by LoadLibrary, GetProcAddress calls.

Due to such technique exploit code runs on any configuration of operational system. Just such attacks also are counteracted by the given protection. In case attacker uses in exploit the exactly defined exported function addresses that is necessary to him the given protection in this kind is powerless. However, attacker can not to develop universally exploit code. As an additional protection measure may be used reallocation DLL to other base address. But attacker can find an DLL image necessary in memory and to calculate required function addresses.

So, this method nevertheless provides of complete protection, but complicates to vulnerable without some information about attacked system.

(C) 2000, Andrey Kolishak