A critical vulnerability in sshd(8) was present in Portable OpenSSH versions 8.5p1 [to] 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges.
+
Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.
Instead of linking against libsystemd, load it dynamically in a temporary child process to avoid polluting actual sshd's address space with that library and its many dependencies (shortens ldd sshd output from 28 to 20 lines)
Build without Kerberos support (further shortens ldd sshd from 20 to 13 lines)
The Security SIG repositories provide extra security-related packages and security-hardened override packages (replacing those from the main distribution) for Rocky Linux and other Enterprise Linux (EL) distributions.
If you've been to this wiki before, you'll likely want to check out what's new.
Developing and maintaining various security related packages that are not in upstream EL. Identifying, developing, and maintaining security hardening changes relative to upstream EL packages. Occasionally including/backporting additional security fixes that are not yet in upstream EL packages. Contributing to the respective upstreams where practical.
"},{"location":"#on-another-compatible-el-distro","title":"On another compatible EL distro","text":"
Download the release package containing our repository configuration file and package signing public key. Use the version that corresponds to the major version of your EL distro.
rocky-release-security-9
rocky-release-security-8
Verify the package file's SHA-256 digest with sha256sum. The currently expected digests are:
This isn't as secure as checking the package signature would be if you previously had our package signing public key, but on another distro you probably don't have that yet, so checking the digest against its copy obtained from this separate website is a best-effort measure.
"},{"location":"#packages","title":"Packages","text":""},{"location":"#extra-packages-for-el8-and-el9","title":"Extra packages (for EL8 and EL9)","text":"
lkrg (Linux Kernel Runtime Guard)
passwdqc (password/passphrase strength checking and policy enforcement)
"},{"location":"#extra-packages-currently-only-for-el9","title":"Extra packages (currently only for EL9)","text":"
control (a common interface to register and control security-relevant system facilities)
hardened_malloc (security-focused memory allocator providing the malloc API, and a script to preload it into existing program binaries)
"},{"location":"#override-packages-for-el8-and-el9","title":"Override packages (for EL8 and EL9)","text":"
microcode_ctl (updates Intel CPU microcode to fix CVE-2023-23583)
"},{"location":"#override-packages-currently-only-for-el9","title":"Override packages (currently only for EL9)","text":"
glibc (adds many security-hardening changes originating from Owl and ALT Linux on top of EL package)
openssh (fewer shared libraries exposed in sshd processes while otherwise fully matching EL package's functionality)
The changes are described in more detail on the per-package wiki pages linked above, as well as in the package changelogs. More packages/changes are planned, including override packages also for EL8.
Just like for other Rocky Linux SIGs, the source trees for Security SIG packages are maintained in per-package git repositories. Each repository contains branches r8 and/or r9 corresponding to target EL version.
If anyone else wants to join this effort - in any capacity including development, maintenance, testing, documentation, user support, spreading the word, or something else - please join the Mattermost channel below and let us know!
We also welcome well-reasoned suggestions/feedback/preferences on direction we should take (e.g., only making changes on top of EL's vs. offering newer upstream versions), what else to package, and what other changes to include.
Some of the people active with setting up this SIG so far:
Name Mattermost Name @flawedworld Fredrik Nystr\u00f6m @nscfreny Louis Abel @label Mustafa @mustafa Neil Hanlon @neil Scott Shinn @atomicturtle Solar Designer @solardiz"},{"location":"news/","title":"News","text":"
These are what we consider significant SIG/Security news items, not an exhaustive list of package updates and wiki edits.
lkrg 0.9.8-2.el8_10.security is a rebuild of Linux Kernel Runtime Guard for EL 8.10, which wasn't strictly necessary this time as our build for 8.9 also remained working on 8.10 as-is.
glibc 2.34-100.el9_4.security.0.8 contains all of our changes so far rebased on top of 9.4's 2.34-100, which was still missing the iconv and nscd security fixes, so our addition of those is still relevant.
openssh rebased on 9.4's 8.7p1-38.
The status page on CVE-2024-1086 has been updated to refer to EL9 fix.
Our hardened EL9 glibc updated to include glibc upstream fix for CVE-2024-2961. On that CVE status page, we also provide a mitigation for both EL9 and EL8.
The status page on CVE-2024-1086 has been updated to refer to EL8 fix and errata, suggest disabling network namespaces, explain remaining risks with LKRG.
We've just set up a status page on CVE-2024-1086, currently listing two mitigations for this Linux kernel vulnerability.
"},{"location":"news/#march-11-to-16-2024","title":"March 11 to 16, 2024","text":"
openssh rebased on upstream EL 8.7p1-34.3 with fixes for CVE-2023-48795 (Terrapin attack) and CVE-2023-51385, now building it without Kerberos support (further shortens ldd sshd from 20 to 13 lines, down from 28 lines in upstream EL).
This SIG/Security News wiki page has been created, retroactively identifying and listing selected news items so far.
control 0.8.0-4 can now manage 3 privileged programs from util-linux (and util-linux-core): mount, umount (one \"facility\" for both), and write. Its wiki page has been reworked.
control wiki page added, documenting the new package.
control provides a common interface to register and control (what it calls) system facilities. This is intended primarily for facilities that can potentially be dangerous to system security, to let you enable, disable, or configure each facility. A typical facility is a SUID/SGID/setcap program or a configuration setting of a service.
Included initially are facility specifications corresponding to the shadow-utils package. Currently, these allow to control access to 5 privileged programs - 3 of them (chage, gpasswd, and newgrp) are by default SUID root and 2 (newuidmap and newgidmap) are cap_setuid=ep.
Everything we had so far has been updated for EL 9.3 and 8.9, including our hardened EL9 glibc and openssh packages rebased on 9.3's and lkrg rebuilt for 9.3's and 8.9's kernels, along with re-testing and wiki edits.
The rocky-release-security package containing our repository configuration has been made (a while earlier) easier to use on EL distros other than Rocky Linux, and we've now updated the wiki accordingly.
"},{"location":"news/#november-16-to-19-2023","title":"November 16 to 19, 2023","text":"
microcode_ctl also for EL8, providing 8.9's Intel CPU microcode to fix CVE-2023-23583 a few days before general availability of our own 8.9 release as a whole.
Wiki pages lkrg and passwdqc have been created. We had these extra packages for a while, but previously only had wiki pages for override packages (referring solely to upstream homepages for the extra packages).
We've started maintaining wiki pages for selected high profile security issues, initially for glibc CVE-2023-4911 and Intel CPU microcode CVE-2023-23583.
microcode_ctl for EL9, providing latest Intel CPU microcode to fix CVE-2023-23583 ahead of availability of a rebuilt new upstream package.
"},{"location":"news/#october-31-to-november-15-2023","title":"October 31 to November 15, 2023","text":"
hardened_malloc package - a security-focused memory allocator providing the malloc(3) API, and a script to preload it into existing program binaries. Its documentation on the wiki.
Initial wiki content documenting what we had so far, which included override packages of glibc and openssh and extra packages of lkrg and passwdqc (even though these per-package wiki pages did not exist yet, so we instead had summaries and external links on the front page only), the repository package, source code repositories, and Mattermost channel.
Under certain microarchitectural conditions, Intel has identified cases where execution of an instruction (REP MOVSB) encoded with a redundant REX prefix may result in unpredictable system behavior resulting in a system crash/hang, or, in some limited scenarios, may allow escalation of privilege from CPL3 to CPL0.
and by Red Hat:
A security vulnerability was found in some Intel processors. Execution of REP MOVSB instructions with a redundant REX prefix may result in execution continuing at an incorrect EIP address after a micro-architectural event occurs, potentially allowing privilege escalation, information disclosure and/or a denial of service via local access.
as well as in CVE-2023-23583.
More detail is available via these links to Intel's website and in the public disclosure by Tavis Ormandy from Google.
A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.
More detail is available in the public disclosure by Qualys, the team who discovered the issue.
A flaw was found in the Netfilter subsystem in the Linux kernel. This issue occurs in the nft_verdict_init() function, allowing positive values as a drop error within the hook verdict, therefore, the nf_hook_slow() function can cause a double-free vulnerability when NF_DROP is issued with a drop error that resembles NF_ACCEPT. The nf_tables component can be exploited to achieve local privilege escalation.
Exploitation of the flaw is described in great detail in a blog post by Notselwyn.
Public disclosure date: March 26, 2024 for the above blog post, which made the issue widely known
This is a mitigation also suggested by Red Hat. It is sufficient to fully mitigate this and other/future related vulnerabilities.
If you cannot disable user namespaces, you may nevertheless be able to disable network namespaces, which is also sufficient to fully mitigate this and some other/future related vulnerabilities.
Install our package of LKRG, start and enable the service.
This does not fully mitigate the vulnerability, but it reliably prevents the specific exploit referenced above from working and produces LKRG alerts when the exploit is run. LKRG's feature that does so is its allow list for the kernel's usermodehelper. This will similarly prevent other/future exploits that abuse usermodehelper. The remaining risks are Denial of Service (DoS) as even interrupted exploits may leave the system in an unstable state, and a different exploit of the same vulnerability bypassing LKRG.
An out-of-bounds write flaw was found in the ISO-2022-CN-EXT plugin for glibc's iconv library. When converting from UCS4 charset, adding certain escape charterers is required to indicate where the charset was changed to the library. During this process, iconv improperly checks the boundaries of internal buffers, leading to a buffer overflow, which allows writing up to 3 bytes outside the desired memory location. This issue may allow an attacker to craft a malicious characters sequence that will trigger the out-of-bounds write and perform remote code execution, presenting a high impact to the Integrity, Confidentiality, and Availability triad.
and as further discussed on oss-security:
On PHP [this glibc bug led] to amazing results: a new exploitation technique that affects the whole PHP ecosystem.
Support for the ISO-2022-CN-EXT character set can be excluded from glibc's iconv(3) by editing /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf to comment out the below 3 lines at line 1254 (same line number in EL9 and EL8) and then regenerating the cache file:
These two steps can be accomplished by running the below commands as root:
sed -i -r 's/^(.*ISO-2022-CN-EXT.*)$/#\\1/' /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf\niconvconfig\n
To make sure this has worked as intended, we also recommend that you run iconv -l | grep ISO-2022-CN-EXT before and after the above procedure. It should list the ISO-2022-CN-EXT character set before the procedure, but produce empty output afterwards.
"},{"location":"issues/CVE-2024-2961/#making-the-fix-or-mitigation-effective","title":"Making the fix or mitigation effective","text":"
After installing a fixed version of glibc or/and applying the mitigation, you'll need to restart any long-running processes for which the bug matters (such as PHP-FPM).
control provides a common interface to register and control (what it calls) system facilities. This is intended primarily for facilities that can potentially be dangerous to system security, to let you enable, disable, or configure each facility. A typical facility is a configuration setting of a service or a SUID/SGID/setcap program, or a closely related group of such settings and/or programs that are managed together. We manage permissions on SUID/SGID/setcap programs because those programs pose risk to system security in case of vulnerabilities in them or in library code they use.
control originates in Owl and is actively maintained in ALT Linux.
"},{"location":"packages/control/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
While the original control package in Owl and ALT Linux merely provides the common interface mentioned above for other packages to register their facilities with (and many packages in those distros do), it's been adapted in Rocky Linux to provide its own sub-packages with facility specifications and RPM trigger scripts for other packages coming from EL. This way, we can control those facilities and have custom settings persist (be automatically saved and restored) over package upgrades without us having to maintain forks of those other packages.
The available facilities, their current settings, and lists of possible settings can be queried by running the control command without parameters. With all currently available sub-packages installed and upstream default settings, its output is:
chage public (public restricted)\ngpasswd public (public wheelonly restricted)\nmount public (public wheelonly unprivileged restricted)\nnewgidmap public (public wheelonly restricted)\nnewgrp public (public wheelonly restricted)\nnewuidmap public (public wheelonly restricted)\npam_timestamp_check public (public restricted)\npassword-hash sha512crypt (sha512crypt yescrypt)\npassword-policy pwquality (pwquality passwdqc)\nunix_chkpwd public (public restricted)\nwrite public (public restricted)\n
Facility specifications corresponding to the shadow-utils package. Currently, these allow to control access to 5 privileged programs - 3 of them (chage, gpasswd, and newgrp) are by default SUID root and 2 (newuidmap and newgidmap) are cap_setuid=ep.
Facility specifications corresponding to the util-linux and util-linux-core packages. Currently, these allow to control access to 3 privileged programs - 2 of them (mount and umount) are by default SUID root and 1 (write) SGID tty.
Facility specifications corresponding to the pam package. Currently, these allow to control user password hashing scheme and password policy in use by PAM-aware programs, as well as two SUID root PAM helper programs unix_chkpwd and pam_timestamp_check.
* Wed Jan 3 2024 Solar Designer <solar@openwall.com> 0.8.0-7\n- Add unix_chkpwd and pam_timestamp_check facilities to the pam sub-package\n\n* Wed Jan 3 2024 Solar Designer <solar@openwall.com> 0.8.0-6\n- Revise password-hash and password-policy to process the underlying two\n \"sub-facilities\" (for the two configuration files updated by each of these)\n using the same logic that we had used for mount (where the two underlying\n \"sub-facilities\" are the mount and umount programs)\n\n* Wed Dec 27 2023 Solar Designer <solar@openwall.com> 0.8.0-5\n- Install control(8) mode 755 since some of its features work as non-root\n- Add sub-package with facilities and triggers for pam password hashing and\n password policy\n\n* Mon Dec 18 2023 Solar Designer <solar@openwall.com> 0.8.0-4\n- Add sub-package with facilities and triggers for util-linux\n\n* Mon Dec 18 2023 Solar Designer <solar@openwall.com> 0.8.0-3\n- Rename the shadow sub-package to shadow-utils\n- Rename the source files not to differentiate them by sub-package\n- Add \"Requires: shadow-utils\" in the shadow-utils sub-package\n\n* Wed Dec 13 2023 Solar Designer <solar@openwall.com> 0.8.0-2\n- In addition to Requires(pre), also use Requires in the sub-package\n- In %triggerprein_control, pre-check that the facility exists\n- Use (renamed) copies of the trigger macros within this spec file\n\n* Wed Dec 13 2023 Solar Designer <solar@openwall.com> 0.8.0-1\n- Add macros for use in RPM triggers\n- Add sub-package with facilities and triggers for shadow-utils\n\n* Wed Dec 6 2023 Solar Designer <solar@openwall.com> 0.8.0-0\n- Initial packaging for EL based on ALT Linux and Owl packages\n
Distrust and/or unset many more environment variables used by current and previous glibc versions when running SUID/SGID/setcap (Owl via ALT Linux)
When syslog(3)/vsyslog(3) is called by a SUID/SGID/setcap program without a preceding call to openlog(3), don't blindly trust __progname for the syslog ident (Owl via ALT Linux, further revised for Rocky Linux)
In syslog(3)/vsyslog(3) use asctime_r(3)+localtime_r(3) instead of strftime_r() so that month names don't depend on current locale settings (Owl via ALT Linux)
In asprintf(3)/vasprintf(3) reset the pointer to NULL on error, like BSDs do, so that the caller wouldn't access memory over an uninitialized or stale pointer (ALT Linux)
In fread(3)/fwrite(3) check for potential integer overflow (ALT Linux)
In tmpfile(3) use the TMPDIR environment variable (when not running SUID/SGID/setcap) (ALT Linux)
When qsort(3) is wrongly used with a nontransitive comparison function, nevertheless be robust and avoid memory corruption (Qualys, Rocky Linux)
"},{"location":"packages/glibc/#known-effective-vulnerability-mitigations-and-fixes","title":"Known-effective vulnerability mitigations and fixes","text":"
2.34-83.12.el9_3.security.0.6 and above includes nscd CVE-2024-33599, CVE-2024-33600, CVE-2024-33601, CVE-2024-33602 fixes from upstream glibc 2.34 branch, which upstream also included starting with 2.34-100.el9_4.2.
2.34-83.12.el9_3.security.0.5 and above includes iconv(3) ISO-2022-CN-EXT CVE-2024-2961 fix from upstream glibc 2.34 branch, which upstream also included starting with 2.34-100.el9_4.2.
2.34-60.el9_2.security.0.2 included mitigations sufficient to avoid security exposure of CVE-2023-4911 and a backport of upstream glibc fix of CVE-2023-4527 that was not yet in upstream EL. In the update to 2.34-60.7.el9_2.security.0.3 and beyond, we retained the mitigations while rebasing on upstream EL's package with upstream fixes for these vulnerabilities (and more).
In general, inclusion of additional security fixes will be \"reverted\" if and when those get included in upstream EL packages that we rebase our changes on.
* Thu Jun 13 2024 Solar Designer <solar@openwall.com> - 2.34-100.2.el9.security.0.9\n- Rebase on 2.34-100.2\n\n[... upstream changes ...]\n\n* Mon May 20 2024 Solar Designer <solar@openwall.com> - 2.34-100.el9.security.0.8\n- Rebase on 2.34-100\n\n* Tue May 07 2024 Solar Designer <solar@openwall.com> - 2.34-83.12.el9.security.0.7\n- Upstream glibc 2.34 fix \"nscd: Use time_t for return type of addgetnetgrentX\"\n\n* Tue Apr 30 2024 Solar Designer <solar@openwall.com> - 2.34-83.12.el9.security.0.6\n- Add nscd CVE-2024-33599, CVE-2024-33600, CVE-2024-33601, CVE-2024-33602 fixes\n from upstream glibc 2.34 branch\n\n* Thu Apr 18 2024 Solar Designer <solar@openwall.com> - 2.34-83.12.el9.security.0.5\n- Rebase on 2.34-83.12\n- Add iconv() ISO-2022-CN-EXT CVE-2024-2961 fix from upstream glibc 2.34 branch\n\n[... upstream changes ...]\n\n* Wed Jan 31 2024 Solar Designer <solar@openwall.com> - 2.34-83.7.el9.security.0.4\n- Harden syslog ident fallback initialization to use at most 64 characters of\n __progname when __libc_enable_secure, as inspired by Qualys' discovery of\n related vulnerabilities in newer glibc (not yet present in this version):\n https://www.openwall.com/lists/oss-security/2024/01/30/6\n- Harden qsort against nontransitive comparison functions as suggested by\n Qualys: https://www.openwall.com/lists/oss-security/2024/01/30/7\n\n* Wed Nov 22 2023 Solar Designer <solar@openwall.com> - 2.34-83.7.el9.security.0.3\n- Rebase on 2.34-83.7, drop \"our\" CVE-2023-4527 patch in favor of RH's\n (a similar rebase was made on Oct 6 in 2.34-60.7.el9.security.0.3 for 9.2)\n\n[... upstream changes ...]\n\n* Mon Oct 2 2023 Solar Designer <solar@openwall.com> - 2.34-60.el9.security.0.2\n- Add glibc-owl-alt-sanitize-env.patch stitched from several ALT Linux commits\n as none of their revisions matched this package's set of backports as-is\n- Add glibc-upstream-no-aaaa-CVE-2023-4527.patch based on upstream commit\n bd77dd7e73e3530203be1c52c8a29d08270cb25d fixing\n CVE-2023-4527: Stack read overflow with large TCP responses in no-aaaa mode\n\n* Tue Sep 26 2023 Solar Designer <solar@openwall.com> - 2.34-60.el9.security.0.1\n- Revise the texinfo documentation edit of glibc-2.34-alt-asprintf.patch via\n glibc-2.34-rocky-asprintf.patch\n\n* Sat Sep 23 2023 Solar Designer <solar@openwall.com> - 2.34-60.el9.security.0.0\n- Add some of the patches from ALT Linux as of when they were at 2.34:\n https://git.altlinux.org/gears/g/glibc.git\n git show 5fa32fb0f8509f4b2b1105d71b45966dfbadc099 > glibc-2.34-alt-tmpfile.patch\n git show f97e5d60a6a4c9cb64e3b9ee6f5113969cf07d87 > glibc-2.34-alt-asprintf.patch\n git show cd45d0f74560325cc48aedb9f56881270ab3dfab > glibc-2.34-alt-libio-bound.patch\n git show 436eb1017c04aee3a553c2868d00a4b046e5e394 > glibc-2.34-owl-alt-syslog-ident.patch\n git show 03a86c234873723c26b7e387c498c1332c223968 > glibc-2.34-mjt-owl-alt-syslog-timestamp.patch\n
This package ships the \"normal\" and \"light\" configurations of the GrapheneOS hardened_malloc project. The official README.md in the upstream project documents security properties and explains the differences between the regular and light variants.
"},{"location":"packages/hardened_malloc/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
It is strongly reccomended to read all documentation here before deploying this package on your infrastructure.
In order to support the large amount of mappings caused by guard slabs and large allocation guard regions, the vm.max_map_count sysctl is increased as part of package installation to 1048576 in /etc/sysctl.d/hardened_malloc.conf. You'll need to run sysctl -p /etc/sysctl.d/hardened_malloc.conf for this change to take effect without a reboot. Incidentally, Fedora 39 made the same change, so it's not an exotic configuration.
The package ships 2 builds of hardened_malloc, the regular variant, which is located at /usr/lib64/libhardened_malloc.so and can be preloaded using the hardened_malloc_preload.sh script, and the light variant, which is located at /usr/lib64/libhardened_malloc-light.so and can be preloaded using the hardened_malloc_light_preload.sh script. The preload scripts add the relevant library to LD_PRELOAD and then load the desired binary, as shown in the following example: hardened_malloc_preload.sh cat /proc/self/maps.
Users may choose to set an OS-wide LD_PRELOAD with hardened_malloc. This can be done by adding the desired library, for example, /usr/lib64/libhardened_malloc.so, into your /etc/ld.so.preload. Be aware that for applications where AT_SECURE is set, this approach will not work.
It is suggested that if you wish to deploy hardened_malloc systemwide, that you deploy it in your LD_PRELOAD with the normal variant globally, and then for applications which are performance sensitive, or which fail with the normal variant, try them individually with the light variant using the preload script or by setting LD_PRELOAD within a systemd service namespace. If that does not resolve your issue, try disabling hardened_malloc by running the program in its own systemd service namespace.
"},{"location":"packages/hardened_malloc/#bugs-uncovered-by-hardened_malloc","title":"Bugs uncovered by hardened_malloc","text":"
As with all infrastructure changes, ensure you test in your staging environment extensively before deploying into production. Many packages and projects suffer from memory corruption bugs, which when running under glibc are not encountered during operation, but which hardened_malloc uncovers. Some applications may crash during usage, completely break, or break when running with certain configurations. Bugs in packages are typically a result of upstream project bugs, and should be reported there. In some cases these bugs are fixed in later versions in the upstream project, in which case the bug is an issue with Rocky Linux, and should be reported to Rocky Linux and its upstream distribution, so that the patch may be included.
Package name Latest version tested Normal variant Light variant php php-8.0.30-1.el9_2.x86_64 Broken Broken php php-8.1.14-1.module+el9.2.0+15232+36037ab0.x86_64 Broken Broken sssd sssd-2.8.2-3.el9_2.x86_64 Broken Broken"},{"location":"packages/hardened_malloc/#potential-for-issues-with-edr","title":"Potential for issues with EDR","text":"
By nature of relying on LD_PRELOAD, if you have EDR software on your server, it may falsely send alerts when using hardened_malloc. If it doesn't, your EDR is probably terrible or misconfigured.
* Tue Nov 14 2023 Solar Designer <solar@openwall.com> 12-3\n- Package hardened_malloc_light_preload.sh\n- Disable arm64 building for now (fix didn't work)\n\n* Wed Nov 8 2023 flawedworld <flawedworld@flawed.world> 12-2\n- Set CONFIG_NATIVE to false\n- Mark libraries as executable (change to 755 permissions)\n- Add hardened_malloc_light_preload.sh\n- Fix arm64 building\n\n* Sat Oct 28 2023 flawedworld <flawedworld@flawed.world> 12-1\n- Initial packaging for hardened_malloc version 12, co-authored-by\n Scott Shinn (atomicturtle) and Solar Designer\n
LKRG, or Linux Kernel Runtime Guard, is a kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel.
More information is available on the LKRG homepage and in the documentation files included in the package.
"},{"location":"packages/lkrg/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
Due to EL's kABI stability and the weak-modules mechanism, which this package uses, the same binary package of LKRG usually works across different kernel revisions/builds within the same EL minor release (e.g., 9.4). Once there's a new minor release (e.g., 9.4 is upgraded to 9.5), we'll provide a new build of LKRG accordingly.
Installing the package does not automatically start LKRG nor enable it to start on system bootup. To start LKRG please use:
systemctl start lkrg\n
To enable LKRG on bootup please use:
systemctl enable lkrg\n
"},{"location":"packages/lkrg/#testing-and-recovery","title":"Testing and recovery","text":"
Although the current package passed our own testing (on 9.4 and 8.10), we recommend that you only enable LKRG to start on system bootup after you've tested it for a while to ensure its compatibility with your system. If you nevertheless run into a boot time issue with LKRG later, you can disable it with the nolkrg kernel command-line option.
LKRG includes a remote kernel message logging capability. The corresponding userspace tools are found in the lkrg-logger sub-package. Documentation is also included in there, in /usr/share/doc/lkrg-logger/LOGGING.
* Wed May 22 2024 Solar Designer <solar@openwall.com> 0.9.8-2\n- Pass direct kernel-devel's build path into make\n- Drop \"BuildRequires: kernel\" as we no longer need /lib/modules/*/build\n- Add \"BuildRequires: systemd\" for the _unitdir RPM macro (apparently this was\n previously an indirect dependency via the kernel package)\n\n* Tue Feb 27 2024 Solar Designer <solar@openwall.com> 0.9.8-1\n- Update to 0.9.8\n- Add logger sub-package\n- Mark the sysctl configuration file config(noreplace)\n- Use \"sort -V\" to build against the latest installed version of kernel-devel\n\n* Wed Nov 8 2023 Solar Designer <solar@openwall.com> 0.9.7-4\n- Add a couple of upstream patches, most notably to fix kINT false positives on\nEL 8.8.\n\n* Tue Oct 24 2023 Solar Designer <solar@openwall.com> 0.9.7-3\n- Use weak-modules if available so that on RHEL and its rebuilds the same LKRG\n package build works across different kABI-compatible kernel revisions/builds\n- Drop 32-bit x86 from ExclusiveArch since recent RHEL lacks such kernel-devel\n\n* Thu Sep 14 2023 Solar Designer <solar@openwall.com> 0.9.7-2\n- Use kernel build directory corresponding to the kernel-devel package, not to\nthe currently running kernel\n- \"BuildRequires: kernel\" for the /lib/modules/* directory\n- \"BuildRequires: elfutils-libelf-devel\" to support CONFIG_UNWINDER_ORC=y\n\n* Thu Sep 14 2023 Solar Designer <solar@openwall.com> 0.9.7-1\n- Wrote this rough RPM spec file for Red Hat'ish distros, seems to work fine on\nRHEL 7, 8, 9 rebuilds, but is only reliable when there's exactly one\nkernel-devel package installed at build time and it exactly matches the target\nkernel version.\n
This is a rebuild of the 8.9 package as-is to make it available for 8.8. It uses Intel's fixed microcode revision that was provided to distros privately in preparation for the coordinated disclosure.
* Tue Nov 14 2023 Solar Designer <solar@openwall.com> - 4:20231114-1\n- Update Intel CPU microcode to microcode-20231114 (fixes CVE-2023-23583),\n temporarily dropping most documentation patches\n
Instead of linking against libsystemd, load it dynamically in a temporary child process to avoid polluting actual sshd's address space with that library and its many dependencies (shortens ldd sshd output from 28 to 20 lines)
Build without Kerberos support (further shortens ldd sshd from 20 to 13 lines)
* Mon May 20 2024 Solar Designer <solar@openwall.com> 8.7p1-38.el9_4.security.0.4\n- Rebase on 8.7p1-38\n\n* Sat Mar 16 2024 Solar Designer <solar@openwall.com> 8.7p1-34.3.el9_3.security.0.3\n- Comment out GSSAPI* lines in /etc/ssh/ssh*_config.d/50-redhat.conf and patch\n the code to silently ignore GSSAPIKexAlgorithms when unsupported (like it is\n in our new without-Kerberos build)\n\n* Mon Mar 11 2024 Solar Designer <solar@openwall.com> 8.7p1-34.3.el9_3.security.0.2\n- Rebase 8.7p1-34.el9_3.security.0.1 on 8.7p1-34.3\n- Build without Kerberos support (shortens \"ldd sshd\" from 20 to 13 lines)\n\n* Wed Nov 22 2023 Solar Designer <solar@openwall.com> 8.7p1-34.el9_3.security.0.1\n- Rebase 8.7p1-30.el9.security.0.2 on 8.7p1-34\n\n* Sat Oct 07 2023 Solar Designer <solar@openwall.com> 8.7p1-30.el9.security.0.2\n- Load libsystemd.so.0, not libsystemd.so, as the latter is only provided by\n systemd-devel\n\n* Mon Aug 28 2023 Solar Designer <solar@openwall.com> 8.7p1-30.el9.security.0.1\n- Instead of linking against libsystemd, load it dynamically in a temporary\n child process to avoid polluting actual sshd's address space with that\n library and its many dependencies (shortens \"ldd sshd\" from 28 to 20 lines)\n
passwdqc is a password/passphrase strength checking and policy enforcement toolset, including a PAM module (pam_passwdqc), command-line programs (pwqcheck, pwqfilter, and pwqgen), and a library (libpasswdqc).
More information is available on the passwdqc homepage and in the documentation files (man pages and a README) included in the sub-packages below.
"},{"location":"packages/passwdqc/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
pam_passwdqc is a PAM module that is normally invoked on password changes by programs such as passwd(1). It is capable of checking password or passphrase strength, enforcing a policy, and offering randomly-generated passphrases, with all of these features being optional and easily (re-)configurable.
Merely installing this sub-package does not yet configure the system to use the PAM module. To do so, on EL9 use our control, or on either EL8 or EL9 you may edit PAM configuration files manually e.g. like shown here.
pwqcheck and pwqgen are standalone password/passphrase strength checking and random passphrase generator programs, respectively, which are usable from scripts.
The pwqfilter program searches, creates, or updates binary passphrase filter files, which can also be used with pwqcheck and pam_passwdqc. This can be used for checking of user-provided passwords against existing data breaches, which is recommended in the current NIST guidance, specifically in publication 800-63B sections 5.1.1.2 and A.3. Paid pre-generated filter files are available from Openwall at the project homepage above, but with this tool you can also generate your own.
This package contains development files needed for building passwdqc-aware applications, as well as documentation (man pages) for developing such applications.
passwdqc is a meta sub-package that installs (via dependencies) the actual sub-packages above, except for libpasswdqc-devel.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"SIG/Security Wiki","text":"
The Security SIG repositories provide extra security-related packages and security-hardened override packages (replacing those from the main distribution) for Rocky Linux and other Enterprise Linux (EL) distributions.
If you've been to this wiki before, you'll likely want to check out what's new.
Developing and maintaining various security related packages that are not in upstream EL. Identifying, developing, and maintaining security hardening changes relative to upstream EL packages. Occasionally including/backporting additional security fixes that are not yet in upstream EL packages. Contributing to the respective upstreams where practical.
"},{"location":"#on-another-compatible-el-distro","title":"On another compatible EL distro","text":"
Download the release package containing our repository configuration file and package signing public key. Use the version that corresponds to the major version of your EL distro.
rocky-release-security-9
rocky-release-security-8
Verify the package file's SHA-256 digest with sha256sum. The currently expected digests are:
This isn't as secure as checking the package signature would be if you previously had our package signing public key, but on another distro you probably don't have that yet, so checking the digest against its copy obtained from this separate website is a best-effort measure.
"},{"location":"#packages","title":"Packages","text":""},{"location":"#extra-packages-for-el8-and-el9","title":"Extra packages (for EL8 and EL9)","text":"
lkrg (Linux Kernel Runtime Guard)
passwdqc (password/passphrase strength checking and policy enforcement)
"},{"location":"#extra-packages-currently-only-for-el9","title":"Extra packages (currently only for EL9)","text":"
control (a common interface to register and control security-relevant system facilities)
hardened_malloc (security-focused memory allocator providing the malloc API, and a script to preload it into existing program binaries)
"},{"location":"#override-packages-for-el8-and-el9","title":"Override packages (for EL8 and EL9)","text":"
microcode_ctl (updates Intel CPU microcode to fix CVE-2023-23583)
"},{"location":"#override-packages-currently-only-for-el9","title":"Override packages (currently only for EL9)","text":"
glibc (adds many security-hardening changes originating from Owl and ALT Linux on top of EL package)
openssh (fewer shared libraries exposed in sshd processes while otherwise fully matching EL package's functionality)
The changes are described in more detail on the per-package wiki pages linked above, as well as in the package changelogs. More packages/changes are planned, including override packages also for EL8.
Just like for other Rocky Linux SIGs, the source trees for Security SIG packages are maintained in per-package git repositories. Each repository contains branches r8 and/or r9 corresponding to target EL version.
If anyone else wants to join this effort - in any capacity including development, maintenance, testing, documentation, user support, spreading the word, or something else - please join the Mattermost channel below and let us know!
We also welcome well-reasoned suggestions/feedback/preferences on direction we should take (e.g., only making changes on top of EL's vs. offering newer upstream versions), what else to package, and what other changes to include.
Some of the people active with setting up this SIG so far:
Name Mattermost Name @flawedworld Fredrik Nystr\u00f6m @nscfreny Louis Abel @label Mustafa @mustafa Neil Hanlon @neil Scott Shinn @atomicturtle Solar Designer @solardiz"},{"location":"news/","title":"News","text":"
These are what we consider significant SIG/Security news items, not an exhaustive list of package updates and wiki edits.
lkrg 0.9.8-2.el8_10.security is a rebuild of Linux Kernel Runtime Guard for EL 8.10, which wasn't strictly necessary this time as our build for 8.9 also remained working on 8.10 as-is.
glibc 2.34-100.el9_4.security.0.8 contains all of our changes so far rebased on top of 9.4's 2.34-100, which was still missing the iconv and nscd security fixes, so our addition of those is still relevant.
openssh rebased on 9.4's 8.7p1-38.
The status page on CVE-2024-1086 has been updated to refer to EL9 fix.
Our hardened EL9 glibc updated to include glibc upstream fix for CVE-2024-2961. On that CVE status page, we also provide a mitigation for both EL9 and EL8.
The status page on CVE-2024-1086 has been updated to refer to EL8 fix and errata, suggest disabling network namespaces, explain remaining risks with LKRG.
We've just set up a status page on CVE-2024-1086, currently listing two mitigations for this Linux kernel vulnerability.
"},{"location":"news/#march-11-to-16-2024","title":"March 11 to 16, 2024","text":"
openssh rebased on upstream EL 8.7p1-34.3 with fixes for CVE-2023-48795 (Terrapin attack) and CVE-2023-51385, now building it without Kerberos support (further shortens ldd sshd from 20 to 13 lines, down from 28 lines in upstream EL).
This SIG/Security News wiki page has been created, retroactively identifying and listing selected news items so far.
control 0.8.0-4 can now manage 3 privileged programs from util-linux (and util-linux-core): mount, umount (one \"facility\" for both), and write. Its wiki page has been reworked.
control wiki page added, documenting the new package.
control provides a common interface to register and control (what it calls) system facilities. This is intended primarily for facilities that can potentially be dangerous to system security, to let you enable, disable, or configure each facility. A typical facility is a SUID/SGID/setcap program or a configuration setting of a service.
Included initially are facility specifications corresponding to the shadow-utils package. Currently, these allow to control access to 5 privileged programs - 3 of them (chage, gpasswd, and newgrp) are by default SUID root and 2 (newuidmap and newgidmap) are cap_setuid=ep.
Everything we had so far has been updated for EL 9.3 and 8.9, including our hardened EL9 glibc and openssh packages rebased on 9.3's and lkrg rebuilt for 9.3's and 8.9's kernels, along with re-testing and wiki edits.
The rocky-release-security package containing our repository configuration has been made (a while earlier) easier to use on EL distros other than Rocky Linux, and we've now updated the wiki accordingly.
"},{"location":"news/#november-16-to-19-2023","title":"November 16 to 19, 2023","text":"
microcode_ctl also for EL8, providing 8.9's Intel CPU microcode to fix CVE-2023-23583 a few days before general availability of our own 8.9 release as a whole.
Wiki pages lkrg and passwdqc have been created. We had these extra packages for a while, but previously only had wiki pages for override packages (referring solely to upstream homepages for the extra packages).
We've started maintaining wiki pages for selected high profile security issues, initially for glibc CVE-2023-4911 and Intel CPU microcode CVE-2023-23583.
microcode_ctl for EL9, providing latest Intel CPU microcode to fix CVE-2023-23583 ahead of availability of a rebuilt new upstream package.
"},{"location":"news/#october-31-to-november-15-2023","title":"October 31 to November 15, 2023","text":"
hardened_malloc package - a security-focused memory allocator providing the malloc(3) API, and a script to preload it into existing program binaries. Its documentation on the wiki.
Initial wiki content documenting what we had so far, which included override packages of glibc and openssh and extra packages of lkrg and passwdqc (even though these per-package wiki pages did not exist yet, so we instead had summaries and external links on the front page only), the repository package, source code repositories, and Mattermost channel.
Under certain microarchitectural conditions, Intel has identified cases where execution of an instruction (REP MOVSB) encoded with a redundant REX prefix may result in unpredictable system behavior resulting in a system crash/hang, or, in some limited scenarios, may allow escalation of privilege from CPL3 to CPL0.
and by Red Hat:
A security vulnerability was found in some Intel processors. Execution of REP MOVSB instructions with a redundant REX prefix may result in execution continuing at an incorrect EIP address after a micro-architectural event occurs, potentially allowing privilege escalation, information disclosure and/or a denial of service via local access.
as well as in CVE-2023-23583.
More detail is available via these links to Intel's website and in the public disclosure by Tavis Ormandy from Google.
A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.
More detail is available in the public disclosure by Qualys, the team who discovered the issue.
A flaw was found in the Netfilter subsystem in the Linux kernel. This issue occurs in the nft_verdict_init() function, allowing positive values as a drop error within the hook verdict, therefore, the nf_hook_slow() function can cause a double-free vulnerability when NF_DROP is issued with a drop error that resembles NF_ACCEPT. The nf_tables component can be exploited to achieve local privilege escalation.
Exploitation of the flaw is described in great detail in a blog post by Notselwyn.
Public disclosure date: March 26, 2024 for the above blog post, which made the issue widely known
This is a mitigation also suggested by Red Hat. It is sufficient to fully mitigate this and other/future related vulnerabilities.
If you cannot disable user namespaces, you may nevertheless be able to disable network namespaces, which is also sufficient to fully mitigate this and some other/future related vulnerabilities.
Install our package of LKRG, start and enable the service.
This does not fully mitigate the vulnerability, but it reliably prevents the specific exploit referenced above from working and produces LKRG alerts when the exploit is run. LKRG's feature that does so is its allow list for the kernel's usermodehelper. This will similarly prevent other/future exploits that abuse usermodehelper. The remaining risks are Denial of Service (DoS) as even interrupted exploits may leave the system in an unstable state, and a different exploit of the same vulnerability bypassing LKRG.
An out-of-bounds write flaw was found in the ISO-2022-CN-EXT plugin for glibc's iconv library. When converting from UCS4 charset, adding certain escape charterers is required to indicate where the charset was changed to the library. During this process, iconv improperly checks the boundaries of internal buffers, leading to a buffer overflow, which allows writing up to 3 bytes outside the desired memory location. This issue may allow an attacker to craft a malicious characters sequence that will trigger the out-of-bounds write and perform remote code execution, presenting a high impact to the Integrity, Confidentiality, and Availability triad.
and as further discussed on oss-security:
On PHP [this glibc bug led] to amazing results: a new exploitation technique that affects the whole PHP ecosystem.
Support for the ISO-2022-CN-EXT character set can be excluded from glibc's iconv(3) by editing /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf to comment out the below 3 lines at line 1254 (same line number in EL9 and EL8) and then regenerating the cache file:
These two steps can be accomplished by running the below commands as root:
sed -i -r 's/^(.*ISO-2022-CN-EXT.*)$/#\\1/' /usr/lib64/gconv/gconv-modules.d/gconv-modules-extra.conf\niconvconfig\n
To make sure this has worked as intended, we also recommend that you run iconv -l | grep ISO-2022-CN-EXT before and after the above procedure. It should list the ISO-2022-CN-EXT character set before the procedure, but produce empty output afterwards.
"},{"location":"issues/CVE-2024-2961/#making-the-fix-or-mitigation-effective","title":"Making the fix or mitigation effective","text":"
After installing a fixed version of glibc or/and applying the mitigation, you'll need to restart any long-running processes for which the bug matters (such as PHP-FPM).
As discovered by Qualys and summarized by OpenSSH upstream:
A critical vulnerability in sshd(8) was present in Portable OpenSSH versions 8.5p1 [to] 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges.
Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.
control provides a common interface to register and control (what it calls) system facilities. This is intended primarily for facilities that can potentially be dangerous to system security, to let you enable, disable, or configure each facility. A typical facility is a configuration setting of a service or a SUID/SGID/setcap program, or a closely related group of such settings and/or programs that are managed together. We manage permissions on SUID/SGID/setcap programs because those programs pose risk to system security in case of vulnerabilities in them or in library code they use.
control originates in Owl and is actively maintained in ALT Linux.
"},{"location":"packages/control/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
While the original control package in Owl and ALT Linux merely provides the common interface mentioned above for other packages to register their facilities with (and many packages in those distros do), it's been adapted in Rocky Linux to provide its own sub-packages with facility specifications and RPM trigger scripts for other packages coming from EL. This way, we can control those facilities and have custom settings persist (be automatically saved and restored) over package upgrades without us having to maintain forks of those other packages.
The available facilities, their current settings, and lists of possible settings can be queried by running the control command without parameters. With all currently available sub-packages installed and upstream default settings, its output is:
chage public (public restricted)\ngpasswd public (public wheelonly restricted)\nmount public (public wheelonly unprivileged restricted)\nnewgidmap public (public wheelonly restricted)\nnewgrp public (public wheelonly restricted)\nnewuidmap public (public wheelonly restricted)\npam_timestamp_check public (public restricted)\npassword-hash sha512crypt (sha512crypt yescrypt)\npassword-policy pwquality (pwquality passwdqc)\nunix_chkpwd public (public restricted)\nwrite public (public restricted)\n
Facility specifications corresponding to the shadow-utils package. Currently, these allow to control access to 5 privileged programs - 3 of them (chage, gpasswd, and newgrp) are by default SUID root and 2 (newuidmap and newgidmap) are cap_setuid=ep.
Facility specifications corresponding to the util-linux and util-linux-core packages. Currently, these allow to control access to 3 privileged programs - 2 of them (mount and umount) are by default SUID root and 1 (write) SGID tty.
Facility specifications corresponding to the pam package. Currently, these allow to control user password hashing scheme and password policy in use by PAM-aware programs, as well as two SUID root PAM helper programs unix_chkpwd and pam_timestamp_check.
* Wed Jan 3 2024 Solar Designer <solar@openwall.com> 0.8.0-7\n- Add unix_chkpwd and pam_timestamp_check facilities to the pam sub-package\n\n* Wed Jan 3 2024 Solar Designer <solar@openwall.com> 0.8.0-6\n- Revise password-hash and password-policy to process the underlying two\n \"sub-facilities\" (for the two configuration files updated by each of these)\n using the same logic that we had used for mount (where the two underlying\n \"sub-facilities\" are the mount and umount programs)\n\n* Wed Dec 27 2023 Solar Designer <solar@openwall.com> 0.8.0-5\n- Install control(8) mode 755 since some of its features work as non-root\n- Add sub-package with facilities and triggers for pam password hashing and\n password policy\n\n* Mon Dec 18 2023 Solar Designer <solar@openwall.com> 0.8.0-4\n- Add sub-package with facilities and triggers for util-linux\n\n* Mon Dec 18 2023 Solar Designer <solar@openwall.com> 0.8.0-3\n- Rename the shadow sub-package to shadow-utils\n- Rename the source files not to differentiate them by sub-package\n- Add \"Requires: shadow-utils\" in the shadow-utils sub-package\n\n* Wed Dec 13 2023 Solar Designer <solar@openwall.com> 0.8.0-2\n- In addition to Requires(pre), also use Requires in the sub-package\n- In %triggerprein_control, pre-check that the facility exists\n- Use (renamed) copies of the trigger macros within this spec file\n\n* Wed Dec 13 2023 Solar Designer <solar@openwall.com> 0.8.0-1\n- Add macros for use in RPM triggers\n- Add sub-package with facilities and triggers for shadow-utils\n\n* Wed Dec 6 2023 Solar Designer <solar@openwall.com> 0.8.0-0\n- Initial packaging for EL based on ALT Linux and Owl packages\n
Distrust and/or unset many more environment variables used by current and previous glibc versions when running SUID/SGID/setcap (Owl via ALT Linux)
When syslog(3)/vsyslog(3) is called by a SUID/SGID/setcap program without a preceding call to openlog(3), don't blindly trust __progname for the syslog ident (Owl via ALT Linux, further revised for Rocky Linux)
In syslog(3)/vsyslog(3) use asctime_r(3)+localtime_r(3) instead of strftime_r() so that month names don't depend on current locale settings (Owl via ALT Linux)
In asprintf(3)/vasprintf(3) reset the pointer to NULL on error, like BSDs do, so that the caller wouldn't access memory over an uninitialized or stale pointer (ALT Linux)
In fread(3)/fwrite(3) check for potential integer overflow (ALT Linux)
In tmpfile(3) use the TMPDIR environment variable (when not running SUID/SGID/setcap) (ALT Linux)
When qsort(3) is wrongly used with a nontransitive comparison function, nevertheless be robust and avoid memory corruption (Qualys, Rocky Linux)
"},{"location":"packages/glibc/#known-effective-vulnerability-mitigations-and-fixes","title":"Known-effective vulnerability mitigations and fixes","text":"
2.34-83.12.el9_3.security.0.6 and above includes nscd CVE-2024-33599, CVE-2024-33600, CVE-2024-33601, CVE-2024-33602 fixes from upstream glibc 2.34 branch, which upstream also included starting with 2.34-100.el9_4.2.
2.34-83.12.el9_3.security.0.5 and above includes iconv(3) ISO-2022-CN-EXT CVE-2024-2961 fix from upstream glibc 2.34 branch, which upstream also included starting with 2.34-100.el9_4.2.
2.34-60.el9_2.security.0.2 included mitigations sufficient to avoid security exposure of CVE-2023-4911 and a backport of upstream glibc fix of CVE-2023-4527 that was not yet in upstream EL. In the update to 2.34-60.7.el9_2.security.0.3 and beyond, we retained the mitigations while rebasing on upstream EL's package with upstream fixes for these vulnerabilities (and more).
In general, inclusion of additional security fixes will be \"reverted\" if and when those get included in upstream EL packages that we rebase our changes on.
* Thu Jun 13 2024 Solar Designer <solar@openwall.com> - 2.34-100.2.el9.security.0.9\n- Rebase on 2.34-100.2\n\n[... upstream changes ...]\n\n* Mon May 20 2024 Solar Designer <solar@openwall.com> - 2.34-100.el9.security.0.8\n- Rebase on 2.34-100\n\n* Tue May 07 2024 Solar Designer <solar@openwall.com> - 2.34-83.12.el9.security.0.7\n- Upstream glibc 2.34 fix \"nscd: Use time_t for return type of addgetnetgrentX\"\n\n* Tue Apr 30 2024 Solar Designer <solar@openwall.com> - 2.34-83.12.el9.security.0.6\n- Add nscd CVE-2024-33599, CVE-2024-33600, CVE-2024-33601, CVE-2024-33602 fixes\n from upstream glibc 2.34 branch\n\n* Thu Apr 18 2024 Solar Designer <solar@openwall.com> - 2.34-83.12.el9.security.0.5\n- Rebase on 2.34-83.12\n- Add iconv() ISO-2022-CN-EXT CVE-2024-2961 fix from upstream glibc 2.34 branch\n\n[... upstream changes ...]\n\n* Wed Jan 31 2024 Solar Designer <solar@openwall.com> - 2.34-83.7.el9.security.0.4\n- Harden syslog ident fallback initialization to use at most 64 characters of\n __progname when __libc_enable_secure, as inspired by Qualys' discovery of\n related vulnerabilities in newer glibc (not yet present in this version):\n https://www.openwall.com/lists/oss-security/2024/01/30/6\n- Harden qsort against nontransitive comparison functions as suggested by\n Qualys: https://www.openwall.com/lists/oss-security/2024/01/30/7\n\n* Wed Nov 22 2023 Solar Designer <solar@openwall.com> - 2.34-83.7.el9.security.0.3\n- Rebase on 2.34-83.7, drop \"our\" CVE-2023-4527 patch in favor of RH's\n (a similar rebase was made on Oct 6 in 2.34-60.7.el9.security.0.3 for 9.2)\n\n[... upstream changes ...]\n\n* Mon Oct 2 2023 Solar Designer <solar@openwall.com> - 2.34-60.el9.security.0.2\n- Add glibc-owl-alt-sanitize-env.patch stitched from several ALT Linux commits\n as none of their revisions matched this package's set of backports as-is\n- Add glibc-upstream-no-aaaa-CVE-2023-4527.patch based on upstream commit\n bd77dd7e73e3530203be1c52c8a29d08270cb25d fixing\n CVE-2023-4527: Stack read overflow with large TCP responses in no-aaaa mode\n\n* Tue Sep 26 2023 Solar Designer <solar@openwall.com> - 2.34-60.el9.security.0.1\n- Revise the texinfo documentation edit of glibc-2.34-alt-asprintf.patch via\n glibc-2.34-rocky-asprintf.patch\n\n* Sat Sep 23 2023 Solar Designer <solar@openwall.com> - 2.34-60.el9.security.0.0\n- Add some of the patches from ALT Linux as of when they were at 2.34:\n https://git.altlinux.org/gears/g/glibc.git\n git show 5fa32fb0f8509f4b2b1105d71b45966dfbadc099 > glibc-2.34-alt-tmpfile.patch\n git show f97e5d60a6a4c9cb64e3b9ee6f5113969cf07d87 > glibc-2.34-alt-asprintf.patch\n git show cd45d0f74560325cc48aedb9f56881270ab3dfab > glibc-2.34-alt-libio-bound.patch\n git show 436eb1017c04aee3a553c2868d00a4b046e5e394 > glibc-2.34-owl-alt-syslog-ident.patch\n git show 03a86c234873723c26b7e387c498c1332c223968 > glibc-2.34-mjt-owl-alt-syslog-timestamp.patch\n
This package ships the \"normal\" and \"light\" configurations of the GrapheneOS hardened_malloc project. The official README.md in the upstream project documents security properties and explains the differences between the regular and light variants.
"},{"location":"packages/hardened_malloc/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
It is strongly reccomended to read all documentation here before deploying this package on your infrastructure.
In order to support the large amount of mappings caused by guard slabs and large allocation guard regions, the vm.max_map_count sysctl is increased as part of package installation to 1048576 in /etc/sysctl.d/hardened_malloc.conf. You'll need to run sysctl -p /etc/sysctl.d/hardened_malloc.conf for this change to take effect without a reboot. Incidentally, Fedora 39 made the same change, so it's not an exotic configuration.
The package ships 2 builds of hardened_malloc, the regular variant, which is located at /usr/lib64/libhardened_malloc.so and can be preloaded using the hardened_malloc_preload.sh script, and the light variant, which is located at /usr/lib64/libhardened_malloc-light.so and can be preloaded using the hardened_malloc_light_preload.sh script. The preload scripts add the relevant library to LD_PRELOAD and then load the desired binary, as shown in the following example: hardened_malloc_preload.sh cat /proc/self/maps.
Users may choose to set an OS-wide LD_PRELOAD with hardened_malloc. This can be done by adding the desired library, for example, /usr/lib64/libhardened_malloc.so, into your /etc/ld.so.preload. Be aware that for applications where AT_SECURE is set, this approach will not work.
It is suggested that if you wish to deploy hardened_malloc systemwide, that you deploy it in your LD_PRELOAD with the normal variant globally, and then for applications which are performance sensitive, or which fail with the normal variant, try them individually with the light variant using the preload script or by setting LD_PRELOAD within a systemd service namespace. If that does not resolve your issue, try disabling hardened_malloc by running the program in its own systemd service namespace.
"},{"location":"packages/hardened_malloc/#bugs-uncovered-by-hardened_malloc","title":"Bugs uncovered by hardened_malloc","text":"
As with all infrastructure changes, ensure you test in your staging environment extensively before deploying into production. Many packages and projects suffer from memory corruption bugs, which when running under glibc are not encountered during operation, but which hardened_malloc uncovers. Some applications may crash during usage, completely break, or break when running with certain configurations. Bugs in packages are typically a result of upstream project bugs, and should be reported there. In some cases these bugs are fixed in later versions in the upstream project, in which case the bug is an issue with Rocky Linux, and should be reported to Rocky Linux and its upstream distribution, so that the patch may be included.
Package name Latest version tested Normal variant Light variant php php-8.0.30-1.el9_2.x86_64 Broken Broken php php-8.1.14-1.module+el9.2.0+15232+36037ab0.x86_64 Broken Broken sssd sssd-2.8.2-3.el9_2.x86_64 Broken Broken"},{"location":"packages/hardened_malloc/#potential-for-issues-with-edr","title":"Potential for issues with EDR","text":"
By nature of relying on LD_PRELOAD, if you have EDR software on your server, it may falsely send alerts when using hardened_malloc. If it doesn't, your EDR is probably terrible or misconfigured.
* Tue Nov 14 2023 Solar Designer <solar@openwall.com> 12-3\n- Package hardened_malloc_light_preload.sh\n- Disable arm64 building for now (fix didn't work)\n\n* Wed Nov 8 2023 flawedworld <flawedworld@flawed.world> 12-2\n- Set CONFIG_NATIVE to false\n- Mark libraries as executable (change to 755 permissions)\n- Add hardened_malloc_light_preload.sh\n- Fix arm64 building\n\n* Sat Oct 28 2023 flawedworld <flawedworld@flawed.world> 12-1\n- Initial packaging for hardened_malloc version 12, co-authored-by\n Scott Shinn (atomicturtle) and Solar Designer\n
LKRG, or Linux Kernel Runtime Guard, is a kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel.
More information is available on the LKRG homepage and in the documentation files included in the package.
"},{"location":"packages/lkrg/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
Due to EL's kABI stability and the weak-modules mechanism, which this package uses, the same binary package of LKRG usually works across different kernel revisions/builds within the same EL minor release (e.g., 9.4). Once there's a new minor release (e.g., 9.4 is upgraded to 9.5), we'll provide a new build of LKRG accordingly.
Installing the package does not automatically start LKRG nor enable it to start on system bootup. To start LKRG please use:
systemctl start lkrg\n
To enable LKRG on bootup please use:
systemctl enable lkrg\n
"},{"location":"packages/lkrg/#testing-and-recovery","title":"Testing and recovery","text":"
Although the current package passed our own testing (on 9.4 and 8.10), we recommend that you only enable LKRG to start on system bootup after you've tested it for a while to ensure its compatibility with your system. If you nevertheless run into a boot time issue with LKRG later, you can disable it with the nolkrg kernel command-line option.
LKRG includes a remote kernel message logging capability. The corresponding userspace tools are found in the lkrg-logger sub-package. Documentation is also included in there, in /usr/share/doc/lkrg-logger/LOGGING.
* Wed May 22 2024 Solar Designer <solar@openwall.com> 0.9.8-2\n- Pass direct kernel-devel's build path into make\n- Drop \"BuildRequires: kernel\" as we no longer need /lib/modules/*/build\n- Add \"BuildRequires: systemd\" for the _unitdir RPM macro (apparently this was\n previously an indirect dependency via the kernel package)\n\n* Tue Feb 27 2024 Solar Designer <solar@openwall.com> 0.9.8-1\n- Update to 0.9.8\n- Add logger sub-package\n- Mark the sysctl configuration file config(noreplace)\n- Use \"sort -V\" to build against the latest installed version of kernel-devel\n\n* Wed Nov 8 2023 Solar Designer <solar@openwall.com> 0.9.7-4\n- Add a couple of upstream patches, most notably to fix kINT false positives on\nEL 8.8.\n\n* Tue Oct 24 2023 Solar Designer <solar@openwall.com> 0.9.7-3\n- Use weak-modules if available so that on RHEL and its rebuilds the same LKRG\n package build works across different kABI-compatible kernel revisions/builds\n- Drop 32-bit x86 from ExclusiveArch since recent RHEL lacks such kernel-devel\n\n* Thu Sep 14 2023 Solar Designer <solar@openwall.com> 0.9.7-2\n- Use kernel build directory corresponding to the kernel-devel package, not to\nthe currently running kernel\n- \"BuildRequires: kernel\" for the /lib/modules/* directory\n- \"BuildRequires: elfutils-libelf-devel\" to support CONFIG_UNWINDER_ORC=y\n\n* Thu Sep 14 2023 Solar Designer <solar@openwall.com> 0.9.7-1\n- Wrote this rough RPM spec file for Red Hat'ish distros, seems to work fine on\nRHEL 7, 8, 9 rebuilds, but is only reliable when there's exactly one\nkernel-devel package installed at build time and it exactly matches the target\nkernel version.\n
This is a rebuild of the 8.9 package as-is to make it available for 8.8. It uses Intel's fixed microcode revision that was provided to distros privately in preparation for the coordinated disclosure.
* Tue Nov 14 2023 Solar Designer <solar@openwall.com> - 4:20231114-1\n- Update Intel CPU microcode to microcode-20231114 (fixes CVE-2023-23583),\n temporarily dropping most documentation patches\n
Instead of linking against libsystemd, load it dynamically in a temporary child process to avoid polluting actual sshd's address space with that library and its many dependencies (shortens ldd sshd output from 28 to 20 lines)
Build without Kerberos support (further shortens ldd sshd from 20 to 13 lines)
* Mon Jul 01 2024 Solar Designer <solar@openwall.com> 8.7p1-38.el9_4.security.0.5\n- Fix CVE-2024-6387 regreSSHion\n\n* Mon May 20 2024 Solar Designer <solar@openwall.com> 8.7p1-38.el9_4.security.0.4\n- Rebase on 8.7p1-38\n\n* Sat Mar 16 2024 Solar Designer <solar@openwall.com> 8.7p1-34.3.el9_3.security.0.3\n- Comment out GSSAPI* lines in /etc/ssh/ssh*_config.d/50-redhat.conf and patch\n the code to silently ignore GSSAPIKexAlgorithms when unsupported (like it is\n in our new without-Kerberos build)\n\n* Mon Mar 11 2024 Solar Designer <solar@openwall.com> 8.7p1-34.3.el9_3.security.0.2\n- Rebase 8.7p1-34.el9_3.security.0.1 on 8.7p1-34.3\n- Build without Kerberos support (shortens \"ldd sshd\" from 20 to 13 lines)\n\n* Wed Nov 22 2023 Solar Designer <solar@openwall.com> 8.7p1-34.el9_3.security.0.1\n- Rebase 8.7p1-30.el9.security.0.2 on 8.7p1-34\n\n* Sat Oct 07 2023 Solar Designer <solar@openwall.com> 8.7p1-30.el9.security.0.2\n- Load libsystemd.so.0, not libsystemd.so, as the latter is only provided by\n systemd-devel\n\n* Mon Aug 28 2023 Solar Designer <solar@openwall.com> 8.7p1-30.el9.security.0.1\n- Instead of linking against libsystemd, load it dynamically in a temporary\n child process to avoid polluting actual sshd's address space with that\n library and its many dependencies (shortens \"ldd sshd\" from 28 to 20 lines)\n
passwdqc is a password/passphrase strength checking and policy enforcement toolset, including a PAM module (pam_passwdqc), command-line programs (pwqcheck, pwqfilter, and pwqgen), and a library (libpasswdqc).
More information is available on the passwdqc homepage and in the documentation files (man pages and a README) included in the sub-packages below.
"},{"location":"packages/passwdqc/#usage-in-rocky-linux","title":"Usage in Rocky Linux","text":"
pam_passwdqc is a PAM module that is normally invoked on password changes by programs such as passwd(1). It is capable of checking password or passphrase strength, enforcing a policy, and offering randomly-generated passphrases, with all of these features being optional and easily (re-)configurable.
Merely installing this sub-package does not yet configure the system to use the PAM module. To do so, on EL9 use our control, or on either EL8 or EL9 you may edit PAM configuration files manually e.g. like shown here.
pwqcheck and pwqgen are standalone password/passphrase strength checking and random passphrase generator programs, respectively, which are usable from scripts.
The pwqfilter program searches, creates, or updates binary passphrase filter files, which can also be used with pwqcheck and pam_passwdqc. This can be used for checking of user-provided passwords against existing data breaches, which is recommended in the current NIST guidance, specifically in publication 800-63B sections 5.1.1.2 and A.3. Paid pre-generated filter files are available from Openwall at the project homepage above, but with this tool you can also generate your own.
This package contains development files needed for building passwdqc-aware applications, as well as documentation (man pages) for developing such applications.