From 5bcc839e2f1e1e51a7a3f325bb10d448267a3cd4 Mon Sep 17 00:00:00 2001 From: Meike Chabowski Date: Tue, 28 May 2024 20:02:16 +0200 Subject: [PATCH] Added content to main document --- xml/MAIN-SBP-SUSE-security-report-2023.xml | 887 +++++++++------------ 1 file changed, 388 insertions(+), 499 deletions(-) diff --git a/xml/MAIN-SBP-SUSE-security-report-2023.xml b/xml/MAIN-SBP-SUSE-security-report-2023.xml index 0e16b282..4a3d67b7 100644 --- a/xml/MAIN-SBP-SUSE-security-report-2023.xml +++ b/xml/MAIN-SBP-SUSE-security-report-2023.xml @@ -94,7 +94,7 @@ - SUSE Solution Security is committed to delivering best in class software security to its + SUSE Solution Security is committed to delivering best-in-class software security to its customers and to the open source community. The primary objectives are to treat software security as an ongoing and continual process. @@ -416,424 +416,407 @@ - - Remote Stack Overflow in the <package>tipc</package> networking module of the Linux - kernel + + CVE-2023-44487: HTTP/2 <emphasis role="bold">Rapid Reset</emphasis> attack Overview - The Transparent Inter Process Communication (TIPC) is an IPC mechanism designed for - intra-cluster communication. It represents the cluster topology using the concept of nodes and - the links between these nodes. A stack overflow flaw was found in the Linux kernel's TIPC - protocol functionality in the way a user sends a packet with malicious content where the number - of domain member nodes is higher than the 64 allowed. This flaw allows a remote user to crash - the system or possibly escalate their privileges if they have access to the TIPC network. - - As part of the monitoring framework the "Overlapping Ring Supervision Algorithm" was - introduced to monitor neighbouring nodes in the cluster. This also introduced a security bug - that could be exploited to execute a remote Denial of Service (DoS) attack on systems using TIPC - and FORTIFY_SOURCE enabled. + In August 2023, Amazon Web Services, Cloudflare and Google noticed a new type of + distributed denial-of-service (DDos) attacks on their networks. These attacks had record breaking sizes, + three times bigger than previous attacks. - Solution - Installing the updated packages provided by SUSE is sufficient to fix the problem. Use the - following command to search for the specific patch: - - zypper lp -a --cve=CVE-2022-0435 - or - zypper patch --cve=CVE-2022-0435 - - to apply the fixes. - After a kernel update a restart is required. Unless you are using the SUSE Linux Enterprise - Live Patching extension, for which SUSE provides the live patch to fix this vulnerability - allowing you to patch the kernel without shutting down your system and reducing the need for - planned downtime and increasing service availability. - - - References - - - - SUSE TID 000020580: - - - SUSE Web page for CVE-2022-0435 : - - - - - - - Dirty Pipe - - Overview - On Monday, March 7th, security researcher Max Kellermann published a new software - vulnerability that affect users of the Linux kernel. The vulnerability, called Dirty Pipe - (CVE-2022-0847), impacts Linux kernels 5.8 and later, and allows local attackers to overwrite - files even if they had only read permissions, allowing for easy privilege escalation. The issue - is triggered by a combination of two bugs, one bug in Linux kernels 4.9 and newer and made - exploitable by the second bug introduced in Linux kernel 5.8. Our currently maintained SUSE - Linux Enterprise products are not affected as they ship older Linux kernels than 5.8. The - upcoming SUSE Linux Enterprise 15 SP4 with Linux kernel 5.14 will be already fixed before - shipment. + As it turned out, the problem that was exploited was not an implementation bug, but an issue + inside the internal design of the HTTP/2 protocol itself. The principle of the + Rapid Reset attack is quite simple. + + With HTTP/1.1, all requests to the server are processed serially on one connection. + The client is sending a request, the server will read and process it and send a response. Then the next request is processed. + The newer HTTP/2 protocol allows multiple bidirectional streams via a single TCP connection. + A client can therefore send several requests at the same time, which are then answered by the server. + This results in a much higher utilization of each connection. + + The Rapid Reset attack now uses the fact that each of those + inner streams can be canceled at any point in time via an RST_STREAM frame. This can be done even before + data has been transmitted back to the client. The problem that arises is as follows: + The request is processed by the server, and for this purposes, resources are allocated per stream. + These resources must be deleted again a moment later when the RST_STREAM frame has arrived. + + This comes at almost no cost for the attacker, but depending on the server implementation, + it can result in significant resource utilization for the victim. Solution - We have released fixes for the first bug for SUSE Linux Enterprise 12 SP4 and newer and - SUSE Linux Enterprise 15 and newer, even though they are not directly affected. To install the - respective patch, use + Several upstream projects updated their code to implement or extent the mitigation mechanisms + that prevent or lower the impact of those attacks. This is usually done by setting a reset rate limit. + + To install the respective patches, use: + + zypper patch --cve=CVE-2023-44487 - zypper patch --cve=CVE-2022-0847 References - SUSE TID 000020603: + SUSE Web page for CVE-2023-44487: - SUSE CVE-2022-0847 Web page: + Google Cloud blog article: - SUSE blog article: + Cloudflare blog article: - Wep page of dirty pipe: + Qualys blog article: - - - Boothole 3 + + CVE-2023-48795: SSH prefix truncation attack (aka Terrapin Attack) Overview - GRUB developers and security researchers have identified more security relevant bugs in - the GRUB2 and shim boot loaders, which could be used by local attackers to - circumvent the secure boot chain. This vulnerability has similar effects and considerations as - the original Boothole and Boothole2 issues. For regular users with their machine under full - control this is less of an issue as in scenarios relying on secure boot, like public - systems. - - Solution - Boothole 3 consists of the following security vulnerabilities: - + Security researchers from the Ruhr University Bochum have published a new attack on + the SSH v2 protocol, which allows active person-in-the-middle attackers to impact SSH connections + by removing initial encrypted SSH packets. + + This can lead to protocol security downgrades or similar problems. + Changing SSH packages or injecting new encrypted SSH packages is not possible with this attack. + + Software on all SUSE Linux Enterprise versions were originally affected. + The problem is inherent to the existing SSH v2 protocol, so new protocol addition(s) and enforcement + of them are needed to avoid the problem. + + The protocol vulnerability needs to be exploited in tandem with specific SSH ciphers. + The chacha20-poly1305 SSH cipher is the one that was shown to be exploitable + most easily, also other ciphers using Encrypt-Then-MAC Message Authentication Codes (MACs) might + be exploitable under certain conditions. + + Note that the ciphers themselves are not problematic. They could lead to exploitable scenarios + only in combination with the SSH v2 protocol weakness. + + Find below a list of SSH v2 implementations that are shipped by SUSE and their exploitability status: + - CVE-2021-3695: A crafted PNG grayscale image may have led to out-of-bounds write in - heap. + openssh: is affected in all shipping versions up to 9.5p1. + All versions of SUSE Linux Enterprise Server are affected. - CVE-2021-3696: A crafted PNG image may have led to out-of-bound write during huffman - table handling. + putty: is affected. It is shipped via SUSE PackageHub 15. - CVE-2021-3697: A crafted JPEG image could have led to buffer underflow write in the - heap. + libssh.org (aka libssh): supports chacha20-poly1305 + since 0.8.0. SUSE Linux Enterprise Server 12 SP5 and SUSE Linux Enterprise Server 15 SP1 and newer are affected. - - - These security issues require attackers to supply crafted images to GRUB2, which is - unlikely in common local scenarios, but can allow bypassing the secure boot chain. - - - CVE-2022-28733: Fixed net/ip to do ip fragment maths safely. If GRUB2 is loading - artefacts from the network, a Man-In-The-Middle attack could be used to execute code. This is - an uncommon scenario. + libssh2.org (aka libssh2_org): does not implement the chacha20-poly1305 + cipher in the newest release 1.11.0. ETM MACs were only implemented in 1.11.0, therefor versions before 1.11.0 + are not affected. SUSE Linux Enterprise Server 12 SP5 and SUSE Linux Enterprise Server 15 come with version 1.11.0 and are + affected by this problem. - CVE-2022-28737: Fixed a buffer overflow in shim. + jsch (Java SSH): chacha20-poly1305 was added with + version 0.1.66, ETM MACs in 0.1.58. Versions from 0.1.58 to current 0.2.9 are considered affected. + SUSE currently does not ship affected versions of jsch. - CVE-2022-28734: Fixed net/http OOB write for split HTTP headers. + proftpd: its mod_sftp module, which is shipped via + SUSE PackageHub 15, is affected. It supports ETM MACs, but not chacha20-poly1305. + The module, however, is not enabled by default. - CVE-2022-28735: GRUB2 verifier framework changes to avoid potential bypasses. - - - CVE-2022-28736: Fixed a use-after-free in chainloader command. + golang.org/x/crypto/ssh: The Golang SSH module is also affected. + The SSH module is used and/or included by a long list of software written in GO.s of an issue, as in scenarios + relying on secure boot, like public systems. + - SUSE is switching to a new secure boot signing key for secure boot signed artefacts. We - have released GRUB2 updates, with incremented SBAT revision on AMD64/Intel 64 and signed with - the new secure boot key to allow disabling it on IBM Z and IBM Power. SUSE also released Linux - kernel updates signed with the new signing key in June 2022 and following days on our regular - second Tuesday of the month kernel release time. In 2022 we released a new - shim version that disallows use of the previous secure boot keys and fixes a - shim security issue, with incremented SBAT version after all the previous - updates. + Solution + The solution is to install respective updates on server and client machines. - References - - - SUSE TID 000020668: - - + openssh updates were provided on December 18th. + Other SSH software was also updated after backporting upstream security fixes. + Note that both SSH clients and servers must be adjusted for the protocol adjustments to be effective. + + Mitigations like removal of ciphers can be done on either side to be effective. + Bacuase rollout may take some time and not all clients are under administrative control, + configuration adjustments such as removing ciphers should be made to avoid using affected ciphers + (see the References section below). - grub2 security issues + References - SUSE CVE-2022-28736 Web page: - - - SUSE CVE-2022-28735 Web page: + SUSE Web page for CVE-2023-48795: - - SUSE CVE-2022-28734 Web page: - - - SUSE CVE-2022-28733 Web page: - - - SUSE CVE-2021-3697 Web page: - - - SUSE CVE-2021-3696 Web page: + + SUSE TID 000021295: - SUSE CVE-2021-3695 Web page: - - - - - shim security issue - - - SUSE CVE-2022-28737 Web page: + Web page: - - Side-channel information leaks / denial of service attack against MMIO registers + + + TTY injection via sudo Overview - Security researchers and Intel engineers have identified several transient execution - side-channel information leak attacks and one denial of service attack when accessing MMIO - registers. + The Linux TTY subsystem allows pushing back keypresses into the TTY stack. + This is a not well-known feature and may lead to unexpected consequences or potential attacks. + As an example, in cases where untrusted code using a command such as sudo + is executed, the untrusted code could push keypresses into the TTY stack, + which could then be executed after the sudo execution completes. + + While sudo is commonly used for transitioning to root + where this would not be an issue, several other sudo scenarios are possible where this could be used to escalate privileges. + The untrusted code would then be able to execute commands as root using this attack. + + To avoid this injection, sudo has the option to create a new + pseudo terminal device (PTY), which is discarded after running sudo, + and would not be affected by this keypress push back attack. However, note that this might impact + terminal output or the use of interactive keys like backspace or delete. - Multiple flavors of these issues have been identified: + Solution + Add the line + +Default use_pty + + to the /etc/sudoers configuration file using the visudo command. + Starting with sudo version 1.9.14p1, this setting is the default for new installations. + References - CVE-2022-21166: Device Register Partial Write (DRPW) Some endpoint MMIO registers - incorrectly handle writes that are smaller than the register size. Instead of aborting the - write or only copying the correct subset of bytes (for example, 2 bytes for a 2-byte write), - more bytes than specified by the write transaction may be written to the register. On some - processors, this may expose stale data from the fill buffers of the core that created the - write transaction. This issue is mitigated using CPU Microcode and Operating System (kernel) - code changes. - - - CVE-2022-21127: Update to Special Register Buffer Data Sampling The RDSAND, RDSEED, SGX - EGET KEY instructions use the low bandwidth MMIO interface, and their content could be sampled - using side-channel information leak methods. This issue is being mitigated with CPU Microcode - updates. - - - CVE-2022-21125: Shared Buffers Data Sampling (SBDS) After propagators may have moved data - around the uncore and copied stale data into client core fill buffers, processors affected by - MFBDS can leak data from the fill buffers. This issue is mitigated using CPU Microcode and - Operating System (kernel) code changes. - - - CVE-2022-21123: Shared Buffers Data Read (SBDR) It is similar to Shared Buffer Data - Sampling (SBDS) except that the data is directly read into the architectural software-visible - state. This issue is mitigated using CPU Microcode and Operating System (kernel) code - changes. - - - CVE-2022-21180: Undefined MMIO Hang While not directly related to side channel - information leaks, overly long MMIO reads to short MMIO registers could lead to machine hangs, - causing a denial of service. This will be fixed by filtering out too long MMIO reads in kernel - / hypervisor software. + SUSE TID 000021241: - - Solution - An updated Intel CPU Microcode was published in the Intel IPU 2022.1 release, released by - SUSE in ucode-intel version 20220510 packages. SUSE released kernel updates - to mitigate the leaks. A new kernel boot command line option has been introduced, called - mmio_stale_data. - - Configuration: - - mmio_stale_data=off - Mitigation is disabled. - - mmio_stale_data=full - Mitigation is enabled, but SMT is still enabled so information might leak on the same CPU - core. - - mmio_stale_data=full,nosmt - Mitigation is enabled, and SMT is disabled so the mitigation is complete. Note that this is - option is also covered by using the generic mitigations option. + - References + + CVE-2022-40982: CPU transient information leakage from GATHER instructions + aka <quote>Gather Data Sampling</quote> aka <quote>DOWNFALL</quote> + Overview + Security researcher Daniel Moghimi has identified a transient information leakage from GATHER + instructions on modern Intel CPUs (Skylake to + Tiger Lake generations). + + This can be used to reveal secret data contained in vector registers, which can essentially + be any information due to the use of these instructions in memory copy operations. + This information leak can cross process and privilege boundaries. + + Solution + Intel has released CPU microcode to mitigate these issues. + The CPU microcode is mandatory for mitigation, the mitigation is enabled by default. + + Updated ucode-intel packages released by SUSE, + version 20230808 or later, contain the mitigations. If there is no CPU Microcode available, + the avx instructions can be hidden from CPUID reporting by the kernel. + + In addition, kernel and XEN changes are being applied to: + - SUSE Technical Information Document (TID) 000020669: + allow disabling the mitigation. - SUSE CVE-2022-21166 Web page: + report affectedness of the CPU and state of the mitigation. + + + SUSE will release kernel and XEN updates. + + Mitigation reporting + + The mitigation state is reported via the sysfs file + /sys/devices/system/cpu/vulnerabilities/gather_data_sampling. + The file can report the following states: + + - SUSE CVE-2022-21127 Web page: + Not affected + This processor is not vulnerable. - SUSE CVE-2022-21123 Web page: + Vulnerable + This processor is is vulnerable and the mitigation is disabled. - SUSE CVE-2022-21125 Web page: + Vulnerable: No microcode + This processor is is vulnerable and the microcode is missing mitigation. - SUSE CVE-2022-21180 Web page: + Mitigation: Microcode + This processor is is vulnerable and the mitigation is in effect. - Article: + Mitigation: Microcode (locked) + This processor is is vulnerable and the mitigation is in effect and cannot be disabled. - Article: + Unknown: Dependent on hypervisor status + Running on a virtual guest processor that is affected but with no way to know + if the host processor is mitigated or vulnerable. This can happen if the hypervisor does not expose + necessary MSR registers to guests. - - - - RETBLEED transient execution information leak side-channel attack + Kernel command line options: + + + gather_data_sampling=off + Switch off this specific mitigation (the default is on). + + + mitigations=off + Switch off all CPU transient execution mitigations, including the gather_data_sampling one. + + + clearcpuid=avx + This option hides the AVX instructions from CPUID flags. Therefore, existing optimized code will not use + AVX instructions, or fallback to other variants, and thus not expose the vulnerability. + + - Overview - Security researchers Johannes Wikner and Kaveh Razavi from ETH Zuerich have identified a - new transient execution information leak caused by return CPU instructions on - Intel and AMD x86 systems. In certain scenarios the return instructions turn to use the indirect - branch predictor, which can be influenced by Branch Target Injection attacks aka Spectre-BTI. - This allows local attackers to execute code to leak sensitive data out of the kernel, same as - other Spectre like vulnerabilities. + Performance considerations + + The mitigation impacts performance of the GATHER parts of the AVX2 and AVX512 instructions, + and potentially operations that are translated within the CPU to use these vector instructions + (for example potentially REP MOVS, or other instruction sets like SSE). + + According to the technical paper linked from the Intel Product Security Center Advisory listed below, + the impact might be as follows: + When the mitigation is enabled, there is additional latency before results of the gather + load can be consumed. Although the performance impact to most workloads is minimal, specific workloads + may show performance impacts of up to 50%. - Affected CPUs: + References - Intel Skylake and newer Intel x86 CPU generations + SUSE Web page for CVE-2022-40982: - AMD Bulldozer (family 0x15) up to Zen 3 + Downfall attacks Web page: - Arm CPUs that are also vulnerable to Spectre variant 2 + Intel Product Security Center Advisory INTEL-SA-00828: - Solution - Various mitigation methods have been implemented and can be selected manually or are - selected automatically. IBPB (Indirect Branch Prediction Barrier) can be used to flush the - indirect branch predictor. This has performance impact, but is the safest option. On Intel - Skylake the IBRS feature is used (Indirect Branch Restricted Speculation), which clears the - branch history buffer from lower privileged entries. Go to the References - paragraph for instructions on each mitigation type. + - References + + CVE-2023-24932: BlackLotus bootkit - + Overview + A UEFI bootkit called BlackLotus has been spotted in the wild, which uses buggy secure boot binaries + to bypass the UEFI secure boot chain. While this component is not shipped by SUSE, to ensure the integrity + of the UEFI secure boot chain, the affected components will need to be excluded from the UEFI secure boot space. + Any UEFI secure boot-enabled installation could be impacted by this vulnerability. + + Solution + You can exclude affected components via a so-called DBX file which blocks UEFI binaries + using signatures/has. DBX file updates can be delivered + and deployed in different ways: + + - SUSE Technical Information Document (TID) 000020693: + Via BIOS or Windows updates + The DBX file can be delivered via BIOS updates. In case of a dual boot system, it is delivered with Windows updates. + If it is installed via BIOS or Windows updates, no additional deployment on Linux is required. - SUSE CVE-2022-29900 Web page: + Via the firmware update tool (fwupd) + Download the current DBX revocation list from https://uefi.org/revocationlistfile for the respective hardware platform. + Use the command fwupdmgr install x64_DBXUpdate.bin and follow the prompts. + This update method only works starting with SUSE Linux Enterprise 15 SP3 based products and newer. + Note: This is a manual deployment and is only required + if there are concerns about UEFI bootkits, as they are not a common attack scenario. + + + References + + - SUSE CVE-2022-29901 Web page: + SUSE Web page for CVE-2023-24932: - SUSE CVE-2022-28693 Web page: + Microsoft Support KB5025885: - SUSE CVE-2022-23825 Web page: + UEFI Revocation List File: + - - <package>openssl 3</package> certificate parsing buffer overflow + + CVE-2023-29552: New SLP based traffic amplification attack Overview - Security researcher Polar Bear has reported a buffer overflow in - openssl when parsing X.509 certificates. This problem could be used by - remote attackers to cause overflows in openssl-based servers parsing, for - example client certificates, or client overflows when parsing server certificates. + Security researchers Pedro Umbelino at Bitsight and Marco Lux at Curesec have published + a new network traffic amplification attack using the Service Location Protocol (SLP, RFC 2608). + This new attack allows for up to 2200x amplification, enabling very effective distributed + denial of service attacks. - This problem only affects openssl 3.x and newer, older - openssl versions are not affected. openssl 3 is only - shipped as a secondary library starting with SUSE Linux Enterprise 15 SP4. No package currently - uses openssl 3. + This flaw is a network protocol design flaw, a software fix is not easily possible. Solution - Patches are available for download and install for SUSE Linux Enterprise 15 SP4. + The SLP protocol IP ports 427, both UDP and TCP, outside of your network boundary + should be blocked or filtered. References - SUSE CVE-2022-3602 Web page: + SUSE Web page for CVE-2023-29552: - SUSE CVE-2022-3786 Web page: - + SUSE TID 000021051: - + - - Vulnerability Management in 2022 + + Vulnerability Management in 2023 The SUSE Solution Security team constantly monitors all the software components used in our - products for security issues. More and improved tools are now available for finding out zero-day - vulnerabilities and scanning for existing vulnerabilities. Such instruments can validate and - report back if the application code written is following the standard security best practices or - there are major gaps in potential attack vectors such as buffer overflow, denial of service or - unwanted elevated access. It is clear that developers are becoming more and more security-aware - and the quality of the code being developed has greatly improved in both quantity and quality. - While we notice an increasing number of important vulnerabilities, the number of critical - vulnerabilities is going down year over year. + products for security issues. More and improved tools are now available to find zero-day vulnerabilities + and scan for existing vulnerabilities. Such tools can check and report whether the application code written + conforms to standard security best practices or whether there are major holes in potential attack vectors + such as buffer overflow, denial of service, or unwanted elevated access. It is clear that developers are + becoming more and more security-aware and that the quality of the code being developed has improved + significantly, both in quantity and quality. While we are seeing an increasing number of important + vulnerabilities, the number of critical vulnerabilities is decreasing year over year. - Vulnerabilities with a unique CVE identified, impacting SUSE products in 2022 + Vulnerabilities with a unique CVE identified, impacting SUSE products in 2023 @@ -845,10 +828,10 @@ - 100 - 637 - 436 - 15 + 123 + 597 + 387 + 9 @@ -856,7 +839,7 @@
- Security updates and patches released to fix these vulnerabilities in 2022 + Security updates and patches released to fix these vulnerabilities in 2023 @@ -868,10 +851,10 @@ - 58 - 584 - 2364 - 101 + 49 + 718 + 2137 + 37 @@ -879,13 +862,13 @@
- Security updates and patches released per month in 2022 + Security updates and patches released per month in 2023 - + - +
@@ -893,223 +876,129 @@ - Secure Software Supply Chain - + Securing the software supply chain + Securing our software supply chain is a top priority for SUSE to protect our customers - security risks, known and zero-day vulnerabilities. Ensuring that no threat actor can inject + from security risks, known and zero-day vulnerabilities. Ensuring that no threat actor can inject malicious code into our build service systems is certified by industry leading security certifications. Our teams continually work to certify all SUSE products, and develop security solutions to offer our customers the highest level of trust and reliability. - A new industry standardization effort named Supply chain Levels for Software Artifacts - (SLSA ), started by Google and driven by several industry stakeholders, aims to protect the - integrity of the software supply chain. SLSA defines four levels of assurance, going from basic - requirements at level 1 to strict rules and documentation requirements at level 4. While the SLSA - standard is still in development, SUSE already considers it as a great representation of needs - for a secure product build environment. Thus we are adjusting our processes and tooling to meet - the requirements of the highest assurance level 4. The main controls which are covering the - highest assurance level 4 for our SUSE Linux Enterprise product offering include: - - - SOURCE CODE MANAGEMENT - Keeping source code integrity is the key aspect of supply chain integrity. Source code - integrity needs to be defended against all threats originating from insider or outsider attacks. - - - - Source threats: Typical source code threats include bad - code that introduces vulnerabilities or a compromised source control system. To address bad - code injection, SLSA mandates two-person reviews. To prevent source code from getting - compromised, SLSA mandates strong measures to secure the source control systems. - - - Build threats Build threats include code commits to - the build that were not tracked by the source control system, a compromised build platform, - bypassing the CI/CD system, a compromised package repository, and injecting bad packages. Most - build threats are mitigated by maintaining a controlled build environment, where each build is - also fully encapsulated on its own, not influenceable from outside, or even reproducible. To - prove this to the outside, detailed provenance data can be generated, which allows for the - external inspection of the builds. Strong security controls ensure that the build platform is - not easily compromised. - - - Dependency threats Dependency threats come into play - where risky dependencies are used. SLSA addresses this kind of threat by mandating provenance - for all artifacts (files, Git commits, directories of files, container images, ...). That way - one would have an indication that this dependency was not built from the proper builder or out - of the designated GitHub repository. - - - - Version-controlled source Our Open Build Service complies - with this requirement as it assigns numeric identifiers to commits. The commit stores - information about the author, the commit time, a comment describing the commit, and other - information. The commit also contains an identification of the source content, like the tree - object in git. - - - Verified revision history: Each commit stores - information about the author and commit time. It also contains a comment describing the commit - and other information. Identities of all actors are verifiable and use two-factor - authentication. - - - Revision and change history are retained indefinitely: - We retain all sources, but also any shipped binary indefinitely. A retraction of a shipped - update from the customer's channels does not lead to its removal from the build system. - Furthermore, all source references and binary shipments including bug tracker references (CVE, - bugzilla) are tracked by the build system for each shipment channel. - - - Two-person reviewed: The workflows for creating a new - product and delivering maintenance updates involve multiple parties, like the core code review - team and the maintenance or product release managers as a minimum. Furthermore, there are - reviews by subject matter experts and additional checks for quality assurance and legal - aspects. These reviews are enforced by the OBS, and a single decline rejects the entire release - process. - - - - - BUILDING AND BUILD SYSTEM - - The next part of the integrity chain is the actual build process that turns sources to - binaries. The entire build process must be secured against any kind of unknown or outside - influence to avoid possible tampering with the builds. Builds must be reproducible to allow - verification and checking of build results. - - - - Scripted build: This is achieved by the SUSE build - script also used by the Open Build Service (OBS). Even the decision to invoke a build is made - by OBS based on the submitted code changes or other builds. - - - Build service: We are running our build service in a - dedicated build cluster within the SUSE data center - - - Build as code: The recipe files defining the build - process are part of the sources of the individual packages, for example the RPM spec file, its - sources and patches, or image and container description files. The build environment - configuration (project config) is also under source control in OBS. - - - Isolated and Ephemeral environment We are using an - isolated KVM instance for each build. Access to the outside is not possible (no network), only - the sources and binaries prepared by OBS can be used. OBS also decides which pieces of the - build artifacts are used. This includes running Linux kernel in the VM. - - - Parameterless: The build happens completely decoupled - from any user interaction. Any parameter must be part of any source submission. No input is - possible during the build, which is ensured by the KVM setup. The only output during the build - is the build log. - - - Hermetic: Our software builds in a KVM guest without - network, and everything required for the build is injected before the build instance is brought - up. - - - Reproducible: Our OBS system tracks all used binaries - for each build and can reproduce the build environment of any released binary. The binaries - used are also referenced in in-toto provenance files and made available together with the - sources starting from SUSE Linux Enterprise 15 SP4 builds. Older builds may have missing - binaries because of the nature of the bootstrapping process. It is notable that the SUSE Linux - Enterprise 15 code base is not enforcing binary identical reproducibility yet. Instead, builds - are compared and known good differences are accepted (for example time stamps or build host - name). This validation is done by the code in the build-compare package. - - - - PROVENANCE - A key aspect of supply chain security is the ability to prove that a build has been - completed / a package built according to all SLSA4-mandated requirements. This provenance is - established by means of providing metadata that proves compliance to SLSA. The SLSA requirements - for provenance include process requirements on provenance generation and consumption, and - requirements on the contents of the provenance. - + + Proactive review of code + + Our skilled team of proactive security engineers regularly reviews the code we ship. + We harden our products and conduct security audits on selected packages. Packages and products + are continually reviewed to ensure we protect our customers' systems with the latest state of the art + technology. To this end, we have introduced an automation setup that notifies our team of + potentially dangerous changes in existing or new packages (for example important permission changes) + and triggers an audit if necessary. + + Over the last year, our proactive Security team has found and assigned CVE IDs to a number + of vulnerabilities which document the more important findings. Find more information on our + blog page. + + + + + + Software Bill of Materials (SBOM) available + + Following recent supply chain attacks and increasing security automation, software inventory + management in particular is becoming increasingly important. Governments and other regulated industries + now require the publication of a so-called Software Bill Of Materials (SBOM) for software products. + + Various SBOM formats have appeared on the market. + SUSE has begun releasing SBOM in the two formats most commonly used by operating system vendors: + SPDX 2.0 and CycloneDX. SPDX 2.0 has even been standardized in ISO/ICE 5962:2021. + + SUSE Linux Enterprise product media: + For our product media (ISO images), the SBOM materials are available from our download Web site + in both SPDX 2.0 and CycloneDX formats. The granularity of this data is currently at RPM level. + + SUSE Linux Enterprise BCI container images: + For our BCI container images, the SBOM data is delivered in the sigstore attestation blob in SPDX 2.0 format. + The data is supposed to be processed automatically, but manual retrieval is also possible. Due to multi-arch + container manifests it is a two step operation. + + Example call: + Use the external crane tool + to extract the x86_64 container part, the cosign tool to retrieve and verify the attestation, + and the jq tool to extract the SPDX 2.0 SBOM data. + + crane digest --platform linux/amd64 registry.suse.com/suse/sle15:15.4 + + Example result: + + sha256:c8aeb5a7662c38716d303fb854c5baa2329afccb4637c0f3c7c44b971181fdbb + + Then run the following on the command line: + + + cosign verify-attestation --type spdxjson –key + /usr/share/pki/containers/suse-container-key.pem + registry.suse.com/suse/sle15@sha256:c8aeb5a7662c38716d303fb854c5baa2329afccb4637c0f3c7c44b971181fdbb | jq '.payload | @base64d | fromjson + | .predicate' + + + + + + Security Information in CSAF format + + The Common Security Advisory Format (CSAF) is an industry-standard format for publishing + security advisories in machine readable form. It is the descendant of the CVRF format and standardized + by the OASIS foundation. + + It differs from the OVAL format, whose goal is to be able to machine-check the health of a system + for security, while the CVRF and CSAF formats are intended for machine import into ticketing systems + and bug trackers to respond to vulnerabilities. + + SUSE currently offers: + - Source threats Available - - - Source threats Authenticated - - - - Source threats Service-generated + CSAF data indexed by Security Advisory in CSAF 2.0 format. - Source threats Non-falsifiable - - - Source threats Dependencies complete + CSAF VEX data indexed by CVE in CSAF 2.0 VEX format. - - SUSE is up to a great start with its effort to attain SLSA L4 compliance, as SLSA - requirements partly overlap with the requirements of Common Criteria EAL4+. This means that - several SLSA criteria were met by SUSE's supply chain processes right from the start. The core - part of this is our certified and proven build and integration process which uses the Open Build - Service technology. Over the past few months, SUSE has been working on improving and tightening - processes and technologies to be able to claim full SLSA L4 compliance. - - For more information on our compliance with the Google SLSA Level 4 requirements, visit: - - - - - - - Adopting Sigstore for our Supply Chain Security - - Sigstore is a recent initiative to enhance signing and cryptographic verification of open - source deliveries. SUSE has adopted additional "cosign" style signing for its published container - images including Base Container Images (BCI) containers. SUSE also started uploading cryptographic - signatures to the global "rekor" transparency log for its containers and product repositories in - February 2022. SUSE Linux Enterprise Base Container Images (SLE BCI) offer a platform for - creating SUSE Linux Enterprise Server-based custom container images and containerized - applications that can be distributed freely. SLE BCIs feature the same predictable enterprise - lifecycle as SUSE Linux Enterprise Server. The SLE_BCI 15 SP3 and SP4 repository (which is a - subset of the SUSE Linux Enterprise repository) gives SLE BCIs access to 4000 packages available - for the AMD64/Intel 64, AArch64, PowerPC, and IBM Z architectures. The packages in the repository - have undergone quality assurance and security audits by SUSE. The container images are - FIPS-compliant when running on a host in FIPS mode. In addition to that, SUSE can provide - official support for SLE BCIs through SUSE subscription plans. - - Security - Each package in the SLE_BCI repository undergoes security - audits, and SLE BCIs benefit from the same mechanism of dealing with CVEs as SUSE Linux - Enterprise Server. All discovered and fixed vulnerabilities are announced via e-mail, the - dedicated CVE pages, and as OVAL and CVRF data. To ensure a secure supply chain, all container - images are signed with Notary v1, Podman’s GPG signatures, and Sigstore Cosign. We have also - implemented support for cosign signatures on a rekor server, so you can also check BCI container - images against rekor, the immutable tamper resistant ledger. All cosign signatures of containers - and generated update repositories (GPG) are uploaded to the Linux Foundation’s rekor transparency - log. - - Stability - Since SLE BCIs are based on SUSE Linux Enterprise Server, they feature the same level of - stability and quality assurance. Similar to SUSE Linux Enterprise Server, SLE BCIs receive - maintenance updates that provide bug fixes, improvements, and security patches. Tooling and - integration SLE BCIs are designed to provide drop-in replacements for popular container images - available on hub.docker.com. You can use the general-purpose SLE BCIs and the tools they put at - your disposal to create custom container images, while the language stack SLE BCIs provide a - foundation and the required tooling for building containerized applications. - - Redistribution - SUSE Linux Enterprise Base Container Images are covered by a permissive EULA that allows you - to redistribute custom container images based on such a SLE BCI. - - + + SUSE has started generating CSAF data for SUSE security update notifications + and CVEs in February 2023, including all previous security advisories and CVEs. + + The CSAF 2.0 security advisory data can be downloaded + from the SUSE ftp site. + The CSAF 2.0 VEX data indexed by CVE can be downloaded + from this SUSE ftp site. + The data is available under the Creative Commons license, with attribution CC-BY-4.0. + The CSAF format is a verbose and simple JSON format, so it can be hooked into other tools pretty + easily even without additional libraries. + + A list of reference tools + is also provided by OASIS. + + + + + Open Source Vulnerabilities (OSV) data + + OSV is a Google-based vulnerability database and triage infrastructure for open source projects + aimed at helping both open source maintainers and consumers of open source. + + SUSE is publishing regularly updated OSV data, which is available in beta status on + . + + + Securing Our Product Portfolio - + + - January 25th 2022 + January 17th 2023 The Defense Information Systems Agency (DISA) has released the Security Content Automation Protocol (SCAP) for the SUSE Linux Enterprise Server 15 Security Technical Implementation Guide