📜 ⬆️ ⬇️

Ideas about the self-limiting protection mechanism in Windows

Parents know best what their child can do and what not. Similarly, the programmer of a particular program knows better than others what actions the program should perform and which not. But not everything is as good as we would like. Malicious programs often interfere with the work of other programs. The consequences of exploiting vulnerabilities in network programs are not at all predictable. All this somehow violates information security not only in enterprises, but also on computers of ordinary users.

And how it would be nice if the program itself knew what actions it doesn’t need and turned off them just in case.


')
Antiviruses and other similar systems try to take on the role of defenders, but all protection comes down to a set of rules that are the same for many and do not take into account the specifics of the programs being protected. This approach sometimes leads to unpleasant situations. Here are some examples:


But as mentioned above - the author of the program knows best what his program should do. So why not give him the opportunity to put restrictions on certain actions? And not for the whole program, but for specific streams.

Efficiency of the idea

Thanks to this, you can achieve:


Speaking from a more realistic point, one could:


Features of the implementation and use of ideas

To implement the idea you need in the Windows kernel:


In kernel32.dll add one function to control the protection. Which also will not be very big.

These actions under the force of any programmer (and in one day). But the biggest difficulty is that Microsoft itself has to do it. That is why this protection mechanism remains in dreams.

Theoretical retreat

Since any restrictions in user mode (user mode) are easily bypassed or removed, it is necessary to implement all the protection in the kernel.

The basic principle of calling system functions in Windows can be represented as the following diagram:



After calling sysenter / syscall / int 0x2E or call dword ptr fs: [0xC0] (depending on the windows version), further control will go to the kernel, where the KiSystemService function looks at the table of system service addresses (SDT) and by the service number (transmitted in the eax register) ) finds the address of the desired function and then transfers control to it. In this way, the function is called.

The system uses two tables - one is responsible directly for the system and is processed by the kernel, and the second is responsible for the work of the GUI and is processed by the win32.sys driver. We are interested in the first table.

Thanks to this architecture, it is possible to put access restrictions on the call of any system function. To do this, simply insert a simple check into the KiSystemService function.

We have already found the place of verification, now it is necessary to find a place for storing the access matrix.

In Windows operating systems, the kernel uses the KTHREAD structure to describe the flow, which is different for each thread. This is where the access matrix can be stored. But now it will not be a matrix, but a line list (since each stream will store information only about itself).

Everything is good, but there is also a network, work with which is organized through special drivers. But even here, the problem is solved in processing some IRP requests to the devices \\ Device \ Tcp, \\ Device \ Udp, \\ Device \ Raw, which will also allow you to transparently check the ability to access the network from certain streams.

How we will implement protection

The implementation of protection is seen as follows:


Protection work progress:


I would like to pay special attention to the protection installation function. She sees the prototype as:
DWORD QuerySystemSecurity (HANDLE hThread, DWORD Flag, QWORD * Key, VOID * Data);


Also in QuerySystemSecurity there should be a table of correspondence to the number of the function to be prohibited and its number from the SDT. the latter changes from version to version.

Conclusion

Thanks to one simple function and a small modification of the kernel, you can get quite flexible and fast protection. The programmer himself will be able to forbid abnormal actions to his programs. That would be very useful in network programs and primarily in browsers.
Protection based on this approach would be able to more flexibly control the execution of third-party code in programs (not only malicious, but also plug-ins from other authors). If small developers would not be interested in such protection, then large developers could easily use it to enhance the protection of their programs against the interference of someone else's code.

Of course, such protection can be implemented not only by Microsoft itself, but also by third-party developers, but this will already be a crutch and will not work as effectively (due to the fact that you have to refuse to store data in PTHREAD) well, and will not have such a global scale.

But as always, these are only personal dreams about the existence of protection, which are unlikely to be realized by Microsoft.

Source: https://habr.com/ru/post/145174/


All Articles