Windows Self-Restriction Security Ideas

Parents know best what their child can do and what not. So 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 others. The consequences of exploiting vulnerabilities in network programs are not predictable at all. All this in one way or another violates information security not only in enterprises, but also on the computers of ordinary users.

And it would be nice if the program itself knew what actions it did not need and, just in case, turned them off.



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 protected programs. This approach sometimes leads to unpleasant situations. Here are some examples:

• Introduced malicious code into the browser - gets unhindered access to network functions.
• Embedded malicious code in the mail program - will gain unhindered access to the mail database files, despite the fact that the antivirus will protect these files.
• Exploiting vulnerabilities in network programs - sometimes it allows you to gain access to the system or increase rights, despite the fact that the user may have minimal rights.

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 threads.

Idea Productivity

Thanks to this, you can achieve:

• Information processing and visualization flows could not work with the network.
• Network workflows could not run another program or be embedded in someone else's process.
• Malicious code embedded in the program could not take advantage of its level of trust with antiviruses.

Speaking from a more realistic point, one could:

• The browser itself could prohibit the launch of third-party programs.
• The mail program could have access to the database files, but the code embedded in it could not.
• Any program could learn about its abnormal activity.

Features of the implementation and use of ideas

To implement the idea, it is necessary in the Windows kernel:

• Make edits in two system structures.
• Add one system call.
• Write code on 50-100 lines.

In kernel32.dll add one function that controls protection. Which also will not be particularly large.

These actions are within the power of any programmer (and in one day). But the biggest difficulty is that Microsoft itself must do this. That is why such a defense mechanism remains in dreams for now.

Theoretical retreat

Since any restrictions in user mode are easily circumvented 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 scheme:



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

The system uses two tables - one is directly responsible for the operation of the system and is processed by the kernel, and the second is responsible for the operation 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 restriction on the call of any system function. To do this, just insert a simple check into the KiSystemService function.

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

On Windows operating systems, the kernel uses the KTHREAD structure to describe a stream, which each stream has its own. This is where it will be possible to store the access matrix. But now it will no longer be a matrix, but a linear list (since each thread will store information only about itself).

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

How we will implement protection

The implementation of protection is seen as follows:

• In the description structure of each stream there is a table of prohibitions consisting of bits. In Windows 7, the SDT has 360 functions, so an array of 512 bits (64 bytes) is enough above the roof.
• By default, all bits are reset (i.e. there are no bans)
• There is also a 64-bit key field, which will be discussed a bit later.
• There is also a 32/64 bit field storing the callback address of the function
• Total we have data for 76/80 bytes
• Another system call has been added to the kernel, which fills the structure according to the following rules:
  
  • Bits can always be set.
  • You can reset bits only by specifying a special security key.
  • A special key can be obtained only once.
  • Callback function can be set only once or unlimited number using the key.
  
  
• An interface function has been added to kernel32.dll and ntdll.dll to the system call organizing the protection management.

Protection progress:

• In the KiSystemService or the IRP request driver of the network driver, we get a pointer to the PTHREAD structure
• Check the boundaries of the index (in the case of a number in the SDT)
• Check if bit is set or not. If set, return STATUS_ACCESS_DENIED
• If a bit is set and a callback function is specified, then call it. Thus, notifying the process that some thread tried to perform prohibited actions.

I would like to pay special attention to the function of installing protection. Her prototype is seen as:
DWORD QuerySystemSecurity (HANDLE hThread, DWORD Flag, QWORD * Key, VOID * Data);

• hThread - the handle to the thread for which protection is set. Or 0xFFFFFFFF in the case of the current thread.
• Flag - parameters passed or requested:
  
  • Get the key.
  • Set the ban on the function.
  • Set the ban on the list of functions.
  • Set a ban on a group of functions. - for example, working with files or processes.
  • Set the callback function.
  • Remove the ban on the function.
  • Inherit the protection table or not.
  • Deny remove protection even if the key is specified.
  • Deny receipt of the key.
• Key - key address or NULL.
• Data - data depending on Flag.

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

Conclusion

Thanks to one simple function and a slight modification of the kernel, you can get quite flexible and fast protection. The programmer himself will be able to prohibit abnormal actions to his programs. Which 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 of programs would not be interested in such protection, then large ones could easily use it to strengthen the protection of their programs from the intervention of other people's code.

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

But as always, these are just your own dreams of the existence of protection, which Microsoft will hardly realize.