SANS Stormcast Tuesday, August 4th, 2026: More Arch Linux AUR trouble; iCloud Sharing; Pass the Passkey

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/10036.mp3

previous

More Arch Linux AUR trouble; iCloud Sharing; Pass the Passkey

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Tuesday August 4th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu graduate certificate program in
 industrial control systems. Arch Linux announced that they
 yet again had to stop accepting adoption requests
 for their user packages. So Arch Linux is in part popular
 because they have AUR, the Arch User Repository, which
 does host packages created by users. In other distributions,
 you may be able to create DEP and RPM and similar packages,
 but there is no sort of easy way to find them if they
 weren't included in the official distribution.
 Different for Arch, which has AUR to host these packages.
 And then they have a neat feature that allows new
 maintainers to take over abandoned packages, a common
 problem when it comes to open source. The only issue here
 is, well, it's a little maybe a little bit too easy to take
 over an existing package. So what often happens here is
 that a user publishes a package, it gains some
 popularity, then they lose interest in it. And then there
 is an adoption request that's being submitted by a malicious
 party in order to then add malware to the package. Well,
 that's exactly what happened yet again has happened before
 on a larger scale. There are several hundred suspicious
 packages published and who knows how many adoption
 requests are sort of outstanding for various other
 packages. And now in order to sort of catch up on that
 backlog and also maybe refine their procedures somewhat,
 Arch has decided to not accept any new adoption requests
 until further notice. Well, and then there is an
 interesting sort of lesson that we have been emerging out
 of the court battle between Apple and OpenAI over the
 alleged theft of intellectual property by Apple employees
 who joined OpenAI. The problem here is that some of these
 employees apparently retained access to confidential
 material after they left Apple. Now, one of the sort of
 root causes here appears to be that if you're joining Apple
 as an employee, you're being given two terabytes of storage
 as part of an iCloud account. And then of course, with
 iCloud, you have the problem that if you're logged into a
 particular device, you can only be logged into one iCloud
 account. So some employees choose to use these two
 terabytes of storage with their personal account. And
 then of course, this led to sort of the mingling of
 personal and official Apple documents, which then resulted
 in the loss of intellectual property. When you're
 selecting a cloud solution like this, there should always
 be a specific account that you're using for anything work
 related. You don't really want to mingle personal and work
 documents in one account, not just to keep your company's
 data safe, but also to keep your personal data safe from,
 for example, being stolen if your company is getting
 breached. So definitely always good to keep a little bit of
 firewall between those two domains. And Palo Alto did
 publish a blog post outlining some of the attacks against
 passkeys, in particular, attacking the sync mechanism
 that's implemented in password managers. So one of the big
 design decisions when it comes to passkey compared to some of
 the prior FIDO2 standard implementations was to make it
 more usable. And as part of this, they did allow syncing
 these passkeys with password managers. This was a critical
 thing to really make passkeys usable for the average user.
 Before that, a FIDO2 key was linked to a particular
 hardware device like a YubiKey or one of these Google Titan
 devices. And there was no real good way to sort of back them
 up. Actually, the official solution was to just register
 multiple keys with a particular website, which of
 course, isn't really sort of feasible to the average user
 who is just trying to replace usernames and passwords.
 However, the problem with password synchronization, of
 course, is that once the attacker is able to
 synchronize these passkeys, well, they're effectively able
 to steal the secret keys. And it's really sort of what this
 article by Palo Alto is all about, about how this syncing
 can happen, how attackers can sort of, you know, infiltrate
 that process and then obtain copies of these passkeys. I
 don't think it's sort of a fundamental really flaw in
 passkey. It's really just an intentional limitation and a
 risk that was accepted to make passkeys usable. When you're
 implementing passkeys or FIDO2, I should say, for some
 more higher risk applications, then maybe you don't really
 sort of want to go with passkey, but one of these more
 hardware linked authentication methods that are also sort of
 part of the FIDO2 standards. And then you avoid some of the
 weaknesses that are outlined in this article. And N-able
 has released a hotfix for its N-Central product. Now, what
 makes this in particular sort of difficult is that this
 hotfix does fix currently exploited vulnerability that
 was originally addressed in an update last week on Friday.
 N-able released 2026.3, but apparently the fix was not
 complete. So now they're actually releasing 2026.3.1.7,
 which does hopefully release the real fix for this
 vulnerability. Speaker 1 Well, and this is it for today. So
 thanks for listening. Thanks for liking. Thanks for
 subscribing. And talk to you again tomorrow. Bye.