Merge branch 'main' into dependabot/npm_and_yarn/npm_and_yarn-40d86643b0

garloff · web-flow · commit bfa7998badcd · 2026-06-01T18:09:39.000+02:00
diff --git a/blog/2026-05-10-kernel-root-exploits.md b/blog/2026-05-10-kernel-root-exploits.md
@@ -81,6 +81,26 @@ _Exploiting these vulnerabilities requires access to the system and the ability
 to execute code there, thus the categorization as Local Privilege Escalation (LPE),
 not Remote Code Execution (RCE)._
 
+## Update 2026-05-13: Fragnesia
+
+Yet another network fragment handling issue which fails to properly prevent
+in-place en/decryption which can be made to hit sensitive page cache contents
+that was put there with splice has been discovered with
+[Fragnesia](https://www.openwall.com/lists/oss-security/2026/05/13/3).
+It's a simple logic error where the sharing property is forgotten in buffer
+coalescing. It has gotten CVE-2026-46300.
+
+## Update 2026-05-15: ssh-keysaign-pwn
+
+This LPE is unrelated to the others; under certain circumstances, the kernel
+fails to prevent the dumping of process memory under ptraces, which can be used
+to read out sensitive data. As it can be used to read e.g. ssh keys, it has been called
+[ssh-keysign-pwn](https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn). It has
+gotten CVE-2026-46333.
+
+This vulerability allows local attackers to read sensitive data (Information
+Disclosure - ID) which may be useful to escalate privileges.
+
 ## Impact
 
 Any system where normal (non-root) users can log in to execute code under their
@@ -124,18 +144,20 @@ The fixes for Dirty Frag are still in development as of May 8. The first fixes
 have been merged upstream and released in 7.0.5, 6.18.28, 6.12.87, 6.6.138,
 6.1.172, 5.15.206 and 5.10.255 but there is
 [more to come for rxrpc](https://lwn.net/ml/all/2026050859-ahead-anchovy-05e2@gregkh/).
+Update 2026-05-11: 7.0.6 and 6.18.29 contain this last patch, older kernels don't need it.
 The responsible disclosure process for Dirty Frag unfortunately failed due to the
 [patches being spotted](https://www.openwall.com/lists/oss-security/2026/05/07/12),
 so the upstream maintainers and the distributors this time did not have time
 to carefully prepare and test fixes ahead of the publication of the issue.
 So we have to expect that it will take a few days until all Linux distributor
-manage to ship tested fixed kernels.
+manage to ship tested fixed kernels. Alma Linux has done so already, others are
+expected to follow soon.
 
 A fully effective workaround is again to prevent loading the affected modules
 by placing another file `dirtyfrag.conf` in `/etc/modprobe.d/`:
 
 ```shell
-# Temporary workaround for Dirty Frag CVE-2026-43284, CVE-2026-43500
+# Temporary workaround for Dirty Frag CVE-2026-43284, CVE-2026-43500, CVE-2026-46300
 # This breaks IPsec
 install esp4 /bin/false
 install esp6 /bin/false
@@ -144,6 +166,16 @@ install rxrpc /bin/false
 
 Note that these workarounds prevent IPsec from working.
 
+Update 2026-05-15: This mitigation helps against Fragnesia as well; AppArmor preventing
+unprivileged user namespaces (ubuntu) also helps. While a patch
+for Fragnesia was proposed, a fix has not been merged into the upstream kernel yet.
+Alma Linux has gone ahead and published a fixed kernel anyhow (for testing).
+
+Update 2026-05-15: The stable kernels 7.0.8, 6.18.31, 6.12.89, 6.6.139, 5.15.207, and
+5.10.256 contain a fix for the ptrace vulnerability (CVE-2026-46333 aka ssh-keysign-pwn).
+The latter is hard to mitigate, as there's no Security Module hook. Setting up a seccomp
+that disallows ptrace would help.
+
 If a system is suspected to already have been exploited, the system owner can
 dispose of the page cache by doing `echo 3 > /proc/sys/vm/drop_caches` as root
 and unload the affected modules to prevent re-exploitation.
@@ -211,7 +243,7 @@ key or to use a tool like kubectl-node-shell with the appropriate
 privileges.
 
 ```bash
-for node in $(kubectl get nodes | grep -v '^NAME' | awk '{print $1;}') do;
+for node in $(kubectl get nodes | grep -v '^NAME' | awk '{print $1;}'); do
   kubectl node_shell "$node" -- bash -c 'echo -e "# Temporarily disable algif_aead (copy.fail)\ninstall algif_aead /bin/false" > /etc/modprobe.d/disable-aead-copyfail.conf'
   kubectl node_shell "$node" -- bash -c 'echo -e "# Temporarily disable esp4, esp6, rxrpc (Dirty Frag)\ninstall esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false" > /etc/modprobe.d/disable-esp46-rxrpc-dirtyfrag.conf'
 done
@@ -235,10 +267,40 @@ in the meantime, as advised above.
 The SCS community infrastructure was secured on May 8 by disabling the
 relevant modules.
 
+## Outlook
+
+The density with which severe issues are currently found is notable. While the
+research in the referenced issues originated from human beings being suspicious
+that certain things were not handled correctly everywhere, they were assisted
+by AI tools in the search. This pattern is likely to turn up a relevant number
+of such issues which are reachable now using such help until we may enjoy a
+more quiet time again. Until a new class of weaknesses comes into the reach of
+yet more powerful AI tools.
+
+The other notable thing is that the quiet closing of issues within the Linux
+Kernel no longer works which has broken the responsible disclosure process
+that gave defenders some headway against attackers. One reason is that
+once a pattern emerges, several teams compete for speed to find related issues
+and decide in favor of disclosing before someone else finds it also. Another
+reason is that there are people that now use AI tools to analyze merged bugfixes
+to the kernel using AI tools - the fact that they are not flagged as security
+issues no longer is a good cover. So software distributors need to expect more
+of these occurences where they are struggling to patch software, validate the
+fixes and ship to customers before large-scale attacks happen. Operators will
+need to be fast as well.
+
+So yes, the times are changing in software security and open source software is
+hit first being the most accessible to security researchers. On the proprietary
+side, we can suspect similar research is happening, but whether the research
+teams also go for fame and visibility or maybe have other prevalent incentives
+is an open question.
+
 ## Thanks
 
 The authors would like to thank Taeyang Lee at Xint (who initiated the
 research on copy.fail) and Hyunwoo Kim (@v4bel, who discovered Dirty Frag).
+Update 2026-05-15: They would also like to acknowledge William Bowling (V12) for Fragnesia
+and Jann Horn and Qualys for ssh-keysign-pwn.
 They would also like to thank the upstream Linux kernel maintainers and
 Linux distributors for their reliable work no handling the issues and
 getting fixes out.
@@ -254,3 +316,6 @@ SCS security contact is [security@scs.community](mailto:security@scs.community),
 - kubectl node-shell instructions, v0.2, 2026-05-09, 12:45 CEST.
 - Mention succssful patching of community infra, v0.3, 2026-05-09, 13:30 CEST.
 - Correct facts on the failure of the responsible disclosure. Release as v1.0, 2026-05-09, 20:00 CEST.
+- Update on final rxrpc fix in stable kernels. v1.1, 2026-05-12, 08:45 CEST.
+- Add Fragnesia and ssh-keysign-pwn LPEs. v1.2, 2026-05-15, 17:15 CEST.
+- Add note on AI changing the game (outlook). v1.3, 2026-05-15, 17:30 CEST.
diff --git a/blog/2026-05-28-keystone.md b/blog/2026-05-28-keystone.md
@@ -0,0 +1,126 @@
+---
+title: Multiple Keystone vulnerabilities affecting credential delegation and authorization (OSSA-2026-015)
+authors: [garloff]
+slug: keystone_credential_delegation_auth_bypass_ossa_2026_015
+tags: [security, openstack, keystone, cve]
+---
+
+## The vulnerabilities
+
+A series of five related vulnerabilities has been identified in OpenStack
+Keystone that impact how credentials are delegated and how authorization
+policies are enforced. These vulnerabilities allow authenticated attackers to
+bypass security boundaries, impersonate users, and potentially escalate
+privileges to cloud administrator.
+
+The core issues are:
+
+- **RBAC Policy Bypass (CVE-2026-42999):** An attacker can inject RBAC policy
+  targets via a JSON request body, allowing them to bypass authorization on
+  protected endpoints. This can lead to the reading of credential secrets and
+  escalation to cloud admin.
+
+- **Application Credential Impersonation (CVE-2026-42998 & CVE-2026-43000):**
+  Keystone failed to verify if the caller owned the Application Credential
+  being used. This allows for user impersonation within a project, which can be
+  chained with "trust" operations to escalate privileges from a project member to
+  an administrator.
+
+- **Cross-Project EC2 Credentials (CVE-2026-43001):** Application credentials
+  scoped to one project could be used to create EC2-style credentials for a
+different project, enabling lateral movement across tenant boundaries.
+
+- **Federated Token Rescoping (CVE-2026-44394):** In SAML2/OIDC deployments,
+  federated users can maintain access indefinitely by repeatedly rescoping
+  tokens, as Keystone issues a fresh full-TTL token instead of inheriting the
+  original expiry.
+
+These issues were reported by Boris Bobrov (SAP SE), Tim Shepherd (roiai.ca),
+Erichen (Institute of Computing Technology, CAS), and Artem Goncharov
+(SysEleven GmbH).
+
+## Impact on the SCS software ecosystem
+
+These vulnerabilities pose a significant risk to SCS clouds. Because SCS
+environments rely heavily on S3 compatibility—which utilizes EC2-style
+credentials—the ability to perform cross-project lateral movement
+(CVE-2026-43001) is a direct threat to tenant isolation.
+
+Furthermore, the RBAC bypass (CVE-2026-42999) is particularly severe as it
+undermines the fundamental security model of the cloud, potentially allowing an
+authenticated user to gain full administrative control over the entire Keystone
+service. For deployments using federated identity (SAML2/OIDC), the ability to
+bypass session expiration (CVE-2026-44394) also weakens the security posture
+regarding user lifecycle management.
+
+## Embargo
+
+The issues were reported to the OpenStack Vulnerability Management Team.
+Following coordination with the reporters and upstream developers, the official
+OpenStack Security Advisory
+[OSSA-2026-015](https://security.openstack.org/ossa/OSSA-2026-015.html) was
+published on Tuesday, 2026-05-28.
+
+## Mitigation and Fixes
+
+The primary remediation is to upgrade Keystone to the patched versions provided
+by the upstream OpenStack project.
+
+**Note:** For users with highly customized trust policies, please be aware that
+the fix for CVE-2026-42999 modifies the trust policy structure. This may
+require manual updates to your custom policies to ensure continued
+functionality for services like Heat or image uploads.
+
+The SCS ecosystem software providers are providing fixed Keystone images:
+
+- [OSISM](https://osism.tech/docs/appendix/security/ossa-2026-015)
+- [yaook](https://yaook.cloud/security-advisories-cve-2026-33551)
+
+## Outlook
+
+We see an increased velocity with which security issues are found in the
+IT industry. We're glad to see them reported against the open source projects
+that we are using and the community is working hard to address the issues.
+Security researchers have become more efficient due to the usage of AI tools
+and so have OSS developers - we expect the high volume to continue for the
+upcoming months and maybe beyond.
+
+SCS has always emphasized the ability to patch with confidence on a daily basis
+as an important design criterium for the lifecycle management of our components.
+It now seems to be needed more than ever. We advise operators to prepare for
+this new world and ensure to work on any processual issues that are slowing
+them down in deployment.
+
+## References
+
+- [OSSA-2026-015 Advisory](https://security.openstack.org/ossa/OSSA-2026-015.html)
+- [Launchpad Bug #2148398](https://bugs.launchpad.net/keystone/+bug/2148398),
+  [#2148477](https://bugs.launchpad.net/keystone/+bug/2148477),
+  [#2149775](https://bugs.launchpad.net/keystone/+bug/2149775),
+  [#2149789](https://bugs.launchpad.net/keystone/+bug/2149789),
+  [#2150089](https://bugs.launchpad.net/keystone/+bug/2150089),
+  [#2150379](https://bugs.launchpad.net/keystone/+bug/2150379)
+- [CVE-2026-42998](https://www.cve.org/CVERecord?id=CVE-2026-42998),
+  [CVE-2026-42999](https://www.cve.org/CVERecord?id=CVE-2026-42999),
+  [CVE-2026-43000](https://www.cve.org/CVERecord?id=CVE-2026-43000),
+  [CVE-2026-43001](https://www.cve.org/CVERecord?id=CVE-2026-43001),
+  [CVE-2026-44394](https://www.cve.org/CVERecord?id=CVE-2026-44394)
+
+## Thanks
+
+The author would like to thank Boris Bobrov, Tim Shepherd, Erichen, and Artem
+Goncharov for their work in discovering and reporting these critical
+vulnerabilities and the OpenStack Vulnerability Management Team for handling
+and coordinating this and the OpenStack Keystone upstream developers for
+addressing the issues.
+
+## Sovereign Cloud Stack Security Contact
+
+SCS security contact is
+[security@scs.community](mailto:security@scs.community), as published on
+[https://sovereigncloudstack.org/.well-known/security.txt](https://sovereigncloudstack.org/.well-known/security.txt).
+
+## Version history
+
+- Initial draft, v0.1, 2026-05-28, 16:00 CEST
+- Release, v1.0, 2026-05-29, 12:00 CEST
diff --git a/community/tools/zuul.md b/community/tools/zuul.md
@@ -2,7 +2,7 @@
 
 ## Zuul CI/CD pipelines and project gating
 
-Since we are expecting a lot of pipelines beeing created and used GitHub actions won't keep up
+Since we are expecting a lot of pipelines being created and used GitHub actions won't keep up
 well. We also expect cross-repository and even cross-project dependencies. Therefore we decided to
 use Zuul as our main pipeline solution.
 
@@ -19,9 +19,9 @@ Note: This needs to be updated!
     - the merge-mode which should be used to auto-merge
     - the jobs to run in each pipeline (gh_check, gh_gate, gh_post, gh_tag)
     - these [pipelines](https://github.com/SovereignCloudStack/zuul-config/blob/main/zuul.d/) are triggered by events
-    - ihere are [some default jobs](https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks)
+    - here are [some default jobs](https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks)
 - If you have _self-defined_ jobs, you need to create a folder _.playbooks_
-  - this folder containers ansible playbooks which will be triggered
+  - this folder contains ansible playbooks which will be triggered
 
 ### General information about Zuul
 
