OpenBSD 7.9: two parched failures that allowed local privilege climbing

Today a chain of exploitation of local privileges against OpenBSD 7.9 was made public which, according to the report published by the security company Calif, allows an attacker to rise to root by exploiting two corrected failures in September. The patches for both failures are already available and distributed as errata in September; the first (an entire overflow in shmat (4)) was corrected on 14 September as errata 018 and the second (a use-after-free in the reference count) was corrected on 30 September as errata 026. The corrections are available through syspatch and, according to OpenBSD, cover all architectures. There is, for now, no CVE assigned to either of the two failures or public evidence of use in targeted attacks.

Facts confirmed: the initial vector is a whole overflow in the shmat (4) shared memory attachment function, inherited from the original definition of the BSD kernel for the add-on counter shm _ nattch as a short with 16 bit sign (maximum 32.767). OpenBSD did not expand that type and the explosion takes advantage that, creating enough shared memory segments and many processes, that counter can exceed its limit and make the value wrap to negative. The second piece of the chain is a failure in the reference count that results in a use-after-free. Calif published a technical analysis and concept test code after the delivery of patches by OpenBSD.

How the chain works - technical explanation reconstructed from the report: the attacker maps dozens of shared memory segments and creates numerous processes to inflate shm _ natch beyond 32.767; when the counter wraps, a career condition is created that can cause the kernel to release objects still used by other processes. From there, the explosion also takes advantage of an off-limits writing that modifies multitast membership meters in kernel structures. When the affected socket is closed, the resulting decrement operations end up reading or overwriting page table entries, I make a user page accessible from supervisory mode and thus avoiding the hardware protections SMAP and SMEP. With the kernel-mapped memory in supervisory space, the explosion can overwrite a function pointer located in a kernel direction that is predictable in that machine and run code with kernel privileges.

Important: OpenBSD includes KARL, a randomization mechanism that relieves the kernel binary to randomize function and data addresses. However, according to the researcher (Andrew Griffiths) cited by Calif, the kernel memory divers remain determinist: both the boot and the best-fit assign place early structures (including pointers used by lo0 and enc0 interface controllers) in reproducible directions in the same machine between restarts. This predictability is what allows the explosion to target a function pointer without requiring additional vulnerability of disclosure of information.

What real impacts this can have: on vulnerable systems without patches, an attacker with local access (i.e. capable of running processes on the affected machine) could acquire root privileges. This is not a remote explosion.: requires local execution, such as unprivileged user access or the ability to run processes in a container or session. It therefore directly affects servers or stations where non-fully reliable users have the capacity to run code, multi-user environments and services that give execution to third-party processes.

Confirmed versus estimated or uncertain: it is a fact that the patches were released and that Calif published PoC. It is a reasonable estimate (supported by the explained technique) that the chain allows to evade SMAP / SMEP and get root in the described configuration; however, it is still uncertain whether this chain has been exploited in real environments before correction (there is no public evidence). There is also no CVE assigned at the time of publication, which leaves some uncertainty in the coordinated communication between discoverer and CVE coordinators.

Specific measures to be taken by OpenBSD administrators and users right now: first, update and apply published errata. OpenBSD has distributed the corrections through syspatch; administrators must run syspatch and restart the systems so that the kernel corrections have effect. The official errata information and the syspatch tool are available on the OpenBSD pages: OpenBSD errata and man syspatch. In addition, until the patches are applied, managers should restrict local access: limit accounts with the capacity to run processes, tighten containers and compartments, and review configurations that allow unprivileged users to create large amounts of shared memory segments or mass processes.

Additional operational security recommendations: perform integrity and audit of the system after updating (check binaries, start-up records and abnormal activity), rotate privileged credentials if there is a suspicion of commitment and consider the segregation of services that accept third party code in dedicated hosts that can be restarted and updated more easily. For high-risk environments, limit or monitor the use of unreliable memory sharing and use additional access controls (e.g. control lists at application level).

Hardening measures proposed by the discoverer and its evaluation: Calif proposes four longer-term mitigation lines: safe-unlinking for lists linked to the kernel(already used in FreeBSD and NetBSD), self-referential mapping of page tables, Randomization of the kernel memory consignor and limits checks per compiler. These proposals attack the structural causes of the explosion: safe-unlinking reduces the effectiveness of corruptions of linked lists, the randomization of the self-referential page- table and the assignment makes it difficult to predict directions, and the verification of limits would help to detect out-of-range writing errors or counter oversteps. They are architectural solutions that require implementation and validation work and do not replace the correction of specific errors, but they are an in-depth defense plan.

What to monitor in the coming weeks: confirmation of assigned CVE (s), additional OpenBSD updates that improve architectural mitigation, and reports of active use in the wild stage. The OpenBSD community's response to Calif's hardening proposals and any changes in KARL or kernel memory assignments will also be relevant.

In summary: If you manage OpenBSD systems, apply the errats and restart. The published chain shows a technical route to escape hardware protections and get root from local vulnerabilities, but the corrections are already available and their installation is the most immediate and effective action. Maintain local access reduction as a temporary measure while stabilizing longer-term improvements at the core of the system.