Bug 2515253 - CVE-2026-73585 sblim-cmpi-base: Insecure temporary file creation in sblim-cmpi-base provider registration scripts allows local symlink attack [fedora-all]
Summary: CVE-2026-73585 sblim-cmpi-base: Insecure temporary file creation in sblim-cmp...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: sblim-cmpi-base
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["bfab3f5e-e9b5-4ca3-b500-a...
Depends On:
Blocks: CVE-2026-73585
TreeView+ depends on / blocked
 
Reported: 2026-08-13 11:54 UTC by Vladimir Vasilev
Modified: 2026-08-13 11:54 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Vladimir Vasilev 2026-08-13 11:54:52 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

AI_ONLY_REPORT
package: sblim-cmpi-base-1.6.4-30.el10
------
Summary: Insecure temporary file creation in world-writable directories  
allows symlink overwrite: predictable temporary filenames in provider  
registration scripts let a local attacker redirect privileged writes into  
an attacker-chosen file during registration.
Requirements to exploit: A local unprivileged user must be able to create a  
symlink in `/var/tmp` or `/tmp`, and `provider-register.sh` must be run in  
a privileged context such as RPM `%pre`, `%post`, or `%preun`, or invoked  
manually as root with a vulnerable registration mode. Exploitability is  
reduced or blocked on systems enforcing sticky-directory symlink  
protections such as `fs.protected_symlinks=1`.
Component affected: `sblim-cmpi-base` provider registration scripts  
`provider-register.sh` and `provider-register.sh.pegasus-interop`;  
strongest observed path in `sfcb_install()`/`sfcb_transform()`, with  
similar temporary-file handling in `pegasus_install()` and  
`openwbem_install()`/`openwbem_uninstall()`.
Version affected: `sblim-cmpi-base-1.6.4-30.el10` when the vulnerable  
registration script paths are executed with elevated privileges on systems  
where sticky-directory symlink protections do not prevent the link  
traversal.
Patch available: no released package fix established; proposed patch  
included below
Version fixed: unknown
Upstream coordination: Not notified.
CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H - 6.4 (MEDIUM)
AV:L - Exploitation requires local access to the host.
AC:H - The attacker must hit a privileged registration flow, and  
exploitation may be blocked on modern systems by sticky-directory symlink  
protections or require PID prediction in some code paths.
PR:L - An unprivileged local account is needed to create the symlink in  
a world-writable directory.
UI:N - No separate victim interaction is required once the privileged  
script runs.
S:U - The vulnerable write and the resulting impact stay within the same  
host security scope.
C:N - The demonstrated behavior is file overwrite rather than  
information disclosure.
I:H - A successful attack can modify root-owned files in a privileged  
execution path.
A:H - Overwriting critical files can disrupt services or system  
operation.
Impact: Moderate. On systems without effective sticky-directory symlink  
protections, the flaw can let a local user overwrite root-owned files  
during privileged registration flows. However, exploitation requires local  
access, a privileged execution event, and conditions that are not  
universal. Under Red Hat's guidance, this fits Moderate impact: a flaw that  
could have had Important impact but is less easily exploited based on the  
technical evaluation and/or affects certain configurations.
Embargo: no
Reason: This is a local, configuration-dependent issue with  
straightforward mitigation (`mktemp` and safer temporary-file handling),  
and the available evidence does not show a remote or default-path  
compromise scenario.
Acknowledgement: Aisle Research
Vulnerability Details: The provider registration scripts create temporary  
output files in `/var/tmp` or `/tmp` using predictable names and then write  
through shell redirections that follow symlinks. The clearest path is the  
`sfcb` mode, where `baseregname` is derived from the registration filename  
and used directly in the temporary path:
```sh
for _TEMPDIR in /var/tmp /tmp
do
if test -w $_TEMPDIR
then
_REGFILENAME=$_TEMPDIR/$baseregname.reg
break
fi
done
trap "rm -f $_REGFILENAME" EXIT
if sfcb_transform $_REGFILENAME $myregs
```
```sh
cat >> $OUTFILE <<EOFC
```
A registration input such as `Linux_Base.registration` therefore leads to a  
predictable path such as `/var/tmp/Linux_Base.reg`. The package spec files  
invoke `provider-register.sh` during `%pre`, `%post`, and `%preun`, so  
vulnerable registration modes can run in a privileged package-management  
context. In a controlled proof of concept, pre-creating  
`/var/tmp/Linux_Base.reg` as a symlink caused registration data to be  
written into the symlink target before the downstream staging step failed.  
The `pegasus` and `openwbem` modes use the same insecure  
temporary-directory pattern with PID-based names (`$$.mof`); in `openwbem`,  
the script removes the output path before rewriting it, so that path may  
require tighter timing than the pre-created-symlink `sfcb` case. This  
pattern is consistent with `CWE-377` and `CWE-59`.
Steps to reproduce:
1. On a system where `provider-register.sh` can run as root, ensure  
sticky-directory symlink protections do not block the test case; otherwise  
the issue may not reproduce.
2. As an unprivileged local user, create `/var/tmp/Linux_Base.reg` as a  
symlink to a disposable root-owned file.
3. Trigger the `sfcb` registration path in a privileged context, for  
example `provider-register.sh -t sfcb -r <registration> -m <mof>` as root,  
or through the equivalent package lifecycle action.
4. Observe that registration content is written to the symlink target  
before the staging step exits.
Mitigation: Until a code fix is shipped, keep sticky-directory symlink  
protections enabled (`fs.protected_symlinks=1` or equivalent), avoid  
running the provider registration script from shared multi-user systems  
where untrusted users can plant entries in `/tmp` or `/var/tmp`, and prefer  
a private root-owned temporary directory if the script must be run manually.
Proposed Fix: Replace predictable temporary filenames with securely created  
files from `mktemp`, keep restrictive permissions, and quote the generated  
path consistently. The following minimal patch addresses the primary  
`pegasus` and `sfcb` cases; the same pattern should also be applied to  
`openwbem_install()`, `openwbem_uninstall()`, and  
`provider-register.sh.pegasus-interop`.
```diff
— a/provider-register.sh
+++ b/provider-register.sh
@@
   for _TEMPDIR in /var/tmp /tmp

   do

     if test -w $_TEMPDIR

     then

         _REGFILENAME=$_TEMPDIR/$$.mof

         break

     fi

   done
+    umask 077
+     
_REGFILENAME="$(mktemp "${TMPDIR:-/tmp}/provider-register.XXXXXX.mof")" ||  
return 1
@@

   trap "rm -f $_REGFILENAME" EXIT
+    trap 'rm -f – "$_REGFILENAME"' EXIT
@@

   if pegasus_transform $_REGFILENAME $myregs
+    if pegasus_transform "$_REGFILENAME" $myregs
@@

   for _TEMPDIR in /var/tmp /tmp

   do

     if test -w $_TEMPDIR

     then

         _REGFILENAME=$_TEMPDIR/$baseregname.reg

         break

     fi

   done
+    umask 077
+     
_REGFILENAME="$(mktemp "${TMPDIR:-/tmp}/provider-register.XXXXXX.reg")" ||  
return 1
@@

   if sfcb_transform $_REGFILENAME $myregs
+    if sfcb_transform "$_REGFILENAME" $myregs
```


------
This report was generated using AI technology. Always review AI-generated  
content prior to use


Note You need to log in before you can comment on or make changes to this bug.