| gouthamr | zigo: o/ can you share the reporter and their affiliation for https://review.opendev.org/c/openstack/ossa/+/1006123 please | 14:16 |
|---|---|---|
| zigo | gouthamr: I don't think I have the info, but let me check yeswehack. | 14:17 |
| gouthamr | ++ ty | 14:18 |
| zigo | The nickname is "Rolix", I don't think I have more. | 14:18 |
| zigo | Except the person is from France. | 14:19 |
| gouthamr | zigo: ah, https://hackerone.com/rolix ? we could add "Rolix", and if they'd like to confirm their name/affiliation later, we could do so via an errata update | 14:20 |
| zigo | gouthamr: Looks like it could be the same person, yes. | 14:24 |
| opendevreview | Goutham Pacha Ravi proposed openstack/ossa master: Add OSSA-2026-039 (CVE-2026-pending) https://review.opendev.org/c/openstack/ossa/+/1006123 | 15:35 |
| gouthamr | fungi: rosmaita JayF ^ and https://review.opendev.org/c/openstack/ossa/+/1006088 have both gotten +1s from the respective PTLs, could you please review.. i'm hoping to send these out today :) | 15:39 |
| fungi | thanks, will look shortly | 15:39 |
| rosmaita | ack | 15:40 |
| gouthamr | https://bugs.launchpad.net/keystone/+bug/2158970 is now public | 15:41 |
| JayF | gouthamr: https://review.opendev.org/c/openstack/ossa/+/1006088 +2 (but it's -40 and -39 hasn't merged so I will let your workflow; looking at the other one now) | 16:28 |
| JayF | +2 here too now https://review.opendev.org/c/openstack/ossa/+/1006123 | 16:29 |
| gouthamr | ty JayF rosmaita | 16:29 |
| JayF | https://bugs.launchpad.net/ironic/+bug/2166499 is now public | 16:30 |
| fungi | gouthamr: i approved both ossa-2026-039 and -040 just now, thanks! | 16:56 |
| gouthamr | ah! ty fungi .. /me preps emails | 16:57 |
| fungi | i'm also around for moderating openstack-announce | 16:57 |
| opendevreview | Merged openstack/ossa master: Add OSSA-2026-039 (CVE-2026-pending) https://review.opendev.org/c/openstack/ossa/+/1006123 | 17:00 |
| opendevreview | Merged openstack/ossa master: Add OSSA-2026-040 (CVE-2026-93852, CVE-2026-93854) https://review.opendev.org/c/openstack/ossa/+/1006088 | 17:04 |
| JayF | JFYI; I just delegated to sarhiri implementing yamllint on security-notes in security-doc repo, using the OSSA yamllint change as an example | 17:08 |
| fungi | sgtm | 17:10 |
| fungi | thanks! | 17:10 |
| * gouthamr emails sent about OSSA-039 and OSSA-040 | 17:11 | |
| JayF | If there are other doc cleanups, security or otherwise, that would be good for her queue please let me know | 17:11 |
| * gouthamr mitre informed to publish blazar CVEs, and told about OSSA-2026-039 - when they assign CVEs, i'll file an errata | 17:20 | |
| fungi | i'm still somewhat confused on ossa-2026-039... in https://bugs.launchpad.net/ossa/+bug/2162101 comment #4 i asked about this, and responses led me to believe that each tenant has their own separate amphora vm | 17:22 |
| fungi | and that its access was isolated to their tenant networks | 17:23 |
| gouthamr | escalating to root and escaping the network namespace was demonstrated - network isolation is defense in depth.. i asked gthiemonge if there's any written guideline on network isolation on the host being a mandatory requirement.. | 17:24 |
| fungi | i guess the actual architecture is a kernel-level container per tenant on a shared amphora vm then? | 17:25 |
| fungi | rather than an amphora per tenant | 17:25 |
| fungi | i'll have to take a closer look at the new poc exploit, but if it relies on kernel bugs to escape the namespace and elevate privileges... | 17:27 |
| gouthamr | i didn't see the need to exploit any kernel bug; i do see: "HAProxy runs in master-worker mode and the master process forks program commands before dropping to user nobody, so the injected command runs as uid=0." | 17:30 |
| fungi | oh, so it's a shared haproxy process across all tenants? interesting design choice | 17:31 |
| JayF | fungi: IDK about that, but... https://opendev.org/openstack/octavia/src/branch/master/octavia/common/config.py#L487 | 17:32 |
| fungi | er, looks like a shared execution environment for individual haproxy daemons | 17:32 |
| JayF | all amphorae end up connected into a shared network determined by config | 17:32 |
| JayF | which means by definition it's not gonna be tenant isolated | 17:33 |
| fungi | i guess they assumed the only think haproxy could do was make network connections and so network namespace isolation would suffice | 17:33 |
| fungi | er, the only thing | 17:33 |
| fungi | yeah, my bigger concern was why does one tenanant's amphora have access to private ssl keys for another tenant, but i guess if they all share a common vm then you only need to escalate to vm root | 17:35 |
| gouthamr | that language comes from this: https://bugs.launchpad.net/octavia/+bug/2162101/comments/2 | 17:37 |
| JayF | so this is muddied some | 17:39 |
| JayF | because there's the operator tenant (the one who said "gimme a load balancer") | 17:39 |
| JayF | but octavia itself is using a service cred -- and I would assume that is a part of a dedicated service project | 17:40 |
| JayF | each LB gets it's own dedicated VM pair, the only shared resources that used to exist AFAICT is an old concept of having warm spares shared | 17:40 |
| JayF | ^ was assisted by opencode+deepseek pro latest, but my reading of the code reinforces those findings | 17:40 |
| JayF | fungi: https://opendev.org/openstack/octavia/src/branch/master/octavia/db/models.py#L685 amphorae are indexed by load_balancer_id; | 17:42 |
| JayF | LoadBalancer has project awareness mix-in: https://opendev.org/openstack/octavia/src/branch/master/octavia/db/models.py#L405 | 17:42 |
| JayF | so I'd say this is sorta, a link in the chain | 17:46 |
| JayF | hmm. | 17:47 |
| * JayF makes sure they aren't using shared MTLS creds | 17:47 | |
| fungi | okay, so no shared vm... rce on the amphora used to access the control-plane network and then use its credentials to fetch other tenants' data from the api | 17:47 |
| gouthamr | from my understanding, yeah. RCE can enumerate the "amphora filesystem" reachable via the ctl plane network | 17:49 |
| JayF | it looks like the cred at risk is the one on disk on the amphorae used to communicate between amphorae<>octavia ^ | 17:49 |
| JayF | but the private key for the CA used by the amphorae don't get on there, only a server-specific private key against that CA | 17:50 |
| JayF | so I think our OSSA is written extra paranoid, but I don't hate it in this case. This is a significant amount of access even if you can't connect all the dots with openstack alone. | 17:50 |
| fungi | yeah, makes sense | 17:50 |
| fungi | so thinking about this general class of problem a bit more, it seems like from a security sig perspective we might want to extend our secure development guidelines with architectural advice like services utilizing per-tenant worker virtual machines need to isolate those workloads from the control-plane/management network, use per-tenant keys to prevent one compromised vm | 18:18 |
| fungi | from fetching another tenant's data from the api... | 18:18 |
| fungi | not just for octavia but but trove, magnum, anything else that has a similar model | 18:19 |
| JayF | I would be mildly concerned that there's not a good blanket rule that could apply across the projects | 18:21 |
| JayF | I tried to go down this route (with a non-security bend) once, and it became clear that the "utility VM" use cases were split enough there wasn't a lot of commonness to pull out | 18:21 |
| fungi | ah, too bad | 18:21 |
| opendevreview | Goutham Pacha Ravi proposed openstack/ossa master: OSSA-2026-039: Errata 1 https://review.opendev.org/c/openstack/ossa/+/1006643 | 21:12 |
| fungi | gouthamr: i posted a quick question on ^ | 21:53 |
| opendevreview | Goutham Pacha Ravi proposed openstack/ossa master: OSSA-2026-039: Errata 1 https://review.opendev.org/c/openstack/ossa/+/1006643 | 21:58 |
| gouthamr | ty fungi - good catch! | 21:58 |
| fungi | gouthamr: so they both reported CVE-2026-94572 and nobody reported CVE-2026-94571 ? | 22:00 |
| fungi | or was that an incorrect edit? | 22:00 |
| gouthamr | incorrect edit | 22:04 |
| opendevreview | Goutham Pacha Ravi proposed openstack/ossa master: OSSA-2026-039: Errata 1 https://review.opendev.org/c/openstack/ossa/+/1006643 | 22:05 |
| fungi | okay, so one of them reported both and the other independently reported one of them too | 22:09 |
| gouthamr | yes, both reporters found CVE-2026-94572 (tls_cipher line of the haproxy configuration).. but, CVE-2026-94571 is very similar, different line (redirect_url) | 22:11 |
| fungi | perfect. i'm also on hand to moderate the openstack-announce post | 22:12 |
| gouthamr | passed check, so sent those emails | 22:20 |
| fungi | and accepted through moderation | 22:21 |
| gouthamr | ++ ty fungi | 22:21 |
| gouthamr | heads up that blazar needs an RC2, after https://review.opendev.org/c/openstack/blazar/+/1006050 merges.. i've told the maintainers to get that worked out through the release team | 22:22 |
| fungi | yep, saw that | 22:22 |
| fungi | i'll be on the lookout for it | 22:23 |
| gouthamr | ++ | 22:23 |
| fungi | added to my reminders | 22:23 |
| opendevreview | Merged openstack/ossa master: OSSA-2026-039: Errata 1 https://review.opendev.org/c/openstack/ossa/+/1006643 | 22:24 |
| *** mrunge_ is now known as mrunge | 23:58 | |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!