https://github.com/ubuntu/authd/security/advisories/GHSA-g8qw-mgjx-rwjr

When a user who hasn't logged in to the system before (i.e. doesn't exist in the authd user database) logs in via SSH, the user is considered a member of the root group in the context of the SSH session. That leads to a local privilege escalation if the user should not have root privileges.

@cR0w There’s TOFU and there’s TOFU

@cR0w but Mark Shuttleworth only hires the finest high school valedictorians after a 12 month hazing process posing as an interview!

@cR0w No way this is "moderate" lmao, how is an LPE C:L/I:L/A:N?

@cR0w I love how they're downplaying this. It's obviously C:H/I:H/A:H, but of course they're not admitting to that.

@cR0w good move

@cR0w Yup good call, imo this is blatantly just engineering the score to stay below 7.0/High.

@cR0w lol. Lmao even.

@cR0w W-H-A-T?

@cR0w I like the workaround, "do not use this software". A beautiful universally applicable workaround for any vulnerability.

@cR0w

@cR0w I love a disposable root shell

@cR0w Canonical is truly a gift that keeps on giving

@cR0w if only the CVSS v4.0 example guide had thought to include an SSHD example vulnerability like regreSSHion as an example of how to classify such bugs. Then they’d have had clear guidance that nothing has changed about this in the last decades

@cR0w

@f4grx @cR0w yoooo....!

@cR0w The hivis and clipboard of invisibility aren't meant to get you C-suite permissions!

@f4grx @cR0w but remember! Everyone saying systemd and snaps and authd are all terrible fucking ideas by terrible fucking people who continually and repeatedly demonstrate forcefully they have no fucking clue is just a hater and wrong!

Also don't point out that sssd identified this as a possible issue... well, was before $jobF so at least 10 years or so?

@cR0w "Knock knock."
"Who's there?"
"God."
"If you say so, right this way sir!"

@cR0w @f4grx the fucking *irony* is that sssd and systemd are both Red Hat projects.

@cR0w "boy, if only there was a solution to the problem we created 👉👈 ...maybe if you gave us some money???"

@cR0w if only there was a better systems programming language that this stuff could be written in that would avoid these sort of errors. Hypothetically it would be ideal for this sort of security sensitive project :(

@cR0w oh, I'm not golang proficient, but it looked like go was defaulting a struct member to zero, rather than flagging that it hadn't been initialized?

@cR0w nobody knows that “failures happen” more than incident response teams, so perhaps they’ll correct it. But the docs are clear, and FIRST even publishes guides for PSIRTs on how to handle security bulletin releases. Vulns like this need to be scored correctly so they get patched correctly, investigated correctly, etc. If a score like this persisted through internal investigations and external publications, that could be a great deal worse than just the public announcement side. I sincerely hope scoring and validation wasn’t a single persons responsibility, regardless of seniority. And more than one person should’ve touched this since quite some time.

@cR0w @patcharcana

@cR0w @yomimono Luckily, there's a simple fix for this. Just give all users root privileges, and then the behavior will be correct and the privilege escalation bug goes away.

@cR0w
PAM - 1001 ways to shoot yourselves into the foot.

@cR0w @Dio9sys I bet you #skiddies gonna go #cryptojacking #Monero tonite...

@kkarhan @cR0w I have no idea who is the character on this gif, but I found her fun, saved it, and today is the perfect occasion to repost her 😁

@f4grx @cR0w it's "Kizuna AI"

@rootwyrm @cR0w @f4grx also this isn't a #smSystemD nor #snap issue!

@cR0w @redsakana yeah...

@cR0w @srtcd424 really?

WTF!?

@angusm @cR0w @yomimono ah, I see you're familiar with modern DevOops.

@cR0w

@cR0w hmm, that looks like test data? Though it is explicitly 0 there before the patch, which might imply intention .. or maybe someone just set the test data to what the code was currently doing? Ugh ..

@da_667 @cR0w MY CVE-ITIS

@cR0w at least it's not in something fundamentally core to the function of the network-connected OS...

Oh fuck off.

@cR0w im fuckin losing it

@cR0w why would anyone run ubuntu over Debian, like for real?

@cR0w sure hope everybody has properly configured service users without login shells!

@cR0w
David Attenborough voice:
"As a sign of cooperation, the wild server offers a reciprocal 'root on first use' to the user's 'trust on first use'..."

@cR0w this is even more hilarious than the cryptography bug my partner found last year https://github.com/ubuntu/authd/security/advisories/GHSA-4gfw-wf7c-w6g2

That one at least had subtlety

@cR0w
I was hired basically straight out of highschool to work for Shuttleworth. I barely even remember having an interview I was kinda just... hired. He was a really chill dude but a lot of the people at Canonical are really shitty to others
@rootwyrm

@cR0w wat?

@cR0w
YUP XD
@rootwyrm

@cR0w @angusm @yomimono This is the root cause.

@cR0w
Who amongst us hasn't accidentally written "if User = 'Not Found', Admin = true"?

@cR0w It was such a good quality bait, I'm a master in that class

@cR0w

@cR0w pity there wasn't some kind of daemon running that could tale care of root thingys for SSH.

@cR0w @jerry vibe coding before it was cool

@cR0w this might go back all the way to the start of systemd

@cR0w Canonical QA tester: ssh login works ✅

@cR0w SuSE sponsors a project with similar goals (and hopefully less security bugs): https://github.com/himmelblau-idm/himmelblau

@cR0w @fre > The stable PPA release of authd can be used today as an authentication service. This project is under active development and the release of authd to the official archive is planned for Ubuntu 26.04 LTS.

Gives a slightly mixed message.

@cR0w Is it a local privilege escalation when it involves a remote shell?

@cR0w I can't help but ask... what does this tell us about authd, if anything? Shouldn't it fail closed and use design techniques to ensure that it fails closed?

@cR0w

@cR0w ummm, ok, and uhhhh, what happens if GID 1234 is in use? Shouldn't this be an explicit failure case?

@cR0w you mean cvss?

@buherator @cR0w how else are we going to get companies to pay maintenance fees for free software?

@cR0w

@cR0w so is this on all Ubuntu computers?

@rootwyrm @cR0w @f4grx

What. A. Surprise.

@cR0w
Isn't authd currently only distributed via PPA?
Do they really provide security updates for PPA packages in Ubuntu Pro?

@cR0w what are you talking about? the patch is not behind any kind of subscription

@cR0w
Yeah, that's a very dubious practice.

But I think it should be made clear that this vulnerability does not affect most users because it isn't installed by default, and doesn't get installed "accidentally" either because it requires adding a PPA.

(Could be that there are cloud VM images that have it preinstalled, IDK)

@cR0w "// TODO: Should we set the GID to something else than 0 (i.e. the GID of the root primary group)?"

*emits a sigh deeper than the Mariana Trench*

@cR0w That description was AI-generated, wasn't it?

@cR0w @Doomed_Daniel

Yes, if you installed and configured authd and an authd broker, you should check if you're affected, and update the packages. However, I doubt that someone "forgets" that they did this, because it means they set up an OIDC app in Entra ID or Google IAM and went through the extensive configuration of authd and the authd broker.

@cR0w I presume this is some kind of auto-account provisioning feature?

@Doomed_Daniel that's correct.
@cR0w is just wrong.

@cR0w @Doomed_Daniel

The updates are part of a PPA: https://launchpad.net/~ubuntu-enterprise-desktop/+archive/ubuntu/authd/+sourcepub/17413382/+listing-archive-extra

Just check https://launchpad.net/~ubuntu-enterprise-desktop/+archive/ubuntu/authd/+packages for details.

It's all clearly released to everyone that uses authd (clearly an opt-in choice)

@cR0w @fre imho the description looks more dangerous than it is...

Try to get an user on root group, tell me, what operations can you really do? Really few things give root group important privileges.

@lanodan @cR0w it does.

There's no other way the user group can be initialized, unless you know the code better.

@cR0w @Doomed_Daniel well... I replied while going through the thread.

But for sure the first messages were doing false accusations regarding Pro or anything like that, so I feel it's relevant to underline a message when it's hot correct.

@cR0w @fre it was mostly due to the SSH architecture (and happening only there), that we'll change upstream soon.

Anyways we all agree that this a bad bug (even thought I think we had worse), but despite what you seem to suggest, it was handled openly and doing all the proper steps.

Shit happens in any project, can't really tell we did anything wrong in the way we handled it.

@cR0w @fre indeed nobody wants a cookie, but any behavior was criticized, while we just followed standard procedures.

Regarding PRO, it's completely another topic as you finally realized, but no main package in Ubuntu is not getting security updates.

@cR0w @3v1n0
with > 500 boosts your original post clearly got a much wider audience than people who know you

@cR0w @Doomed_Daniel @3v1n0 Clearly many users responsing to your post misunderstood various things about this vulnerability:
* It does not give access to unauthenticated Users
* It does not affect all/most Ubuntu systems
* It does not affect default configurations

The misunderstandings are not your fault, but you boosted many of those replies which were clearly made under wrong assumptions.

@cR0w A tip for anyone designing authentication mappers like this that can make it significantly less problematic if you forget to initialize the UID and/or GID values in all paths: If you can't use an explicit "UIDisSet" boolean next to it that's checked before handoff, explicitly initialize them to 65534 for 'nobody' so if something forgets to set it, you get nobody instead of root...

@cR0w // TODO: Should we set the GID to something else than 0 (i.e. the GID of the root primary group)?