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

@jimfl Yeah, this is a whole new level to me. Yikes.

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

@rootwyrm I've heard nothing but the worst about that process and shit like this just shows. But it's cool, they'll keep making money by holding security updates behind subscriptions.

@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.

@fre That's why I didn't put severity or CVSS string in the toot. I think the description speaks for itself and putting their initial assessment would cause people to not take it very seriously.

@kallisti That's why I didn't put severity or CVSS string in the toot. I think the description speaks for itself and putting their initial assessment would cause people to not take it very seriously.

@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?

@ckure Look, it's not like Canonical has been doing vulnerable systems for a couple of decades or anything. Maybe it was a legitimate oversight...

@cR0w

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

@noratrieb Mitigation: sudo init 0

@cR0w

@cR0w I love a disposable root shell

@Dio9sys Happy Monday. It's just so... Canonical.

@cR0w Canonical is truly a gift that keeps on giving

@redsakana Unless you're a customer, that is.

@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

@ckure I do honestly hope this wasn't some poor intern that will get thrown under the bus because the seniors are unwilling to take responsibility. But it's Canonical so...

@f4grx @cR0w yoooo....!

LMAO when it turns out the patch for this is behind the subscription like

@cR0w

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

@patcharcana When the unlocked door isn't actually a trap but just easy mode.

@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?

@rootwyrm @f4grx inb4 "you get what you pay for"

@da_667 Happy Monday

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

@patcharcana We need a new version of the sudo make me a sandwich that's even dumber now.

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

@rootwyrm @f4grx Right. Good call.

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

@kevinmirsky In their imaginary defense, everyone else puts security behind paid features so why not?

@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 :(

@srtcd424 This one does not appear to be a language issue. Programmer socks would not have saved them here.

@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?

@srtcd424 It defaulted to 0 but because it was programmed to do so, right?

@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.

@ckure Fully agree. But these days it seems like nothing is working as designed and while I like to give Canonical a hard time, I genuinely have no reason to expect they're operating any better than so many these days.

@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.

@angusm @yomimono When everyone is root, no one is root.

@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 ..

@srtcd424 Bugdoor... 😏

@da_667 @cR0w MY CVE-ITIS

@NosirrahSec @da_667 I've got a bad case of Canonical

@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

@somebody

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

@fabiscafe

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

@farewell_ladmin

@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

@astraluma That's a nice find.

@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

@chillybot @rootwyrm

a lot of the people at Canonical are really shitty to others

And yet they named their OS Ubuntu

@cR0w wat?

@pmb00cs exactly

@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"?

@Rhodium103 I would never default deny. I've got manners.

Given how popular Ubuntu is, I wonder how heavily weighted code like this is with Copilot. 🤔

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

@fabiscafe 🥂

@cR0w

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

@howard Sounds too legacy for the forward-thinkers at Canonical.

@jerry It would explain a lot.

@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 ✅

@catsalad Unit test: Passed

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

@galaxis Seems like it would be quite a challenge for them to introduce a more but I've got popcorn ready just in case.

@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.

@yacc143 @fre 🤔

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

@truh Everything is local if you wait long enough to observe it. taps temple

@andre @kevinmirsky Meh, I've had a good run. Just make it quick and thorough.

@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?

@adamshostack I think that pretty much nails it. It appears it's using test data to apply to logins that are not already in the authd user database. But that test data is gid: 0. Whoopsie.

@cR0w

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

@adamshostack Yeah. And then the sandbagged CVE CVSS assessment is the cherry on top.

@cR0w you mean cvss?

@adamshostack I would think so but maybe they're just kicking the can down the road? The whole thing is weird.

@adamshostack Yep, sorry about that.

@buherator @jerry

@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?

@waterbear No: https://documentation.ubuntu.com/authd/stable/

@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?

@Doomed_Daniel I don't think so. I was being a smartass about Canonical's approach of hiding security patches behind Pro.

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

@jxvvt I was being a smartass about Canonical's general approach of hiding needed security patches behind Pro.

@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)

@Doomed_Daniel That's an exercise for the admins. I'm not going to imply it's unlikely to impact users simply because they don't remember installing authd. The reality is that it's bad enough that it justifies taking inventory of all systems that may be impacted.

@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*

@dotjayne It's just so funny.

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

@Ertain It was not. It was me. I honestly don't even know how to do that and I am completely okay with 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.

@jxvvt @Doomed_Daniel Organizational memory too though. Just because it wasn't documented doesn't mean it wasn't installed / configured.

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

@peribotsarah Not so much provisioning as brokering cloud auth.

https://documentation.ubuntu.com/authd/stable/

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

@3v1n0 @Doomed_Daniel I usually am but how so this time?

@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)

@3v1n0 @Doomed_Daniel I have linked both of those in replies as I do understand that part. I think you maybe should have read one post further before calling me out: https://infosec.exchange/@cR0w/114694894920067010

@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.

@3v1n0 @fre That's a downstream issue, though one I expect we also have different levels of acceptable risk on.

When the one job of authd is to broker IAM functions, putting previously unknown users into the root group seems like a major failure. It almost fails to the point of "you had one job" meme status.

@lanodan @cR0w it does.

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

@3v1n0 @lanodan I'm not saying that I know the code any better. I'm just saying that with the benefit of hindsight, the answer to this question in the code comments is yes.

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

And the patch reflects the correct answer as far as I'm concerned.

@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.

@3v1n0 @Doomed_Daniel It wasn't false accusations. It was, at least to people who know me, clearly a s̶̰̩̝̿̏̆͌͆̄͋̅͋̈͒͑̂̚h̵̡̢̨̛͍̮͙͉̫̻̜̱͇̿̾͊̀̄̓̎̃́ͅi̷̡̤̭̣̖͕̰̹̗͉͖̺̽̔̾̑̓͜͠ͅt̷̩̗͚͕̱̱̜̰͛̍́̈́̈́́͝p̷̩̐͋̊̋̾̑͊̐͒̍̍͠ó̴̱̘͑̔̄͐͛̏͛̑͆͘̚s̷̡̧̳͓̱͖͗͐͌̈́̈́̃͒͐͜t̷̟̮͍́̕

@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.

@3v1n0 @fre All I'm suggesting is that it's a hilarious bug and that I think it's bullshit that Ubuntu holds some security patches behind a Pro login. Those are two separate issues that are connected by the Ubuntu OS. Yes it was fixed and reported in the open as is the standard for FOSS. You don't get a cookie for that.

Yes, shit happens with any project. That doesn't mean I'm not going to point it out so people can fix their shit while simultaneously laughing as though I wrote the bug myself.

@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.

@3v1n0 @fre "Finally"

LMAO. Have a nice day.

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

@Doomed_Daniel @3v1n0 500 boosts? No wonder so many people have responded.

@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.

@jxvvt @Doomed_Daniel @3v1n0 If the misunderstanding is that widespread, then maybe the person who wrote the advisory is the person you should be doing the weird damage control with from your hours-old throwaway account, not someone boosting toots that entertained they were entertained by.

@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)?

@josephholsten I saw that too. 😆

https://infosec.exchange/@cR0w/114695486788548391