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.