Life without SDL. Winter 2017

Introduction, disclaimer or why this article

This article is presented with the aim of encouraging anyone who is in any way connected with the development to pay more attention to security, and we have tried to do this in the most obvious way possible. The article does not claim to be an independent study.

The first attempt to form a problem was presented at the final stage of the M * CTF at the MTUCI Congress Center. On the day of the lectures , the report “Life without SDL. Autumn 2016 ”, covering a detailed analysis of the DOM XSS on WIX.COM and Cryptsetup Initrd root Shell in modern distributions. The last case we reviewed at a recent webinar.
')
The report received public approval and smoothly moved into a dialogue about existing problems and how to solve them. This inspired us to create a series of articles on the most interesting and illustrative cases, emphasizing the relevance of the topic touched.

Short review

The article describes how life goes by without the practice of secure software development (SDL).

The following vulnerabilities were considered as material for analysis:

1. Vulnerability CVE-2017-6074: DCCP in the Linux kernel
2. Fsquirt vulnerability in Windows 7/8 / 8.1

Consider each of them.

Vulnerability CVE-2017-6074: DCCP in the Linux kernel

Description and analysis

Recently, Andrei Konovalov uncovered a vulnerability CVE-2017-6074, which he found in the Linux kernel code affecting the little-known transport layer protocol DCCP. This vulnerability is related to the “double free memory” error class. The researcher showed that under certain conditions, some pointer to the memory area is released twice.

To conduct an attack, the core of the system must be assembled with the condition "CONFIG_IP_DCCP". Opinions of people discussing the problem are divided: some claim that this option is enabled by default in many modern distributions, while others say that DCCP support is turned off in most Linux implementations (Red Hat representatives stated that checking the archive of the technical support service didn’t reveal any case of active dccp clients). It should be noted that DCCP is not forgotten and even met not so long ago on EKOPARTY CTF.

In this article, we are more interested in the cause of the occurrence and the fact that this kind of vulnerability was quite long in the system (from version 2.6.14 to October 2005 and up to release 4.9.11.). Let's analyze the cause of the problems and think about how to ensure that they do not lead to very serious consequences.



Dynamic memory allocation functions allocate memory whose size is indicated by the programmer. When freeing memory, the size is not required. This is achieved due to the fact that the size of the allocated memory is stored close to the unit itself. Thus, when calling the release of memory, it is clear how many bytes must be marked as available.

Since the block is marked as free, the subsequent operation of the software can change the contents of the memory at this address. The second free memory call will try to interpret the data that is recorded as the size of the memory being freed. It is this action that can lead to potentially undesirable consequences - a software crash (for example, due to the fact that the memory release function may try to mark “all” of the available memory as free, because where there was a size before, it turned out to be 0xffffffff ), or even the execution of third-party code.

It is an example when Andrew can demonstrate the execution of third-party code. Schematically, it indicates the following order of function calls:

 kfree(pointer) . . . some_object = kmalloc() . . . kfree(pointer) 

First, the memory is released to the address pointer , then a call is made to allocate a new memory region. Potentially, it can happen that the same area of ​​memory will be allocated that it was freed before. It turns out that pointer and some_object point to the same address.

Recalling the release will cause the memory at the pointer address to be marked as free, but it will be assumed that some_object points to the correct memory location, which is wrong. So the double free memory vulnerability has become “memory use after free” some_object code will use the some_object pointer without considering that it was released.

The researcher showed that, using special techniques, you can try to write down any special values ​​at this address, which later leads to the execution of third-party code.

Later, Andrew laid out the evidence , which includes a SMEP / SMAP bypass. Andrey emphasizes that his PoC is unstable, but nevertheless the very possibility of exploitation is present.

Impact assessment

Although this vulnerability requires local access, it is still quite dangerous and can lead to:

• Unauthorized disclosure:
  
  • in memory there can be a pointer to anything;
• Unauthorized modification information:
  
  • use of previously freed memory may damage actual data if the memory area has been allocated and used properly elsewhere;
• Service access violation:
  
  • if chunk consolidation occurs after using previously released data, then a failure may occur if an invalid chunk is used as fragment information;
• Execution of unauthorized code:
  
  • double freeing of memory can lead to the fact that the “Write-what-where” primitive will allow an attacker to execute arbitrary code.

We use the practice of secure software development (SDL)

Consider this situation from the outside, as if the SDL was used in the development. The following phases are well suited for solving this problem at first glance:

• Design / Design:
  
  • In the general case of this class of errors in the design, select a language that provides automatic memory management. If the language is already defined, then discuss in advance the rules for managing the memory to eliminate this at the design level;
• Implementation / Implementation:
  
  • Use preset memory management rules. Control that the memory is released only once;
  • after freeing the memory, set the pointer to this memory to NULL so that the pointer cannot be released again;
  • if an object-oriented language is used, then make sure that object destructors only delete each chunk of memory once;
  • Use static analysis tools to find double-free chunks of code. Within the framework of this vulnerability, this is a rather problematic task due to the complexity of the project;
• Verification / Verification:
  
  • dynamic analysis. The use of verification at runtime (Runtime Verification) software allows you to check its functionality using tools that monitor the behavior of the application in cases of memory corruption, problems with user privileges and other critical security problems;
  • fuzzing The use of deliberate input of deliberately distorted or random data in the application helps to identify potential problems, and at the same time requiring relatively small costs. Andrew was able to detect this vulnerability with the help of the syzkaller utility, which in turn is a system call fuser for Linux.

How to fix it

One option is to disable DCCP:

 # echo "install dccp /bin/true" >> /etc/modprobe.d/disable-dccp.conf 

Linux distributions developers have already released updates and fixed everything. This patch fixes bugs:

Fsquirt vulnerability in Windows 7/8 / 8.1

Description and analysis

If the previous vulnerability had an identifier in CVE, then this vulnerability is not so simple. For a complete understanding of the situation, let us dwell on the history of its discovery and tell about one interesting case from the life of our company.

The work of the researcher includes a certain set of tasks, one of which is the study of software for the impact of third-party components. One of the tools of the researcher in such types of work is the utility “Process Monitor” from the “SysInternals” Mark Russinovich. It allows you to track the work of various applications with the file system, registry, network and many other events. One of the great features of the utility is tracking activity at boot time. Just when analyzing such an event log, a strange activity was discovered, which our researcher noticed:



Explorer.exe tries to access a file with a nontrivial name "fsquirt.exe", and it searches for it in very unusual places. If you look closely at the ways in which an attempt is made to access the file, it becomes clear that these are the paths from the active user's PATH environment.

First, we turned to Google, which helpfully suggested to us that the file “fsquirt.exe” is most often located in “ C:\Windows\System32\ ” and is part of the Bluetooth subsystem. Learn more about "fsquirt.exe" on the Microsoft website.

Since the file search goes in folders from the variable PATH environment, this means that the specified file was not found in its standard location, and the OS continued searching the paths from the PATH . We thought that if we place the file in such a way, it will be launched. Practice has shown that we were not mistaken.

Since the study was not conducted on a clean stand, there was still some chance that these actions were introduced by third-party software. Therefore, we tested the hypothesis on freshly installed versions of the OS.

The result: Windows 7, Windows 8 and Windows 8.1 download “fsquirt.exe”, Windows 10 does not.

In Windows 7, Windows 8 and Windows 8.1 (but not Windows 10), during the operating system boot (after the user has logged in), the explorer.exe process searches for and starts the fsquirt.exe application. Start is made with the rights of the user, escalation of privileges is absent. The application is searched for in places controlled by the user, since it can change its value in the PATH environment variable.

Example of operation:

A potentially malicious application can create a folder along the path “ C:\SpecialDirFromPath ” and change the PATH environment variable for the current user by adding the created directory to the list. Then in this folder there is a file "fsquirt.exe" with "load".

In the example, this is just a console application with text and waiting for input:

Impact assessment

Despite the fact that this vulnerability does not allow elevating rights in the OS, it is still quite dangerous. First of all, it is the ability of the user (or potentially malicious application with user rights) to create a situation in which arbitrary code will be executed when the OS boots. To implement, you need to add the path to the application to the PATH user environment variable and name the application “fsquirt.exe”.

It will be rather difficult to detect such an autostart, since it does not use any standard mechanism for this (registry, tasks, or special directories of the “Autostart” type).

When using a multistage launch (when “fsquirt.exe” launches “Appendix A”, it will launch “Appendix B”, and then, in turn, will launch “Appendix C”, and so on) even the behavioral analysis from anti-virus products may be will not track the cause of the start of activity or, at least, there will be difficulties.

We use the practice of secure software development (SDL)

In this part of the article, in order to solve the current problem, I would like to touch upon not the general phases, but specific practices:

• Definition of information security requirements;

• Analysis / reduction of the attack surface;

• Testing / security testing of third-party components.

The problem is more organizational. Indeed, from the point of view of functioning, everything works as expected, but organizationally it is not defined: right or wrong. It is possible that in this example it is logical to combine the “definition of IS requirements” and “Analysis / reduction of the attack surface”, since here it is strongly interrelated.

For example, a huge number of requirements are applied to drivers in the same Windows so that they do not violate the overall level of OS security. Conventionally, to start the driver, you need to write a large amount of various information into the registry, put it on the desired path, sign the file with a digital signature. There is such a “small” list of actions, and for a normal start of software there are not so many requirements.

How to fix it

To protect yourself from such an attack, you should take an empty executable file that does nothing and place it along the path “ C:\Windows\system32\fsquirt.exe ”. In this case, this application will be launched, and no other execution path will be searched. In Windows 10, this file is available.

Conclusion

This article is a story about a small part of the security problems encountered in software development. I wanted to demonstrate in practice the importance of the SDL secure development cycle. I hope that this article will in the worst case prove to be a little useful for you, and at best it will become an impulse to action. Vulnerability in software is unpleasant, dangerous, and sometimes very expensive. The main thing is to correct the errors in time, and the SDL is the tool that will help reduce the number of such emergency corrections.

I also want to express my deep gratitude to my colleague Vasiliy Kravets xi-tauw for the fact that thanks to his attention in the study, I had a fresh example for the article. Also, thanks for the review, inaccuracies and helpful suggestions.