{"id":29880,"date":"2019-10-31T21:32:27","date_gmt":"2019-10-31T18:32:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux\/"},"modified":"2019-10-31T21:32:27","modified_gmt":"2019-10-31T18:32:27","slug":"milliony-binarnikov-spustya-kak-ukreplyalsya-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Millions of binaries later. How Linux has strengthened","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MillionsTL;DR<\/b>In this article, we explore hardening schemes that work out of the box in five popular Linux distributions. For each, we took the default kernel configuration, loaded all packages, and analyzed the protection schemes in nested binaries. The distributions considered are OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 and 7, as well as Ubuntu 14.04, 12.04, and 18.04 LTS. <\/p>\n

The results confirm that even basic schemes, such as stack canaries and position-independent code, are still not widely used. The situation is even worse for compilers when it comes to protection against vulnerabilities like stack clash, which gained attention in January after the disclosure of vulnerabilities in systemd.<\/a><\/noindex>However, not everything is hopeless. A significant portion of binaries implement basic protection methods, and their number is increasing with each version. <\/p>\n

The assessment showed that the highest number of protection methods is implemented in Ubuntu 18.04 at the OS and application levels, followed by Debian 9. On the other hand, OpenSUSE 12.4, CentOS 7, and RHEL 7 also implement basic protection schemes, with stack clash protection being applied even more broadly with a much denser default package set.
\n<\/a><\/noindex><\/p>\n

Introduction<\/h1>\n

\nEnsuring high software quality is challenging. Despite the vast array of advanced tools for static code analysis and dynamic runtime analysis, as well as significant progress in compiler and programming language development, modern software still suffers from vulnerabilities that are constantly exploited by malicious actors. The situation is exacerbated in ecosystems that include legacy code. In such cases, we not only face the perennial challenge of identifying potential exploitable bugs but are also constrained by rigid backward compatibility requirements that often necessitate retaining outdated, and in worse cases, vulnerable or buggy code.<\/p>\n

This is where protection or hardening methods come into play. Some types of errors we are unable to prevent, but we can make life harder for attackers and partially address the problem by preventing or obstructing exploitation<\/i> these errors. Such protection is used in all modern operating systems, but the methods vary significantly in complexity, effectiveness, and performance: from stack canaries and ASLR<\/a><\/noindex> to full-fledged protections CFI<\/a><\/noindex> and , Return-Oriented Programming), but uses nonexistent snippets of machine code to build a chain of calls ('gadgets') instead of actual machine code fragments, embedding them in subqueries within SELECT.<\/a><\/noindex>. In this article, we will examine what protection methods are employed in the most popular Linux distributions by default, as well as explore the properties of binaries distributed through the package management systems of each distribution.<\/p>\n

CVE and security<\/h3>\n

\nWe have all seen articles with titles like \"The Most Vulnerable Applications of the Year\" or \"The Most Vulnerable Operating Systems.\" Typically, they present statistics on the total number of records for vulnerabilities of the type CVE (Common Vulnerabilities and Exposures)<\/a><\/noindex>, obtained from the National Vulnerability Database (NVD)<\/a><\/noindex> from NIST<\/a><\/noindex> and other sources. Consequently, these applications or OS are ranked based on the number of CVEs. Unfortunately, while CVEs are very useful for tracking issues and informing vendors and users, they say little about the actual security of the software.<\/p>\n

For example, let\u2019s look at the total number of CVEs over the past four years for the Linux kernel and the five most popular server distributions, namely Ubuntu, Debian, Red Hat Enterprise Linux, and OpenSUSE.<\/p>\n

\"Millions
\nFigure 1<\/i><\/p>\n

What does this graph tell us? Does a higher number of CVEs mean that one distribution is more vulnerable than another? The answer is no. For instance, in this article, you will see that Debian implements stricter security mechanisms compared to OpenSUSE or Red Hat Linux, yet Debian has more CVEs. However, this does not necessarily mean weakened security: the presence of CVEs does not indicate whether a vulnerability is exploitable<\/i>. Severity scores provide insight into how likely it is that a vulnerability will be exploited, but ultimately exploitability largely depends on the defenses present in the affected systems, as well as the resources and capabilities of malicious actors. Moreover, the absence of CVE reports does not indicate anything about other unregistered or unknown<\/i> vulnerabilities. unregistered or unknown<\/i> vulnerabilities. The difference in CVE may be explained not by the quality of the software but by other factors, including the resources allocated for testing or the size of the user base. In our example, a higher number of CVE for Debian may simply indicate that Debian provides more software packages. <\/p>\n

Of course, the CVE system provides useful information that allows for creating appropriate defenses. The better we understand the reasons for program failures, the easier it is to identify potential exploitation methods and develop corresponding mechanisms. detection and response<\/i>. Figure 2 shows categories of vulnerabilities for all distributions over the past four years (source<\/a><\/noindex>). It is immediately clear that most CVEs fall into the following categories: denial of service (DoS), code execution, overflow, memory corruption, information leakage (exfiltration), and privilege escalation. Although many CVEs are counted multiple times in different categories, the same issues persist year after year. In the next part of the article, we will evaluate the use of various protection schemes to prevent the exploitation of the specified vulnerabilities.<\/p>\n

\"Millions
\nFigure 2<\/i><\/p>\n

Since I have already learned to \"somewhat\" port QEMU to JavaScript, this time it was decided to do it wisely and not repeat past mistakes.<\/h3>\n

\nIn this article, we intend to answer the following questions:<\/p>\n