A new Polkit vulnerability

Posted Jan 26, 2022 15:43 UTC (Wed) by mcatanzaro (subscriber, #93033)
In reply to: A new Polkit vulnerability by dmoulding
Parent article: A new Polkit vulnerability

It was embargoed. We can't begin building updated packages until after the embargo is lifted. If you break the embargo by preparing an update too soon, security people get mad. ;)

A new Polkit vulnerability

Posted Jan 26, 2022 16:51 UTC (Wed) by yodermk (subscriber, #3803) [Link] (12 responses)

Distro security teams can't BEGIN to build packages before the embargo is lifted??? I thought the point of the embargo was to allow the packages to be ready at a coordinated time when the vuln was disclosed.

A new Polkit vulnerability

Posted Jan 26, 2022 16:54 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (9 responses)

Fedora has fully open process, including what gets build in the build system and associated sources.

A new Polkit vulnerability

Posted Jan 26, 2022 17:28 UTC (Wed) by dmoulding (subscriber, #95171) [Link] (8 responses)

As far as I can tell, Fedora 35 users (don't know about other versions) still don't have a patch for this available to them. Which, again, is supposed to be, I think, the whole reason there's an embargo in the first place (so that users aren't left with unpatched systems waiting on fixes after public disclosure).

I get that the processes are open. But I guess that by definition means this is a process that doesn't accommodate the idea of security vulnerability embargoes (which by definition cannot be handled "in the open"). Seems there could be a way to be open with everything, except embargoed fixes. I'd imagine that would be exactly along the lines of what the people who came up with this convention of embargoing security vulnerability disclosure had in mind.

A new Polkit vulnerability

Posted Jan 26, 2022 18:21 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

I may be totally incorrect in my assumptions, but I don't think this is actually a huge problem for Fedora users in practice, due to a combination of several reasons:

1. The problem exists in pkexec, not Polkit in general.
2. This means that attackers must be able to execute arbitrary user-level programs in order to exploit the flaw.
3. Polkit is used mostly with desktop-style systems. Desktop-style systems are usually single-user, and that user has other ways of accessing root anyway.
4. Fedora is used much more widely as desktop systems than server systems, especially not as server systems where arbitrary users can upload arbitrary code to run (e.g. web site hosting with PHP).

Of course there are most likely huge Fedora-based machine farms in several organizations (universities maybe?) where arbitrary users do have unprivileged access that I'm simply not thinking about. Anyway, there's always "rm pkexec" as a temporary workaround.

A new Polkit vulnerability

Posted Jan 26, 2022 19:23 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

Normally it takes about two days to release an update for an urgent security issue, assuming the responsible packager reads bugmail regularly, notices on the first day, and no particular challenges with backporting the patch. Our infrastructure is not designed with speed as the top priority.

A new Polkit vulnerability

Posted Feb 3, 2022 12:22 UTC (Thu) by RedDwarf (guest, #89472) [Link]

Some statistics of how often an updates-testing package doesn't go to updates would help people make an informed decision here.
- Do I want "testing"? No.
- Do I want "fast"? Yes.
Since I need to compromise, I want to know how faster is fast, and how pre-tested is testing.

A new Polkit vulnerability

Posted Jan 26, 2022 19:36 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (3 responses)

Your first sentence is wrong. Patched package was pushed to stable repositories at 2022-01-26 17:00:37 UTC (half hour before your comment).
It was available the testing repository since yesterday.
The package was built at 25 Jan 2022 18:11:31 UTC (https://koji.fedoraproject.org/koji/buildinfo?buildID=190...).
The code changes landed in the repo yesterday at 17:51:47 UTC (https://src.fedoraproject.org/rpms/polkit/c/a55ef1ff5db9b...)

That's for nitpicking. As for your main point – yes, Fedora openness does not align with embargoes. Only way to prepare packages earlier would be to use some shadow build infrastructure, not widely visible. That would mean losing transparency, thus losing trust which is double important for security updates.

Actually, there is another way. Commits, builds, repo composes could get metadata tag like "notVisibleBefore" set to embargo lift timestamp. Before that time, it should only show changes to the owner. But this would require really intrusive surgery in many components (starting with git). It's unfeasible.

A new Polkit vulnerability

Posted Jan 26, 2022 20:05 UTC (Wed) by dmoulding (subscriber, #95171) [Link] (1 responses)

$ sudo dnf update polkit
Fedora 35 - x86_64                               37 kB/s |  13 kB     00:00    
Fedora 35 openh264 (From Cisco) - x86_64        4.2 kB/s | 989  B     00:00    
Fedora Modular 35 - x86_64                       46 kB/s |  13 kB     00:00    
Fedora 35 - x86_64 - Updates                     35 kB/s |  10 kB     00:00    
Fedora 35 - x86_64 - Updates                    504 kB/s | 447 kB     00:00    
Fedora Modular 35 - x86_64 - Updates             45 kB/s |  13 kB     00:00    
Dependencies resolved.
Nothing to do.
Complete!

I just did that. So still no update available to me on this system. Not sure why if the patched build was available already.

But as to the feasibility, why is it infeasible to have closed infrastructure on which to make commits, do builds and test? Then when an embargo is lifted, the commits can be pushed to the public repo, builds done and released immediately, without having to wait for testing. Doesn't on the surface seem infeasible to me, but admittedly I'm not a developer for any distro (let alone Fedora) so I don't know what nuances would make this impractical.

A new Polkit vulnerability

Posted Jan 26, 2022 20:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> I just did that. So still no update available to me on this system. Not sure why if the patched build was available already.

The patched builds are available in updates-testing repo. The commits go into a spec + patches repo in https://src.fedoraproject.org/ and then the builds happen via https://koji.fedoraproject.org/koji/

Once the builds are available there, Bodhi is used to push the updates to updates-testing for public comments and testing via https://bodhi.fedoraproject.org/

In this case, for Fedora 35, this is the errata

https://bodhi.fedoraproject.org/updates/FEDORA-2022-da040...

dnf install <foo> --enablerepo=updates-testing

> But as to the feasibility, why is it infeasible to have closed infrastructure on which to make commits, do builds and test?

It isn't infeasible but it is considerable amount of work to duplicate a good amount of the infrastructure somewhere privately, find the resources to test it privately and push it out slightly earlier while still allowing community volunteers to participate.

A new Polkit vulnerability

Posted Jan 26, 2022 22:29 UTC (Wed) by brunowolff (guest, #71160) [Link]

There is more to it than just getting pushed to stable for naive users. (People who know can get the build directly from koji. But you need to know you want the update.)
Composes of repos typically happens once a day with the set of packages in stable at around 0500 UTC. Typically the compose finishes 8 to 10 hours later and gets copied to the primary source for distribution. Before most people see the change, it needs to be copied to the mirror they use. I think some pick them up pretty quickly, but others might only check once a day.

If you happen to be using rawhide right now, composes have been failing more than usual the last week, including the last two days. If this threat is a high priority for you (e.g. if you have multiple users on your system that you don't fully trust to behave), then you need to pull a copy from koji or from this morning's failed compose (which will have a lot of updates).

A new Polkit vulnerability

Posted Jan 27, 2022 9:09 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> I get that the processes are open. But I guess that by definition means this is a process that doesn't accommodate the idea of security vulnerability embargoes

Embargoes are predicated on the idea components are independant and you can prepare an update in a sekret top security facility isolated from everything else.

In reality modern components are deeply interdependant, moving one part echoes far and wide, and requires notifying lots of people (see: log4j).

A new Polkit vulnerability

Posted Jan 26, 2022 19:13 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

Well packagers can of course prepare things locally in advance, but if you make public commits or use public build infrastructure, then you've broken the embargo. So yeah, the actual process of building the update cannot begin until after the embargo has ended.

Distros with private infrastructure (e.g. RHEL) are able to prepare more easily.

A new Polkit vulnerability

Posted Feb 5, 2022 2:30 UTC (Sat) by xnox (guest, #63320) [Link]

I don't see how being open prevents to be integrated with embargoes. Ubuntu uses Launchpad, which supports private builds, but also converting private builds to public. It allows building update privately, and publishing them publically which at publication time reveals source code and full build-logs.

If there were enough resources committed, surely koji / fedora could implement the same. Push private tags, do builds, and unembargo them at publication time. A missing build infrastructure feature, and lack of timely security support. Not really anything to do with "openness".