Turkish Journal of Physiotherapy and Rehabilitation; 32(3) ISSN 2651-4451 | e-ISSN 2651-446X
SECURITY FLAWS IN MAINSTREAM LINUX DISTRIBUTIONS
Shubham Saini1, Devansh Patel2, G.K. Sandhia3 1School of Computing, SRMIST Chennai 2School of Computing, SRMIST Chennai 3Assistant Professor, School of Computing, SRMIST Chennai
ABSTRACT:
This paper aims to analyze the research that has been done in the field of Operating Systems and the software used by them. Recently Linux has started to play a pivotal role in regular operating systems, so security is the main concerning factor based on the large market share of different distributions of linux. In this paper, comparisons have been made between OpenSSL with LibreSSL, systemD with other init systems, musl with glibc and Xorg with Wayland.
I. INTRODUCTION: Linux is a UNIX like operating system . Actually, linux is a kernel but people confuse it as an operating system. A Finnish-American software engineer named Linus Torvalds, released the kernel on 5 October 1991. Being written from scratch, it does not contain any legacy code. A model of free and open source software is used and then packaged into an operating system which usually contains an init system, linux kernel, coreutils etc. The source code can be distributed, used and modified as the kernel is released under GPL license. Some of the popular Linux distributions include Fedora, Ubuntu, Linux Mint, Debian, Red Hat, Arch Linux, and SUSE Linux organization server.
Many Linux distributions are called “Distros” in short. Distributions use a package manager such as apt, zipper, yum, portage or pacman to install, modify and remove all of the system's software from one location.
As many systems run linux as their daily driver, it becomes very important to secure it properly. With a market share of nearly 37% and it’s usage in large businesses, linux has been widely used worldwide. Most of the time, people are using mainstream distributions of linux like Ubuntu, Arch, Fedora, RedHat etc. In this paper, we’re going to demonstrate how that can be insecure and bad for your business. In this paper, a clear comparison and security standards have been made between the code present in mainstream distributions with those of open source alternatives present.
II. COMPARISON OF OPENSSL WITH LIBRESSL 2.1 What is LibreSSL? LibreSSL is a fork of openSSL 1.0.1g by OpenBSD. It is an open-source implementation of the transport layer security (TLS) and many newer features added since the fork. It is generally the crypto stack which is responsible for handling secure communications against eavesdropping or need to identify the party at the other end over computer networks. It is widely used in web servers and most of the HTTPS websites. After the HeartBleed vulnerability, the OpenBSD team decided to audit the source code of OpenSSL and decided to fork it to remove dangerous code.
2.2 Why is LibreSSL more secure? As of November 2020, OpenSSL has 664,111 lines of code whereas 377,749 lines of code. More lines of code means that your code is more prone to bugs and vulnerabilities. If you provide a lawyer with a document which contains 500 lines and another document with 1000 lines, the lawyer will be able to find more legal flaws in the latter one. This is evident because since its release OpenSSL has 203 vulnerabilities and LibreSSL has only 7. Moreover there was no high risk CVE (Common Vulnerability Exposure)in LibreSSL. www.turkjphysiotherrehabil.org 3272
Turkish Journal of Physiotherapy and Rehabilitation; 32(3) ISSN 2651-4451 | e-ISSN 2651-446X
2.3 LibTLS LibreSSL uses libtls which is a new API to replace the OpenSSL compatible API’s that are in use today. OpenSSL API is very complex and difficult to use. The OpenSSL application is unsuitable for production use. On the other hand, libtls is designed to make easier more foolproof applications. Libtls is more secure, not only that, it is also legacy compatible.
TLS connections made with libtls uses a set of functions throughout their life cycle. tls_init() tls_config_set() tls_configure() tls_server() or tls_client() tls_server() or tls_client() tls_accept() or tls_connect() tls_handshake() tls_read() and tls_write() tls_close() tls_free()
The Traditional OpenSSL API does not follow semantics of read() and write(). Also, it can do strange things like connect to a different daemon when you do a read or write or block on a descriptor (/dev/Xrandom).
You can easily convert an existing program to use TLS if the semantics are similar. But we can’t use the same semantics, these are not single system calls. The goal of LibreSSL is to make read() and write() similar to tls_read() and tls_write() can use it with a minimum of fuss. The loop for tls_write() is similar to write(). The code for tls_write on a blocking file descriptor is as follows: while (len >0){ ssize_t ret; ret = tls_write(ctx, buf, len); if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT) continue; if (ret<0){ if (errno == EAGAIN || errno ==EINTR) continue; err(1, “write: %s”, tls_error(ctx)); } buf +=ret; len -=ret; }
Similar semantics are used in Libtls to maintain coherence. At this stage, tls_read() and tls_write() free the global errno variable to prevent callers from abusing the error conditions. To get an error message on failure, Libtls provides tls_error().
2.4 Removed redundant code The libreSSL fork removed 90,000 lines of code from the openSSL code base. It also split out non-crypto things from libcrypto. And make it independent from the libreSSL code by splitting it from its code base.
III. COMPARISON OF SYSTEMD WITH OTHER INIT SYSTEMS 3.1 What is an init system? A computer’s startup or boot process begins with the BIOS. After completing hardware initializations and checks, the BIOS starts the bootloader. The bootloader accesses the MBR(master boot record) or UEFI(Unified Extensible Firmware Interface) on your storage device. It uses the data in the drive and starts the kernel. Then, the kernel loads into memory, decompresses itself and initializes. After kernel loads, a temporary file system is created in RAM by a utility known as initramfs. This allows the required drivers to be initialized and loaded. Also, allows the userspace www.turkjphysiotherrehabil.org 3273
Turkish Journal of Physiotherapy and Rehabilitation; 32(3) ISSN 2651-4451 | e-ISSN 2651-446X file system to load and prepare the environment. An init system is the first process started after the kernel. It handles the creation of the user-space environment and gets PID 1 on the system. The init process is always executed by the kernel after the early stages of bootup are completed by the BIOS and bootloader.
3.2 A project that doesn’t follow philosophy of UNIX Systemd does not follow the Unix philosophy which focuses on making your project simple, short and modular which can be easily maintained by developers other than the creator. This can be seen from the large code base of the project. The whole project consists of 575k lines of code, compared to 16k of openrc, 8.5k of sysvinit and 1.1k of runit. With a massive code base it becomes very difficult for other programmers to maintain it and do security checks. Also a huge code base can lead to breaking the project more often and attack surface is increased manifolds. As linux is a open source project and systemd is maintained by RedHat, the open source community is also becoming centralized because of RedHat alone taking control of the project. Besides, it handle things like device management, power management, mount points, cron, encryption, syslog, network configuration etc. which are responsibilities that exceed those of a simple init system. Also the author of the project has no respect for the IEEE computer society, nor the POSIX standard. In fact, he encouraged developers to ignore POSIX.
3.3 Slow startup times Let’s get more technical and compare it with other init systems present in the market. systemd is much more than an init replacement. It’s a whole suite of software with approximately 70 binaries that handle logging, journaling, daemons, cron jobs and services besides system initialization. This bulk has nothing to do with system initialization. Some of these are systemd-udevd, systemd-logind, systemd-resolvd, systemd-networkd, systemd-tmpfiles, systemd-homed etc. All of these features that systemd provides already existed in linux. To add all of this functionality again just makes your system bloated and increases your attack surface. These bulky services that comes with it lead to a slow startup time. Also some of them are not compatible with other projects like openvpn.
3.4 Binary logging In binary logging, the tools used to parse the logs will have to be aware of its format and know how to deal with ways when it can be corrupted. The binary logging feature provides faster indexing but binary logs are more easily corrupted. Right now, only journald, with journalctl knows the format of the binary logging structure used by systemd.
3.5 CVEs and issues As of Nov 20, systemd has nearly 59 CVEs registered which is a lot just for an init system. It’s a huge security risk as hackers can use these to take control of the whole operating system. As systemd is assigned PID 1 and is responsible for initializing other daemons and services, a bad actor with proper tools can abuse that to launch malicious services. There are also 1341 open issues on github, where the whole codebase of systemd is present.
3.6 Renaming network interfaces The project shifted more often that it breaks backward compatibility. In systemd version 239, the project named the network interfaces differently that its previous versions. They announced that on their mailing list. This particular version breaks many other things too like blacklist/whitelist have been swapped and support for hibernation is also added, which works completely fine with swap file.
3.7 Dynamic Users This feature has been added between v232 and v235 of systemd. Dynamic user is a system account which is created when the service starts, and is deleted along with all the files owned by that user, when it stops. It claims to solve the problem of a service running as a system user creates a file and packages belonging to that user are removed. This way the file created belongs to the UID of the system user that gets assigned to that user originally. When a next system user is allocated with the same UID because of ID recycling, it will have access to the file of a different service which should not be readable or writable. It solves the problem but introduces many others along the way. It keeps those files under “chmod 0700” root-owned directories. Then if another process has taken previous UID, then they’ll have to do a recursive “chown -R” on your data, so we’ll have to wait for that to complete. Now imagine if that’s a large amount of data or on a slow and read-only media or a remote media like NFS. The service will have to wait for that to complete before starting which can take forever. www.turkjphysiotherrehabil.org 3274
Turkish Journal of Physiotherapy and Rehabilitation; 32(3) ISSN 2651-4451 | e-ISSN 2651-446X
3.8 DNS issues This problem of systemd is related to CVE 2017-15908. According to this CVE, a given DNS response which hasn't been made public will cause systemd to hang entirely. So a complete Denial of Service(DoS) attack can be made to your system. Putting so much arbitrary code into PID 1 is a massive danger. Now, with this huge, monolithic, unwieldy PID1 process taking control of so many existing systems, with the potential for new bugs in any one of them can affect the stability of the entire system.
3.9 After=network.target If we define After=network.target in a Unit file, then systemd will not recognize it. Now, network.target indicates that the network management stack is up after it has been reached. A check to determine whether any network interfaces are configured when it is reached is not defined. The primary purpose of it is to order things at shutdown. As a fix, we have to use both After= and Wants= on the network-online.target
3.10 Does not respect system wide resource limits System wide resource limits are configured in /etc/security/limits.conf and systemd for some reason does not respect that. By using `ulimit -a`, we can check that limits are active. But when running some tasks, nofile and nproc limits were not respected and were sitting at their defaults values. As a fix to this, users have to manually specify the limits in the systemd script by using LimitNOFILE and LimitNPROC variables. Again, this depicts that systemd does not respect the settings of your operating system and takes things into its own hands.
3.11 DNS search domain stays in resolv.conf on network disconnect A system sets search domain name when connected to a wireless network by using DHCP. To be precise, ‘search
3.12 Not so good for your privacy Among a huge list of services available online, google is one of the major contributors of these free services and one of them is google DNS(Domain Name System), popular as 8.8.8.8, 8.8.8.4 for ipv4 and 2001:4860:4860::8888, 2001:4860:4860::8844 for ipv6. Google is nowhere near being a non-profit organization and they collect an immeasurable amount of data about you via their DNS. Nothing is free in the digital world and if something is free, you're paying for it through your data. Now, Google's DNS servers are used by systemd as a fallback when there are no entries for nameservers left in the /etc/resolv.conf file.
IV. GLIBC VS MUSL 4.1 What is musl? musl is an implementation of the standard library functionality in compliance with POSIX standards and ISO C with added extensions and planned to be used for linux-based operating systems. It is responsible for providing actual C function interfaces, userspace allocation and is used in constructing higher-level buffered stdio. Also, it helps in memory allocation, thread creation and sync operations using low level interfaces that the kernel provides. Musl is more of a POSIX and ISO C standard of libc’s that follow the UNIX philosophy. It is simple, lightweight, and aims to comply with standards and provide safety to the users.
4.2 Comparison between two security wise Glibc has 152 CVE entries till Nov 20 while musl has only 8. Also glibc is also known for its huge attack surface. Memory attacks like buffer overflows, ret2libc, heap overflows, shellcode injection, return oriented programming etc. are quite popular for the glibc. Even memory protections are not that useful in front of techniques like return to libc and return oriented programming. Where in musl, these attacks become quite difficult to perform.
www.turkjphysiotherrehabil.org 3275
Turkish Journal of Physiotherapy and Rehabilitation; 32(3) ISSN 2651-4451 | e-ISSN 2651-446X
4.3 stdio implementation in musl In Glibc there is support for incorrect format specifiers. For example, %lld has an alias that is %Ld. There is no support in musl for such alternatives. It also honors rounding mode which glibc does not. POSIX and ISO C require the end of file status for a file to be sticky which is honored by musl while this is not the case with glibc.
4.4 Zeroing memory Musl provides bzero, as well as the non standard explicit_bzero, which is also known as memset_explicit() or memset_s() in other libc to ensure that any password leak or any important secret doesn’t stay in memory.
4.5 Invalid state handling Musl also uses assert, which is a wrapper around __assert_fail to validate assumptions and catch invalid states/violations which results in an immediate halt of the program instead of doing some dangerous calls to parse the callstack and the environment.
V. SECURITY OF DISPLAY SERVER 5.1 What is a display server? Display server is a program which is based on client server model, its role is to coordinate input and output to other clients, operating systems and hardware. The display server uses a display server protocol to communicate. Some examples of display servers are Xorg, wayland, Xvfb, quartz and mir. A display server is one of the most important components of a graphical user interface. It is different from a desktop environment. A desktop environment uses display servers within them.
5.2 Xorg Xorg is a display server that uses the X11 protocol. This X11 is used by the clients to communicate with the X server. Compositor is provides a buffer to render a window.
As it can be seen, even though the X server has given the responsibility to display the final output on the screen to the compositor, the X server still communicates with kernel modesetting and event devices. This is an extra step.
5.3 Wayland In Wayland, the compositor acts as the display server. So, there is no extra step needed to transfer the kernel modesetting and event device information to the server and then to the compositor. It can be done in one step since the compositor and the display server are the same.
www.turkjphysiotherrehabil.org 3276
Turkish Journal of Physiotherapy and Rehabilitation; 32(3) ISSN 2651-4451 | e-ISSN 2651-446X
5.4 Security issues with Xorg Xorg uses X server which communicates with the compositor KMS and event dev, whereas in Wayland the compositor and the display server are the same. Since, Xorg uses another module, the scope where vulnerabilities could be found is increased.
The more important issue with Xorg is that it does not limit the applications to a single window. For example, if there are more than one GUI applications running there is no isolation between them. All the keystrokes can be logged using xinput. What makes it even more dangerous is the fact that xinput does not require root access. In a more secure display server, all the applications should be sandboxed.
VI. CONCLUSION The above studies have been done in through reference to the manuals and CVE documentation. It has come to a depth under-standing of how every Linux based distro functions and also their different flavour. With this document anybody is able to identify the inherent problems with most of the distros currently present.
REFERENCES: 1) Cui-Qing Yang, “Operating System Security and securing linux”, Version 1.4b, Option 1 for GSEC, January 2003. 2) Abhimanyu Sharma, Bhuwan Mukhia, Neha Thapa, Ravi Kr Prasad, Arvind Lal, "A Review on Linux Distribution as Future Operating System", International Journal of Scientific & Engineering Research, Volume 7, Issue 4, April-2016. 3) Sughandh Bhatia, Rajinder S. Virk, “Cloud Computing Security, Privacy And Forensics: Issues And Challenges Ahead”, International Journal of Recent Trends in Engineering and Research, 2018 4) Hacker House, “TheShellCORE- Linux shellcode development”, Exploit Database, EDB ID - 47241 (2019). 5) Peter Troger, Matthias Werner, Jan Richling, “Cyber Physical operating systems – What are the right abstractions”, IEEE, 4th Mediterranean Conference on Embedded Computing (MECO). 6) Ranjit Nimbalkar, Paras Patel, Dr. B. B. Meshram, “Advanced Linux Security”, American Journal of Engineering Research (AJER) Volume-02, Issue- 03, pp-07-12. 7) E. Cozzi, M. Graziano, Y. Fratantonio and D. Balzarotti, "Understanding Linux Malware", 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2018, pp. 161-175. 8) Y. Zhou, K. G. Vamvoudakis, W. M. Haddad and Z. Jiang, "A Secure Control Learning Framework for Cyber-Physical Systems under Sensor Attacks", 2019 American Control Conference (ACC), Philadelphia, PA, USA, 2019, pp. 4280-4285. 9) Kobza, Ladislav & Vojtko, Martin & Krajcovic, Tibor., “Migration of a Modular Operating System to a Intel Atom Processor”, 144-145. 10.1109/ECBS-EERC.2015.33. 10) Irune Agirre. (2020). “Safe and secure software updates on high-performance embedded systems”. Presented at the Dependable Systems and Networks (DSN 2020), Valencia, Spain. 11) Irune Agirre – Safe and secure software updates on high-performance systems (2020)
www.turkjphysiotherrehabil.org 3277