PREVENTING ZERO-DAYS WITH SELinux:

Transcription

1 PREVENTING ZERO-DAYS WITH SELinux: How to Stay One Step Ahead of Malicious Software Attacks JOE MacDONALD, CHIEF ARCHITECT MENTOR EMBEDDED LINUX E M B E D D E D S Y S T E M S W H I T E P A P E R w w w. m e n t o r. c o m

2 INTRODUCTION A while ago I was in a meeting with a potential customer and he had two key messages for me. First, he wanted to switch from some other operating system to Linux for his platform. Second, his customers were concerned about using open platforms due to potential security risks when using source code the whole world can see and modify. I've been in this line of work for quite a while now, and I remember a time when the idea of businesses using Linux was pure fiction. It's not that world anymore. If you're buying a new smartphone this year, a study published from the Gartner Group states that eight of ten consumers will be buying an Android phone. That means consumers are betting their personal data, and in some cases, their personal safety, on some version of Linux. I know all that. My potential customer knows all of that too, or we wouldn't have had that conversation. That doesn't reassure his customers, though, who perhaps, don t realize how trusted, reliable, and frankly ubiquitous Linux has become. I needed to give my potential customer something that he could hold up as an example of how far Linux has come today and that the platform has truly stepped up when it comes to modern security challenges. So I made a bold claim: I said that SELinux, along with a properly configured security policy, delivers a Linuxbased operating system that is capable of protecting itself against so-called Zero-Day attacks. A Zero-Day attack for those of you unfamiliar with the concept, is a security vulnerability not yet known to the operating system authors. These are some of the most sought-after security vulnerabilities within the hacking community. LINUX IN THE EARLY DAYS Most people today have at least a general understanding that Linux is a computer operating system used in a lot of places including desktop and laptop computers. Many probably also know that it has something to do with the UNIX operating system from the 1970s. During my time using Linux as my primary computer operating system, I've seen a significant shift in the user-base to the point where I think it's likely a significant percentage of Linux users don't realize their computer is a multi-user system. Even the most minimal Linux installation is likely to have a dozen or more "users" in the system, most with very specific tasks to perform. Of these, it is likely only two or three users are able to log in, and in most cases, only one will actually connect to the system. One of the main reasons for this has to do with the Linux architecture having its roots in UNIX. The Linux operating system itself mostly doesn't do anything it merely provides and manages resources. Anything active happening in the system is done by users. So a Linux machine that runs a database and a webserver will almost certainly have one user account that runs the database application and another user account for running the webserver. Nobody should ever log into the machine as either the database or webserver user, but those accounts are there all the same. DISCRETIONARY ACCESS CONTROL The beauty of the multi-user approach is the UNIX security model, called Discretionary Access Control (DAC), which allows each of these processes to be protected from one another. This means it is not possible for the webserver application to read or write files that belong to the database without the database application granting permission for the webserver to do so, usually by means of a well-defined and tightly controlled API. That is, access to the components of the system that belong to the database is at the database's discretion. There are several drawbacks to this system, however. For one, the granularity of access in the traditional UNIX DAC model is lacking. Users only had three different settings they could adjust. These include access for the owner; access for all users in the same group as the owner; and access for everyone else. That "everyone else" access is particularly problematic. 2

3 The second problem is a consequence of the first; users are not always the best judge of what should be allowed and to whom. This is made only worse when a user needs to share something with someone, or some process, that doesn't share a group with them. I might, for example, want to provide a Web page that would be available to the webserver. The webserver and I would certainly not be in the same group, so the only option is for the webserver to create a directory where "everyone else" is allowed to create pages (obviously a problem), or I create a page in a directory where "everyone else" is allowed to read it and the webserver has to be configured so everyone knows to look there. Both of these scenarios are not great, but are not critical failures. The critical problem comes when interactive users need access to modify shared system resources such as the files where user passwords are stored. The UNIX DAC model provides no safe way to allow users to update their own passwords without potentially changing passwords for other users as well. On Linux systems, passwords are traditionally stored in files in the /etc directory, named passwd or shadow. The format of these files looks like this: The excerpt above shows a number of users on the current system. The only user in this set with a password, who can log in is jjm. For user jjm to change his password, he will need to be able to re-write this file with a new encrypted password in that field. If he s allowed to write that one line of the file, though, DAC allows him to write any lines of that file and therefore jjm could set a password for root that grants him administrator privileges on the system. The UNIX solution to this problem is only allowing the password file to be readable and writable by the file's owner, typically the root account. This creates a special program named passwd which is then given permission to act as if the root user were running it even when a regular user is actually the one running the program. This program is trusted to ensure that the real user jjm will only update the single line corresponding to his account and no other users. The mechanism that allows the passwd program to perform this action is called Set User ID or SETUID. The SETUID bit is attached to the permissions of certain critical system programs and tells the operating system that whenever those programs run, regardless of what user is running them, they should act as if the owner of the program is running them with all the associated privileges and accesses that user would normally have. MANDATORY ACCESS CONTROL DAC works very well for many use cases. In fact, nearly all desktop Linux installations rely entirely on DAC as the only security model for the system. For the common use case it has been proven over the years to be "good enough." It is clear, though, that DAC is not good enough for some scenarios. As devices become smaller, more spread out, and more connected, device owners have less control and less physical access to them. As a result, these devices are a more appealing target for attackers who could collect personal data, steal information or money, or misuse the devices for other unsavory or illegal purposes. 3

4 This is even more of a concern when considering the possibility of software bugs that may allow otherwise trusted and properly configured applications to perform actions the authors never intended. Consider the case where passwd run by one user to update their own password, but when prompted for a new password, the user inputs a carefully constructed string that exposes a bug in the passwd program. Maybe this bug will overwrite part of the program's executable memory and allow the passwd program to read and write a file other than the password file. If jjm were careful about how he constructed that string he could trick passwd into reading or modifying another user's personal documents. The solution to this problem comes in the form of Mandatory Access Control (MAC). MAC is an additional layer of security on top of DAC that essentially says "Even if DAC would allow the requested access, the program must be acting correctly, any incorrect access will not be allowed." In the above scenario we may have a MAC rule that says the passwd program is allowed to read and write the /etc/passwd and /etc/shadow files. Then the normal operating system behavior can ensure that even if the bug we just described exists, the user jjm cannot use it to access the other user's documents because the passwd program was not given permission to access anything but those two files in the entire system, even when it is running as root. A MORE MODERN APPROACH TO SECURITY - SELinux MAC concepts originate from the early 1980s and have been implemented in a number of different ways in a myriad of computer systems since that time. Security-Enhanced Linux (SELinux) isn't the only form of MAC available in Linux today, but it is the first and arguably the most broadly adopted and supported. One of the most compelling features of SELinux, though, is the code size and the way it implements policy. SELinux is implemented as a very small piece of code called the authorization module. A separate piece of code creates and manages the policy store. The importance of small code cannot be overstated. The larger a piece of software, the more complex it is likely to be and therefore, the more likely there will be bugs either due to human error or design flaws. The SELinux authorization module is sufficiently small and self-contained so that it can be proven correct by Formal Methods. By separating policy from the authorization module the code can remain small and robust while the security policy can be expanded almost infinitely to encompass the most complex systems. The implementation of SELinux policy is beyond the scope of this discussion, but the critical underpinning is that everything (users, files, network connections, etc.) within the system has a security label. The authorization module compares these labels against the policy store. If there is an explicit match in the store for those two labels with the requested access, the access is allowed, otherwise it is denied. Going back very briefly to the password changing, the policy that allows regular users to change their passwords might look something like this: This is a simplified example, but the above illustrates what SELinux policy looks like and how it works. The /etc/ passwd and /etc/shadow files would have a security label that identifies them as passwd_t. The passwd program would have a passwd_exec_t label. The jjm user would have a user_t label. These four rules describe how jjm is allowed to use the passwd program to change their password in the /etc/passwd file. In the absence of any other rules, jjm isn't even allowed to see /etc/passwd in a directory (there is no rule here allowing ls to perform any of the read, getattr actions, etc. on the files with the passwd_t label) and the passwd program isn't allowed access to anything in the system that doesn't have the passwd_t label. 4

5 THE REAL-WORLD ZERO-DAY THAT COULD HAVE BEEN Unfortunately, most security vulnerabilities, and particularly Zero-Days, don't allow for convincing demonstrations. If a proof-of-concept program exists it is frequently complex and requires a number of steps to show it working. In many cases, the exploit itself doesn't immediately crash the system, but rather it grants elevated privileges or discloses sensitive information. These exploits are frequently part of a chain that leads to one of those outcomes. By contrast, a real-world example of something that could easily have been a Zero-Day attack had it not been found first by security researchers is CVE The vulnerability is a typical one, a combination of a use-afterfree bug and a double-free bug that together, allowed an attacker to overwrite part of the kernel memory and thereby gain administrator-level privileges. The error was introduced some time before the Linux release and is speculated to exist from the very first implementation the Datagram Congestion Control Protocol (DCCP). A few days after the initial report a partially reliable proof-of-concept implementation was posted to the OSS-Sec mailing list, including a SMEP/SMAP bypass, allowing an unprivileged user to either crash the kernel or launch an interactive shell with administrator privileges. THE DCCP EXPLOIT IN ACTION As the architect for Mentor s Yocto Project-based Mentor Embedded Linux (MEL) Development Platform, I spend a lot of time using MEL on a wide variety of boards, both with and without official BSPs. As the meta-selinux maintainer for the Yocto Project, I spend a lot of time with the SELinux and Reference Policy tools, trying to figure out how to make things easy for projects to include SELinux. When I knew I was going to use this exploit as my example case, I decided to run it on some extremely low-end hardware. In that way, anyone would be able to easily try it out for themselves. I opened my desk drawer and found a BeagleBone Black. It has the advantage of being cheap, ubiquitous, and while it isn't an officially supported board for MEL, it is well supported in the Yocto project and therefore porting it to MEL was not much work for me. I included our meta-selinux layer and selected the reference policy version, choosing the refpolicyminimum variant. This combination is very specific. I selected it because this version of the policy was obviously written and released more than a year before the vulnerability was known. The variant of the policy is intended to allow user applications to run in the unconfined domain. This means they get to execute as if SELinux were not enforcing policy at all. In fact, I've even questioned how useful this minimum policy really is to anyone, but as I've discovered, and will show here, it is can be surprisingly helpful. Finally, I wrote a recipe to build the proof-of-concept code to include in the filesystem image in one of the regularly labelled standard binary locations on the system. In this case the hackpoc program was installed in /usr/bin. At this point there is nothing unusual about this system. At filesystem commissioning the exploit is already present with sane permissions in a normally trusted location. The active policy is intended to allow user programs to execute with the lightest possible touch. After booting the system, I logged in and added an unprivileged user: 5

6 The partial boot log above shows that SELinux is running in enforcing mode, meaning the minimum policy has been loaded and as with the passwd example previously, only explicitly allowed actions will be permitted. So the next step is simple, log in as the new user and attempt to run the proof-of-concept binary: And this is exactly what we would want to see. In fact, a quick examination of the audit log shows the policy in action: This demonstrates that the hackpoc program is not allowed to create a DCCP socket, which is obviously the key component in the exploit. In fact what this is saying is nobody in the unconfined_t space is allowed to create one. This makes sense. Applications should be allowed to open DCCP connections, but they shouldn't be in the 6

7 unconfined_t space. They should be in something like system_t, where the average user would be able to run them anyway. The question remains, does this exploit work at all with Mentor Embedded Linux? It turns out to be a conditional yes (by conditional, I mean you have to enable a couple of options in the kernel that are not enabled by default and you need to be using a pre-release version that hasn't been audited for security yet, as I am here) and we can prove it by disabling the policy enforcement: 7

8 I significantly shortened the panic and stack trace here because in the scenario, where hackpoc fails to get a root shell, it does manage to crash the entire system in a very dramatic fashion. THE POLICY SOLUTION A perfectly reasonable follow-up question would be "But what if I want to use minimum and still allow regular users to open DCCP sockets?" The answer is easy if you don't want to use minimum any significantly larger policy such as standard already contains the code necessary to ensure that an application using DCCP connections will behave in a non-destructive manner. But it turns out that minimum already has some guards in place as well. The key attribute to look at here is in the exploit code itself: Meaning the exploit looks to run bash to provide the interactive root shell. The security labels of these programs reveal this: So hackpoc is owned by the system_u domain and is in the bin_t type. The bash shell has the same owner domain but has a shell_exec_t type. If we search the running policy for anything that might allow a transition from bin_t to shell_exec_t we find nothing: 8

9 This means that even without any custom policy work at all, the absolute worst thing this exploit can do when enforcing the minimum policy is to crash the system. At no point will it ever be allowed to read other user data and it will never be allowed to execute a shell with administrator privileges. Of course, crashing the system is not desirable, but for an exploit that existed in the wild since perhaps 2005, that could easily allow a local user to have unrestricted access to the entire system, and using a policy that was specifically intended to give interactive users almost unfettered access to the system, you can't beat that level of future-proof protection. MORE THAN JUST THIS ONE EXAMPLE There are many examples of SELinux that show when used with a good policy, you can successfully limit or completely prevent security flaws from ever happening or being exploited. Consider the case of CVE , a kernel keyring bug introduced sometime in early 2013 and identified in January In essence, it is the same sort of issue we've just considered, a double-free, but arguably a more dangerous threat since an attacker could overwrite kernel secrets with arbitrary data including compromised secrets or executable code. This was particularly problematic for Android devices, as many of these devices are not automatically fetching updates and contain vulnerable code. After some quick analysis Google was able to reassure many Android users that they weren't as vulnerable to this attack as the report seemed to indicate. Beginning in Android 5.0 (codenamed Lollipop) Google enabled a critical security feature by default: SEAndroid. SEAndroid is the term Google uses to describe their SELinux policy, which has been carefully crafted to address the specific needs of the Android world. A more recent, high-profile example would be CVE , in which a malicious process inside a container could attack the host if someone on the host were to launch a command shell in the container. A detailed blog post Dan Walsh of Red Hat explains how using a standard or higher security profile would completely prevent many of the avenues an attacking process may be able to use. CONCLUSION Finally, let's have a quick look at CVE , a seven-year-old bug in Samba, which is the Windows interoperability suite. It allowed a remote attacker with access to a writable shared Windows drive to upload a shared library and have the Samba server execute it with the privileges of the Samba server itself, typically an administrator. It's worth noting that this is essentially the same attack vector used by the WannaCry ransomware that was in the news around the same time. In this case, using a properly configured SELinux policy on the Samba server would completely eliminate even the need to apply the security patch. All that would be required to completely protect the server from this vulnerability would be to tailor the security policy to ensure that nothing on shared drives can be in an executable security domain. Using SELinux with one of the policies already provided in either the Reference Policy project or the meta-selinux layer in a Yocto-based distribution (included in Mentor Embedded Linux) provides a great deal of protection for your devices. The real challenge comes from taking a system from the 90 percent coverage of a prepared policy to the 100 percent coverage you need. Creating, modifying, or augmenting SELinux policy is certainly easier now than ever 9

10 but it can still be a challenging task for developers who understand their applications but have little or no experience with security policies. If you search around on the Internet for information on how to create policies, you will invariably encounter a tool I haven't mentioned, audit2allow and the closely associated audit2why. I haven't mentioned them because they are extremely powerful tools and like any powerful tool, they're very easy to misuse. Time and again the recommendation will be to do something akin to "Run the sesearch command to find out why your application can't run in enforcing mode, pipe the output to audit2allow and then use the semodule command to load the new policy." This guidance will certainly result in a new policy module that you can use and make a permanent part of your overall security policy. Your application will run successfully with SELinux enabled, but it's almost certainly not what you want. If we had run audit2allow on hackpoc, the result would have included an allowed transition between bin_t and shell_exec_t; the very thing that ensured our protection even in a system that had userspace DCCP enabled. We would have sabotaged our own system. The best thing you can do for the security of your system is to use a security engine such as SELinux with a policy that has been tailored for your specific use case. That means both understanding what your device and applications must be able to do and creating a security policy that allows only that. The second part is a rare skillset, for certain, but your Linux vendor, Mentor for example, is there to provide you with just that sort of expertise. The combination of a carefully engineered system, SELinux, and the right security policy gives you the assurance your device is protected from a significant number of these Zero-Day exploits yet to come. Visit Mentor s Embedded Linux product page for information on Mentor's complete embedded Linux offering. Author biography: Joe MacDonald is the architect for Mentor s Embedded Linux development platform. He has been working with Linux for more than 20 years in a variety of personal and professional roles. Joe has been developing embedded software and primarily embedded Linux at start-ups, Fortune 500 companies, and for government projects in a mix of networking and security areas. He is the technical board lead for the Carrier Grade Linux working group and the primary maintainer of the meta-networking and meta-selinux layers for OpenEmbedded and the Yocto Project. Joe has a B.S. in Computer Science from the University of New Brunswick and currently resides in Ottawa, Canada. The registered trademark Linux is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis. For the latest product information, call us or visit: w w w. m e n t o r. c o m 2017 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks mentioned in this document are the trademarks of their respective owners. MGC TECH16100-w