Security Now 1083 transcript
Please be advised that this transcript is AI-generated and may not be word-for-word. Time codes refer to the approximate times in the ad-free version of the show.
Leo Laporte [00:00:00]:
It's time for Security Now. Steve Gibson is here and he's raring to go. There are more supply chain attacks to talk about, including on the Arch Linux user repository npm. They're going to try to make that a little bit more secure. Steve has some recommendations until they do. And June shows that AI has arrived for vulnerability discovery. We'll talk about that and a whole lot more next on Security Now.
TWiT.tv [00:00:29]:
Podcasts you love from people you trust.
Leo Laporte [00:00:33]:
This is twit. This is Security now with Steve Gibson. Episode 1083 recorded Tuesday, June 16, 2026. Patch Tuesday a la AI it's time for Security now the show we cover the latest in security, privacy and all that stuff online with the man, the myth, the legend, but not the mythos. Mr. Steve Gibson.
Steve Gibson [00:01:03]:
No mythos for you. That's true.
Leo Laporte [00:01:05]:
No fable here.
Steve Gibson [00:01:07]:
No fable either.
Leo Laporte [00:01:08]:
Wow. Wow.
Steve Gibson [00:01:09]:
Crazy story. Well, yeah, I'm gonna share Anthropic's response and then we'll do a little editorializing around that because that was an interesting weirdness. So last Tuesday was June's Patch Tuesday and boy did we break records. Yeah. So today's podcast is titled Patch Tuesday a la AI because you know, this is what we were expecting to see. It'll be interesting to see how long this tsunami crescendo tidal wave pulse lasts. I don't expect it to be like this is not going to be an every month thing, but five, six months would be my guess. And then we're gonna see a, a reaction drop in the number of monthly patches because the AI is going to get deployed.
Steve Gibson [00:02:16]:
In the case of Microsoft and Patch Tuesday, the horribly named code name M Dash, which they make me say every time will, will be the thing that, you know, changes, I really believe changes the Windows side of the industry. Anyway, we're going to dig deep into that. I want to talk about rootkits having been found in more than 400 arch Linux user repository packages.
Leo Laporte [00:02:45]:
I had to really worry about that. I'm an Arch Linux user. Yeah.
Steve Gibson [00:02:50]:
US Government requests Anthropic, as we said, to remove both access to both Mythos and Fable for foreign nationals. But since you can't, I mean, it's like the age restriction problem, right? It's like, well, we're not really sure so we'll just have to tell everybody. No. CISA has also had an interesting response to AI driven attacks changing their patching requirements for federal agencies. And boy, if, if patching was ever a back room or like, like on the back burner, this is. It is just no Longer the case and any federal agency who. And they might. This is a bod.
Steve Gibson [00:03:37]:
What I can't remember that stands for Binding Operational Directive from from CISA which you know has legal strength which says you have to patch on the timeline we say and it's fast. So patching again is like this has moved right up to the front of you know, operational readiness business wise. We'll, we'll, we'll look at that. Also npm the most attacked repository we have, you know the Node JS packet manager has switched to more secure install defaults. The problem is a lot of non malicious use of these install defaults occurs and so this is going to create breakage when. Which is going to have an unclear effect on long term security. I found a really interesting analysis of this from somebody on the inside who understands what's going to happen that we're going to take a look at. Also a bunch of people responded across the spectrum about my little rant on about PHP which of course is not the first time I've ran it about php but we've got great loop closure now with email communications.
Steve Gibson [00:05:02]:
I'm going to share a bunch of that and then we're going to look at the consequence of AI having been here long enough code cognizant AI long enough to have a serious impact on June's patches. So I, I think a lot of fun stuff to talk about and of course a picture of the week that actually is a. Has a kind of a coding theme or that's how I'm going to spin it anyway.
Leo Laporte [00:05:28]:
Oh well, you know I'm always up for that.
Steve Gibson [00:05:31]:
Yeah.
Leo Laporte [00:05:32]:
I have a little tale to tell about AI saving my bacon yesterday too at some point. Yeah I was. It was like a lifesaver. Speaking of Linux.
Steve Gibson [00:05:42]:
Well, we won't. In that case let. Let's do the first sponsor then. Then you have to tell us because I can't wait.
Leo Laporte [00:05:48]:
Yeah, yeah. I just. The more I use it the more valuable it becomes. That's best. It's really clear. Yeah, I miss Fable but you know this was with 4.8 opus 4.8. It did a great job. Now back to Steve and our picture of the week.
Steve Gibson [00:06:04]:
First tell us about AI saving your bacon.
Leo Laporte [00:06:08]:
So I run my agent. Everything, all, all of it, all the models, all the memory, everything on that nice framework desktop I bought. Really designed to do that. I bought it to do local AI. 128 gigs of RAM. It's got that AMD AI plus 395 AI specific processor. It's really nice. Yesterday I come in, I mean, and I use it every day.
Leo Laporte [00:06:33]:
That's where Claude is, where everything is. And it's, it says emergency, can't boot. And it gives me a prompt and I go, oh, that's not good. Now in the past what I would have done is I would have reinstalled Linux on that machine and then had to go through. I've got backups, of course, but I'll go through the hairy process of restoring it. And because it's my agent, I wouldn't have any assistance doing it, fortunately. Right, yeah, it would be on my own, buddy. Fortunately, I do have Claude code running on my laptop, so I thought, well, let me just see if Claude code can help.
Leo Laporte [00:07:14]:
It said, don't erase it, tell me what the message is. And I told it, I said, oh, good news, that might just be a minor thing, let's figure it out. It had me type in, it started to have me type in a lot of stuff, but basically I went to rebooted it through the Linux install USB key so that I have an operating system and I can look at the hard drives. And I said, this is a lot to type in, I'm going to make mistakes. It said, oh, of course, this is Claude talking, what am I thinking? It said, look, I'm human, You, you human, you poor human. I need to SSH into this machine. But of course you're running the boot thing, you know, it doesn't know who I am, it's not going to let me SSH in. So here's what I'm going to do.
Leo Laporte [00:07:59]:
I'm going to write a little web server, run a little web server on your, on the laptop here, and you're going to curl the key, the SSH key into the boot thing, turn on SSH and then I will SSH in and do it for you. I did it. Did it. Ssh10. It said it looked and looked. Oh, you know what the problem is? It's a little weird, but you have two. I don't even know what an ESP is, but you have two ESPs. The way I set this up is it's just dual SSDs, they're lux encrypted and they're mirrored so that if one dies, I mean, this is how mission critical one dies, the other one is still got everything on it.
Leo Laporte [00:08:40]:
And it does because the Lux encryption, it has the password in the tpm. So. Because the other thing is it has to reboot if I'm not around and the power goes out. I have to reboot. But I do want it encrypted. I just don't want to have to be there to enter the password. So it does that automatically through the tpm. I don't know what an ESP is, but apparently it's something to do with uefi.
Leo Laporte [00:09:01]:
There are two different ESP modules, and for some reason they had different Linux kernels. 1 had 7012, 1 had 7.0.11. And that's what was stopping it from booting. It figured that out. It said, okay, I'll just. No problem. I'll just put the other kernel, I'll make a match and from now. And I'm going to write a little stub now, when you do an upgrade, it'll automatically make sure it's the same kernel on both ESP modules so this doesn't happen again.
Leo Laporte [00:09:29]:
It said, okay, all done. Reboot, it's fixed.
Steve Gibson [00:09:34]:
We're living in a science fiction world.
Leo Laporte [00:09:36]:
I don't even know what ESPs are. I would not have been able to fix this. Yeah, it has to do with the UEFI boot. I wouldn't have known where to start. It would have been a massive chore. Instead it wrote a little web server curled. I curled the key over, logged in and did it all for me. Yeah, it.
Leo Laporte [00:09:58]:
And you tell me these things are just autocorrect.
Steve Gibson [00:10:03]:
Wow.
Leo Laporte [00:10:04]:
No, it's very good.
Steve Gibson [00:10:05]:
It's funny, I. I had an experience yesterday. I'm. I'm configuring the house's security and environmental monitoring and management stuff.
Leo Laporte [00:10:18]:
Oh. It's really good at that, actually.
Steve Gibson [00:10:19]:
Yeah. And I was using Claude, but I had it turned down to Sonnet something. And it was kind of stumbling along and I was getting some bad answers and I sort of thought, what am I doing? Why am I using demo?
Leo Laporte [00:10:36]:
So Sonnet's pretty good, but not for the hardcore stuff. Yeah.
Steve Gibson [00:10:40]:
So I switched to Opus 4.8 and what was interesting was that model, in reviewing our dialogue, started to apologize about the previous bad answers that I'd been given. I said, 48 is very apologetic. I'm not sure what happened here, but, you know, you got. I got. There was like, oh, that was somebody else. That was just dumb. That was dumbo.
Leo Laporte [00:11:06]:
Don't. Don't take. So that's One thing that's 48 is notable for. It does apologize a lot. I don't. But when it makes.
Steve Gibson [00:11:13]:
But.
Leo Laporte [00:11:13]:
But this one was so careful. It said, I know this is. You know, I understand. This is your agent. This is. This is Mission critical. I'm going to move slowly and make sure that I'm doing everything right. And it, it was flawless.
Leo Laporte [00:11:26]:
It was.
Steve Gibson [00:11:27]:
And in fact, I had to say now, now that I was on 4, 8, every answer was correct. And at one point it said, I'm going to make sure that I've not given you the wrong information by, by checking on blah, blah, blah, blah. And it went off and did something and it came back and it's like, okay, you know, I verified that this is the case. It's like I'm just sitting here thinking, wow, I have an assistant.
Leo Laporte [00:11:50]:
I know some people listening are thinking, oh, Leo and Steve lost their marbles, they've drunk the koolaid.
Steve Gibson [00:11:55]:
Where's the Kool Aid?
Leo Laporte [00:11:58]:
But until you've actually had this experience, it's easy to poo poo it. But once you've had the experience, it's like, wow.
Steve Gibson [00:12:06]:
And as I said to our listeners a couple of weeks ago, you get an account. It can be free, but that creates context. And my feeling is if you, if what we're saying sounds wacky, then it's because you haven't tried it or there's nothing you need it to do. The idea is, you know, if you're trying to do something, then. And also, old habits die hard. I mean, this is all new. And so, you know, it takes a while to get used to the idea that there is this astonishing assistance available.
Leo Laporte [00:12:46]:
It's kind of amazing. Well, and the thing is, it speaks computer really well. It's very good at speaking computer.
Steve Gibson [00:12:53]:
It's funny too, because that's significant. I remember when Google searches only turned up the results I wanted because only computer geeks were on the Internet.
Leo Laporte [00:13:02]:
Right?
Steve Gibson [00:13:02]:
And so the Internet was very computer quality. Now you got all this, you know, all this nonsense out there. So you get, you know, search results are nearly as interesting for, for computer people because it's got, you know, everybody else. So it's nice.
Leo Laporte [00:13:18]:
Anyway, that's, that's my tale. I, I was just blown away. It was just really surprising.
Steve Gibson [00:13:24]:
Yeah.
Leo Laporte [00:13:24]:
So, okay, thank you. Thank you, Claude, for fixing my computer.
Steve Gibson [00:13:28]:
So it's, it's picture. So I gave this one the caption a loop with the branch test at the end.
Leo Laporte [00:13:38]:
Okay, I'm ready to look at it.
Steve Gibson [00:13:40]:
I haven't seen the branch test at the end.
Leo Laporte [00:13:47]:
Okay, I like it. This is a. Now Steve's turned this into a coder joke, but it is really a coder joke or is it correct?
Steve Gibson [00:13:57]:
So the sign says, so this is some signage somewhere, like like at a service window or something and it says back in 15 minute. And then on the next line it says minutes. If not read sign again.
Leo Laporte [00:14:13]:
So go to 10.
Steve Gibson [00:14:16]:
So exactly. So what we have here is a loop with a delay statement in it and it branches back to the top. Now for those who don't code, there are different configurations for looping. You, you are able to say like for example, while something then do the following, right? Or you can say when, when, when you're finished doing something, you can perform a test and maybe do it again. So and, and it turns out these are like subtly different constructs in computer science. It's one of the things based on like programmers who are just starting out learn is that there are cases where you never want to execute some code in that could be executed multiple times in a. And which is why we call it a loop because you loop back in which case you would test for that decision at the beginning of the loop before you've even done it once. There are other times where, where you always want to do it once and then you want to see well, do I do it again? And so that's where you put the test at the bottom.
Steve Gibson [00:15:30]:
So anyway, I gave this one a loop with the branch test at the end because you know, back in 50 minutes. If not read sign again.
Leo Laporte [00:15:42]:
So yeah, that's very funny. I love it. Yep.
Steve Gibson [00:15:46]:
Okay, so Arch Linux user repository Abbreviated Aura seriously compromised more than 400 instances of. With. Well, seriously, not only in count, but in what 400 instances of Linux rootkit and infosteeler malware were found. The infosteeler targets credentials and access tokens. I'm gonna, we're gonna dig somewhat deeply into that here in a minute because we've never really talked about infostealer malware. We've referred to it. You know, it's like, oh, that's an info stealer. But we haven't like, like what info is stolen? So we're going to answer that.
Steve Gibson [00:16:30]:
Last Tuesday, the site, which great domain, ioctl, which is the abbreviation for IO control, you know, input output control, ioctl fail is the, is the site.
Leo Laporte [00:16:44]:
What a good name. Yeah, what a good name.
Steve Gibson [00:16:47]:
And I didn't know you had. There's a like a dot fail top level domain.
Leo Laporte [00:16:51]:
I didn't either.
Steve Gibson [00:16:52]:
That's just that one.
Leo Laporte [00:16:53]:
Yeah.
Steve Gibson [00:16:54]:
Happened. Yeah. They posted their analysis of this infiltration campaign, opening their report by explaining this report summarizes static reverse engineering of the Linux elf. You know, ELF malware sample named deps. DEPS is the name of the malware and static review of the recovered NPM package source associated with the incident. The sample and package were treated as malicious throughout handling. No dynamic execution of the ELF NPM package lifecycle scripts or package code was performed. The binary is stripped and implemented with Rust style async state machines.
Steve Gibson [00:17:45]:
Function names in this report are an analyst assigned names based on decompiled behavior. Okay, so to interrupt for a minute, what they're saying here is that at no point did they actually execute the malware under any context. You know, that's sometimes done, right? You run it in a, in a protected virtual environment in a sandbox and see to. In order to watch it go see what it does. And just for the record, this elf, this elf, which is referred to here and throughout, for those not well versed in Linux lingo, is abbreviation for executable and linkable format. Thus ELF executable and linkable format. It's a very flexible format that's used almost universally by Linux and the Unixes also and as well as some embedded RTOs and pretty much everywhere other than Windows, which you know, has its own pe, the Portable Executable Format, and Mac, which uses Mach O as as its format. In any event, they chose not to let this thing, as I said, loose.
Steve Gibson [00:18:56]:
I don't know why. In a sandbox, you know, such as, you know, a secure vm, the idea there would be any damage that it might attempt or you know, to do could be observed and contained. Instead, they reverse engineered the malware from a static binary sample of the malware code. And since this malicious binary had been stripped of any latent symbolic names, it was just pure binary code that did the work. Variable names or function names were not there. The analyst assigned the names as they worked through the the the decompilation of this once a function's purpose had become clear. So they go on to explain this sample was recovered from a supply chain compromise involving an arch user repository package build flow. In the reported intrusion path.
Steve Gibson [00:19:57]:
The attacker modified AUR build steps so that the build build a process downloaded and installed a malicious NPM package. That package masqueraded as atomic lock file, which is that like a useful thing version 1.4.2 so that itself is not malicious. It was masquerading pretending to be atomic lock file version 1.4.2 and included the Linux ELF payload at source hooks depths is where it was in the file system. The malicious NPM package uses a pre install lifecycle hook. Now this is interesting. We're going to be talking a little about this whole thing coming up a little bit later. A pre install lifecycle hook to execute the ELF automatically during NPM installation could be useful. In this case, it's a source of abuse.
Steve Gibson [00:20:58]:
This means they wrote a developer workstation, a maintainer's machine or CI slash build host could execute the malware as a side effect of building or installing the compromised AUR package. Deps that's the malware is a Linux credential stealer with optional root only EBPF rootkit capabilities. EBPF I'll just interrupt refers to the extended Berkeley packet filter technology that allows user provided code to be run in the Linux kernel. This gives that code direct access to the most privileged information in the system. Normally this is very useful for analyzing communications you need to be down in the kernel in order to reduce the analysis overhead. Thus the extended Berkeley packet filter. This is an abuse of that privilege essentially. So they continue to describe the malware writing it's designed for developer workstations and build environments.
Steve Gibson [00:22:05]:
It targets browser and electron application data, Slack, Microsoft Teams, Discord, GitHub, NPM Vault, Docker, Podman, SSH, VPN Material, Shell histories and other local developer secrets.
Leo Laporte [00:22:24]:
Yikes.
Steve Gibson [00:22:25]:
In other words, no developer wants this thing anywhere near their machine. They said the recovered supply chain package identifies itself as atomic lot file. Version 1.4.2 contains a malicious NPM lifecycle entry pre install at source hooks depths. That lifecycle script executes the ELF directly during NPM installation. When lifecycle scripts are enabled, the ELF in the package source is byte identical to the analyzed sample. So that was a little bit of repetition and they're just saying what they analyzed was byte identical. They said the attacker controlled Command and Control C2 endpoint was recovered from the ELF. It's not supplied by the NPM package, command line arguments or a JavaScript wrapper.
Steve Gibson [00:23:21]:
The binary decodes an onion service address at runtime and then they give the address is just a long string of gobbly gook like all the onion addresses are ending in dot onion for the domain name. The command result callback is a post at API agent sent through a local loopback SOC style transport. The local 127001 traffic is in an intermediate transport layer, not the attacker endpoint. When BPF is available, the malware can hide local process and socket artifacts used by the transportation. Okay, so in other words, if the code has access to the extended Berkeley packet filter functionality, then that access will be used in a rootkit like manner to completely obscure any and all evidence of any infection or the software Itself, it just disappears so that anyone looking at the machine, looking at, you know, nets, the equivalent of netstat looking at what processes are listening for connections on ports, what communications are occurring on the fly, looking for example, for a connection to a command and control server, it just won't show up. The rootkit system that it brings completely makes it just vanish. And we of course covered rootkits way back in that a Sony infiltration, the advanced persistent threat that got Sony. So they said without ebpf, the local network presence of something can be observed.
Steve Gibson [00:25:14]:
So the recovered package they wrote source the recover package source appears to be a mostly legitimate TypeScript npm package with a malicious ELF inserted into the source tree and then wired into that NPM lifecycle execution. In other words, it's a normal benign piece of big JavaScript typescript and they just tacked in this ELF binary and then use the NPM pre install functionality to get it, you know, to execute it. And then it would do all of its bad stuff, they said. Static review of the package source outside the elf found no JavaScript wrapper, no additional command and control configuration, no command line arguments passed to the ELF, and no package layer references to, you know, temp, sh, API agent, Discord, webhooks or a public C2 domain IP. In other words, the the TypeScript npm package was clean, did not contain any other infection. The infection, such as it was, was all in this ELF binary. So they said. Conclusion the malicious NPM package provides the execution vector.
Steve Gibson [00:26:35]:
The C2 endpoint is included inside the ELF itself. Okay, so now we know what it is and how it's delivered and carried into the system. Which brings us to what does it do inside the developer's machine once it takes hold? And remember, there are 400 instances of these bad things that were discovered in the Arch Linux repository, the user repository. So this no doubt infected a bunch of people. So we learn further why no developer wants us have to wants to have this anywhere near the system. So it installs persistence using root or per user system D service units enforces a single active instance using flock so to to keep like multiple instances from running at once. Redirects standard input output error to dev null so that you won't see it doing anything. Any of its output ignores sigpipe so it takes itself out of any external control, reads proc self exe to locate and copy and install its current executable.
Steve Gibson [00:27:50]:
Uses Rust Async runtime logic to run collectors and transport tasks, enumerates Chromium family browser profiles and Electron app data reads SQLite read cookie databases and Level DB local storage extract Chromium and Electron cookies and service tokens Queries Slack Microsoft Teams Discord, GitHub, npm and OpenAI chat APIs with stolen tokens or cookies Searches local file system locations for SSH keys, your shell history, vault tokens, Docker, Podman credentials, VPN material and developer secrets Uploads file content to temp SH calls back to the recovered onion command and control over a post query to API agent Uses a local loopback sock style transport before reaching proxy destinations Includes a downloader stager path tied to User Bin, Monero Wallet GUI and if sufficiently privileged, loads an embedded EBPF rootkit to hide its process names and all of its socket nodes. So it goes completely stealth once it gets into your system if it's able to use EBPF. And again, just to reiterate, more than 400 instances of arch Linux repository packages have been found infected with this nastiness. So as I said before, we've referred tangentially to InfoStealer malware from Time to time. It is unfortunately an increasingly prevalent form of malware because its goal is is obtaining information that would allow an attacker to pivot to some other target. They don't really care about a developer's machine, but they're hoping that they'll get into the machine of a developer who also happens to have, for example, AWS credentials for some other juicy target like the company he works for or consults to or something. So the bad guys are less much less interested in the initial victim in this case than in what other systems or networks that victim may have access to. And of course the classic example was the LastPass developer who had a a bug in his NAS software that was way out of date and the bad guys got into him, found out that he was a developer at LastPass, and then got into LastPass.
Steve Gibson [00:30:46]:
So we've never looked closely at info stealers since they're definitely something that no one wants to discover in their systems, since they're growing in prevalence, and since we have a very nicely reverse engineered info stealer here to take a look at, I want to share the details of what info this representative info stealer steals. The malware targets developer and collaboration data and they they enumerate them. This is so this is literally what they found this code doing. It digs into the browsers and Chromium profile stores for Google Chrome, Chrome Beta, Chrome Dev, Microsoft Edge, Edge Beta, Edge Dev, Brave Brave Beta Brave Nightly, Vivaldi, Opera Opera Beta, Opera Developer Yandex browser, Epic Privacy Browser, Iridium Ungoogled, Chrome, Thorium, Komodo Dragon Srware, Iron Scent Browser, slimjet, Maxthon UC Browser, Coco Naver Whale, Chromium, Flatpak, Google Chrome Flatpak, Microsoft Edge, Flatpak, Brave Flatpak, Vivaldi Flatback, Opera Flatback and Yandex browser Flatback.
Leo Laporte [00:32:09]:
In other words, half of those I
Steve Gibson [00:32:11]:
know, but they exist and they so these developers took the time to put in some specific code for each and every one of those, because if the developer has it, they want to get into it. Profile artifacts targeted include local storage level DB the network and cookies, cookie network slash cookies, Cookies default slash cookies and Chromium encrypted cookie values Collaboration and Electron applications which it knows about and goes after Slack Slat, Flat pack, Slack Snap Microsoft Teams Microsoft Teams Legacy stores Microsoft Teams Flatpak Slash browser derived stores, Discord, Discord ptb, Discord Canary, Discord Flat Flat pack variants, Discord Snap variants, Ves, Top leg Chord, Web Cord, Arm Chord, ven Chord, Native Cord, ABADDON descent, RIPCord and DAT cord. They also confirmed the slack wait a minute. Data ripcord and dat cord. That's right. They also confirmed slack paths and data where this thing looks at config slack var app.com Slack Slack Config Slack Snap Slack Current config Slack you're just tuned in Cookies for *slack.com Slack API enrichment Thorough API auth test API users.info and Apiconversations list and we're about halfway through Confirmed Microsoft Teams and Microsoft service artifacts include config, Microsoft Microsoft Teams, Auth service Teams, Microsoft.com Teams, Microsoft.com Skype token, region GTM cash token, authorization Bearer x Skype token teams account tenant and team metadata. They've confirmed discord artifacts which it digs around through, including discord tokens from Electron Browser Storage, API v9 users at me API v9 users at me Guilds, MFA State Premium Nitro type flags, guild ownership permissions and member count metadata Developer accounts and package ecosystems including GitHub, NPM and open API Jet TPT account metadata. Confirmed GitHub strings and endpoints include API.GitHub.com where they get a bearer to and user agent.
Steve Gibson [00:35:25]:
They look for credentials, account and repository metadata such as login, company public repository count followers and repository stars NPM strings and endpoints including.registry npmjs.org they get the public, the package publishing identity and maintainer package metadata. The Open API ChatGPT Path queries API.openapi.com with stolen bearer material for account metadata. This is so it's credential validation enrichment against a third party service name. Note not evidence that open API is attacker controlled infrastructure and finally Local developer secrets Vault token files, Docker command history and registry credential material, Podman command history and registry credential material, SSH keys and SSH configuration putty, private key material, VPN profiles and dot ovpn that's openvpn files, shell histories for bash, zsh and f and fish command history containing sftp, sh, keygen, sh, copy id, sh, add, rsync, putty, plink, docker, docker, compost and podman commands and yes, I know that was a lot.
Leo Laporte [00:37:00]:
I've made a song out of it. Would you like to hear the oh,
Steve Gibson [00:37:05]:
we have to have it. Microsoft Teams Microsoft Teams Legacy stores Microsoft Teams Flatpak browser derived stores Discord, Discord ptb, Discord Canary Discord, Flatpak variants It's
Leo Laporte [00:37:21]:
a long song you don't want to hear.
Steve Gibson [00:37:22]:
It's really pretty good.
Leo Laporte [00:37:27]:
There is a little more Discord Snap
Steve Gibson [00:37:30]:
variants Vesc Top leg chord, Web chord, arm chord bend cord Native chord abad on descent rip cord and D cord Slack Path config Slack Slack slack Current
Leo Laporte [00:37:46]:
Sorry, Go ahead please.
Steve Gibson [00:37:47]:
That's wonderful.
Leo Laporte [00:37:48]:
It's amazing what AI can do. Actually, we shouldn't laugh because this has been a nightmare for everybody using Arch. I mean, it is the worst thing you could possibly have happened.
Steve Gibson [00:38:00]:
Yes, terrible. So, as I said, I know that's what I just did to everybody was a lot. But I think it's important to appreciate that the more than 400 instances of this malware which were discovered residing in the Arch Linux repository were expressly designed to root out any and all instances, any and all instances of any of that developer data and send it back to its command and control server. So the real takeaway here is this info stealer stuff. This is what an info stealer looks like. It's what it feels like, it's what it does. If it gets into your computer, it's out there. And developers really need to be extremely cautious, more so than ever, that this doesn't get into their system because it's going to elevate its privileges.
Steve Gibson [00:38:55]:
It's going to, you know, rumage around through your system, sing a little jingle to itself, and just suck everything out of your computer that you just take for granted. And the developers will get it and use it against you or anybody whose information you have on Their behalf, AWS or an employer, someone that, that you're consulting for and so on. So it's real and it's bad.
Leo Laporte [00:39:21]:
Okay.
Steve Gibson [00:39:22]:
So last Friday afternoon, at the request of the US Government's well, non specified concerns for national security, Anthropic shut down all access to their two most advanced models, Claude Fable 5 and Mythos 5. And I'm sure everyone has seen this a lot. We should note that though, that claiming national security has become the catch all phrase used by the US government, which, you know, should be taken to mean either because it's what we want or because we say so. So it's, you know, often not very satisfying. It's not at all clear why this is the case. But in any event, since it was just Leo, it was at the start, the very start of last week's podcast.
Leo Laporte [00:40:16]:
Yeah.
Steve Gibson [00:40:16]:
That Claude. Claude Fable 5 first appeared.
Leo Laporte [00:40:19]:
I think I mentioned it didn't the show?
Steve Gibson [00:40:21]:
Yeah, you did. It's like, hey, there's, there's a new model. And in fact you began playing with it. I think it was during the podcast. You ran it on some of your existing code and it found a whole bunch of more stuff.
Leo Laporte [00:40:34]:
It did. It found a lot of security flaws. It was very good.
Steve Gibson [00:40:37]:
So it looked like another major leap forward. So as a consequence, that of all of that. I want to share what Anthropic posted because there's some interesting pieces of, of sort of things to read in between the lines here about why their two newest models have been taken down. And you know, as I'm saying this, listen to the language Anthropic uses when they talk about safeguards and jailbreaks because this is their push back. And it, it echoes the position everyone here has heard me articulate from the start, which is that are to me it feels understanding enough of how this large language model technology operates intuitively. It feels as if it is. The whole technology is almost certainly going to be inherently hostile to any form of control. I don't mean hostile like in a belligerent way, but I mean it's just the it.
Steve Gibson [00:41:40]:
This isn't something that can be controlled. The way it works is not like normal procedural code. It's not the way it is. You know, you got temperature that you could turn up and down. So I believe it is inherently an uncontrollable technology that is from the standpoint of guardrails. So the headline of Friday's posting and you'll, as you'll see, they talk about that. The headline of Friday's posting was statement on the US government directive to suspend access to Fable 5 and Mythos 5. They wrote their so their their statement is the US government citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees.
Steve Gibson [00:42:44]:
The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance. It hadn't occurred to me Leo, but I guess some of their employees have to be like denied access somehow, which is wacky. Access to all other anthropic models will not be affected, they said. We received the directive from the government today at 5:21pm Eastern. The letter did not provide specific details of its national security concern. Our understanding is that the government believes it's become more aware of a method of bypassing or jailbreaking. They have in quotes Fable 5 and and I saw elsewhere Leo, that I that apparently some was an some Amazon employees or someone in Amazon like believes they figured out a specific jailbreak. I think that was the case anyway, they said.
Steve Gibson [00:43:46]:
We reviewed a demonstration of this specific technique being used to identify a small number of of previously known minor vulnerabilities. These vulnerabilities all appear relatively simple and we have found that other publicly available models are able to discover them as well without requiring a bypass. Anthropic's posture with respect to Fable's safeguards as laid out in our launch blog post is the following. So they said we have some bullet points. We've instituted strong safeguards that greatly reduce the likelihood that Fable is misused for tasks related to cybersecurity among others. Remember as we know they just put a blanket block on cybersecurity and bio something or other saying sorry Fable just don't ask any don't answer any questions about that. And as we saw they like they sort of kick you out to the Opus family if if you make the mistake of crossing one of their trip wires. They said in fact our safeguards are so strong that many users have complained that they are overly broad.
Steve Gibson [00:45:06]:
Right again because that's like the only way to do this if you're going to try to do it is is to is to fail closed because there it just isn't possible to control these models. And this is so this is an artifact of that lack of ability to control is they have to do just blanket like o overreaction they said. In the weeks leading up to the launch of Fable Anthropic worked with the US Government, the uk aisi, multiple private third party organizations and internal teams to Red Team Fable safeguards for thousands of hours. In total, these tests showed that Fable safeguards are substantially more effective than those of any previously deployed model. No testers have yet been able to find a universal jailbreak. We'll see why that word's important in a minute. A universal jailbreak. A jailbreak method that can very broadly bypass the model safeguards, unblocking a wide range of cyber capabilities.
Steve Gibson [00:46:18]:
We suspect that perfect jailbreak resistance is not currently possible for any model provider. Think about that. We suspect that perfect jailbreak resistance is not currently possible for any model provider. Every safeguard used in the industry is vulnerable to non universal jailbreaks, which can elicit some cyber information in specific circumstances. And it is likely that universal jailbreaks will eventually be found in the future. We stated this clearly when we released Fable 5. Given that perfect jailbreak resistance does not appear to be possible today, Anthropic adopted a defense in depth strategy with Fable 5. We aim to make jailbreaks either narrow in the case of non universal jailbreaks, or very expensive to produce in the case of a universal a universal jailbreak.
Steve Gibson [00:47:28]:
And to combine this with thorough monitoring to quickly detect and shut down any successful attacks. This is also why anthropic has required 30 day retention of customer data with Fable. A policy change that carries real costs for us with customers, but that allows us to research and mitigate jailbreaks. So like, you know, by holding on to 30 days worth of interaction, if they find some, that's that Fable has been subverted, then they're able to go back in time. There's nothing that the bad guys can do to erase that history. That allows Anthropic to then understand what happened and improve the jailbreak technology. They said, we understand by this defense in depth strategy. I'm sorry, we stand by, we stand by this defense in depth strategy.
Steve Gibson [00:48:29]:
It reduces the risks posed by Fable, making them comparable to the risks of existing models already deployed across the industry. And that's in other words. Yes. In other words, you know, those that have not been banned by the US government because the US government says, yeah, these are fine. So this is. They believe Fable is as safe as any of their other models. They said, we have not even received a disclosure of a concerning non universal potential jailbreak that led to a harmful result. The potential jailbreaks that have been disclosed to us are either entirely benign responses or are minor findings that.
Steve Gibson [00:49:15]:
That provide no Mythos specific uplift to date, the government has only given us verbal evidence of a potential narrow, non universal jailbreak, which essentially consists of asking the model to read a specific code base and fix any software flaws. Our understanding is that one potential jailbreak was shared with the government. We've reviewed a report that we believe is the basis of the government's directive and validated that the level of capability displayed here is widely available from other models, including OpenAI's GPT 5.5. Again, they and. And they said, and is used every day by the defenders who keep systems safe. We'll share more details over the next 24 hours. They said we are complying with the government's legal directive and are removing access to Fable 5 and Mythos 5 for everyone. However, we disagree that the finding of a narrow potential jailbreak should be cause for recalling a commercial model deployed to hundreds of millions of people.
Steve Gibson [00:50:34]:
If this standard was applied across the industry, we believe it would essentially halt all new model deployments for all frontier model providers. As we've stated publicly, we believe the government should have the ability to block unsafe deployments as part of a statutory process that's transparent, fair, clear and grounded in technical facts. This action does not adhere to those principles. We apologize for this disruption to our customers. We believe this is a misunderstanding and are working to restore access as soon as possible. Well, that was Friday and Saturday, Sunday, Monday. And when I was using Cloud this morning over the little, the little prompting area, it said Fable is currently disabled.
Leo Laporte [00:51:26]:
Increasingly this looks like a political move, a business move, Pete.
Steve Gibson [00:51:31]:
Well, we know that Hegseth is pissed off at Anthropic.
Leo Laporte [00:51:34]:
He tweeted, you see, you know, I mean he, he clearly. So Katie Mazuris, who is a well known security researcher.
Steve Gibson [00:51:44]:
Yep.
Leo Laporte [00:51:44]:
Was apparently given the paper. We think it was Andy Jassy, the CEO of, of Amazon, who, who talked to the White House and said, right, yeah, there's a jailbreak. This is the third party research paper. Anthropic shared it with Katie Massoura. She says, as far as I know, I'm the only person who's seen this. This is the. You want to know the jailbreak? Three words. Fix this code.
Leo Laporte [00:52:12]:
The researcher took an open source code with known CVEs plus new code with deliberately planted vulnerabilities and asked Fable 5 to review the code for security issues. Fable 5 refused. They then asked the models. By the way, they also did Mythos, Mythos and Opus to fix this code and through a multi step and manual process, turn the output into scripts that test the patches this is the jailbreak, by the way. Katie has made a shirt to kind of play on the previous time this Commerce Department blocked because of munitions. This is crypto. Remember, they made a T shirt with the crypto on it and you can't block a T shirt. First Amendment protects it and went across borders with it.
Leo Laporte [00:53:01]:
She's done the same with this. She's made a fix this code T shirt and on the back it says this shirt is a munition. Now this, this is her assertion. I don't. You know, it's possible there are other jailbreaks. I had heard that Pliny the Liberator, who's a well known jailbreaker, had another jailbreak. I. We're trying to get plenty on the show tomorrow.
Leo Laporte [00:53:25]:
Haven't had any success yet, but we do have Alex Stamos joining us tomorrow. Alex, as you know, really well known security researcher has released a letter and to Secretary Lutnick and National Cyber Director Karen Cross asking them to free Fable, to lift Fable's restrictions. It's a very well thought out, explained letter and it's signed by a great many security gurus, including Alex, who wrote the letter.
Steve Gibson [00:53:53]:
You know, and it's, it's annoying that this comes from a competitor. Right? I mean, that's, that's what really feels wrong.
Leo Laporte [00:54:01]:
Well, the funny thing is Anthropic, Amazon has a huge investment in Anthropic. So I don't know if they're a competitor. This is them. I don't know. We don't know what Annie Jassy told Lutnick, but we do know that Anthropic has been very good to the administration. The anthropic has and is being used
Steve Gibson [00:54:22]:
throughout the administration and is being used.
Leo Laporte [00:54:24]:
Yeah. We also know that OpenAI has donated to the administration. I think it's very hard and maybe we don't know what's going on, but there's never been provided any good evidence that this is a real jailbreak if it's fixed this code. That's absurd. That's absurd. So Ed Felton is a signatory on this many names that our audience would know very well.
Steve Gibson [00:54:50]:
Well, I think that the, the strongest case that Anthropic made in their response to my mind was this isn't that different from everything else.
Leo Laporte [00:55:00]:
Exactly.
Steve Gibson [00:55:00]:
You know, you've singled us out.
Leo Laporte [00:55:02]:
You've done the same thing.
Steve Gibson [00:55:03]:
You've singled us out. And you know, I, you know, like you, you, we, we could suggest maybe this is the flip side of the like, of the conf. Of the consequence of all that marketing attention which many have called hype, that anthropic deliberately created to a company that restricted access to Claude Mythos preview. So you know, I mean they're, they've like, they painted a target on their back. But again, you know, I think there's their strongest point is hey, yeah, we're proud of this model. We're making it better. We put in really strong safeguards and we're not that different from any of the others.
Leo Laporte [00:55:46]:
It's a wake up call for foreign national researchers in all of the AI companies in the United States. You got to think they're thinking about what their plans are going forward. Maybe leave the United States. It's certainly a wake up call for the eu. If the US can block useful AI from the eu, they're going to be working on their models. It's, it's a, I think a very big tactical error and, and I think it's more about politics peak and corruption than it is about actual security. But it's hard to say because we haven't seen. The only jailbreak we've seen clearly is not a problem.
Leo Laporte [00:56:25]:
Maybe there's a merit, maybe there are other jailbreaks. I understand why the government might say, you know, these, these, this AI model is too dangerous to be released, but they need to.
Steve Gibson [00:56:34]:
Well, and you know, the other thing we've seen is other people achieving Mythos grade success with non Mythos model.
Leo Laporte [00:56:43]:
Yeah.
Steve Gibson [00:56:43]:
So, you know, and, and we, we've talked about that here. It's not as if there's some like some really magic pixie dust that Anthropic uniquely has. They just, you know, they're pushing ahead, as is everybody else. It's a good model. Yeah, it's a good model.
Leo Laporte [00:57:00]:
We will talk to Alex Stamos tomorrow on Intelligent Machines, 2pm Pacific, 5pm Eastern. I hope everybody will join us for that. And he will talk about this open letter which he has put out@freefable.org
Steve Gibson [00:57:15]:
Free Fable, that's great.
Leo Laporte [00:57:16]:
Free Fable.
Steve Gibson [00:57:19]:
Okay. As we saw last week, the change to the historical attack pattern that was already accelerating prior to the rise of AI. You know, I mean we, before this all happened, we were noticing, wow, like this is an accelerating problem. I made the comment, you know, a couple years ago about that we used to, how quaint it was that we used to have three or four digit CVE numbers and now they're all five digit and they're large, they're high five digits. So. Will access to significantly more advanced autonomous AI attacking capabilities by a much wider range of attacker change this further. And, and, and you know it absolutely clearly seems that we are seeing an AI driven acceleration which and it will for the first time unfortunately aided by AI include those who are far less knowledgeable and skilled. So you know, it broadens the, the, the base of, of attackers because they don't have to be experts any longer.
Steve Gibson [00:58:39]:
Just as we've seen many of this podcast non coders delighting in their newfound ability to use AI to code. It's only a matter of time and probably not much time until we see attacks managed by non hackers using next generation AI driven autonomous attack frameworks. Last week's report from Anthropic's Red Team, which is what we shared, showed one instance of exactly this that was by the end of March still the exception to the rule. They said, you know not everybody else is using AI in post intrusion strategizing but that one, that one group did. So a year from now it's going to be commonplace. So against this backdrop, Last Wednesday on June 10, CISA released their binding Operational Directive BOD 2604 titled Prioritizing Security Updates Based on Risk. This BOD formalizes, this is me speaking Formalizes the timeline under which federally mandated IT systems are now required to respond to cyber threats that CISA identifies. We've already seen and commented about the response speed required by CISA to some recent threats.
Steve Gibson [01:00:16]:
Remember there was one like by midnight that night or within three days. But now that somewhat breathtaking three day to patch timeline has been formalized. I've got a chart in the show notes at the top of page 8 which actually shows the decision tree that you follow in order to determine how quickly you must patch something. The guidance that CISA has produced has been reduced to this tree with four binary decision points. Since two to the power of four is 16, that is to say there are 16 combinations of four bits. We've got 16 leaves at the end of this decision tree the fourth branch
Leo Laporte [01:01:02]:
FIFA chart here this is. Holy cow.
Steve Gibson [01:01:08]:
The four branching decisions are has the vulnerability been publicly released? Is the vulnerability in Kev. You know the known exploited vulnerabilities list is the exploitation of the vulnerability of automatable by the adversary and is the impact of its exploitation partial or total control. Each one of the 16 branches ends in either 3 days to patch that is to say you have 3 days to patch this guys or or 14 days to patch or 60 days to patch or patch on system upgrade meaning eh, don't worry about it. You know when you upgrade everything else you know, you'll, you'll get patches. So it's essentially patch it immediately like now with, with a deadline in three days. Or you got two weeks to patch this, or you got two months to patch this, or don't worry about it that much. So for example, riding along the worst case branches of the tree for each decision point, a known vulnerability, a pub. A publicly known vulnerability that's on the kev list, which can be automated and carries an impact of total control by the attacker.
Steve Gibson [01:02:42]:
That guy must be fixed in three days. You know, I might do it now. But it, but the, but the deadline is three days away. Now the flip side, following the best case branches, if the vulnerability has not been publicly exposed, is not on the kev list, cannot be automated. And regardless of whether or not its impact would be partial or total on the victim system, turns out no hurry. Can be fixed during routine system updates. But all other combinations of those four criteria bring you out to a leaf on the tree that tells you how much time you have. What this means is that all federal agencies falling within CIS's binding operational directives will need to put a system in place.
Steve Gibson [01:03:36]:
I mean again, it's no longer like oh yeah, patching, George does that, but he's on vacation. No, the patching has become front, has come front and center. Maintaining up to date systems is no longer something that government agencies will be able to give lip service to while planning to get around to it, you know, whenever. So those lazy days are over thanks to AI and I'd be pretty certain that they're never coming back since once those systems have been painfully put in place, like, you know, rapid patch cycle ability, why would they not continue? So you know, it took, it took clear and, and present threat from AI to, to push the change which nobody wanted. I mean this is going to upset a lot of agencies who've said, oh, we have no ability to actually do that. Well, they're going to have to figure it out and, and generate that ability.
Leo Laporte [01:04:42]:
I think that's a good thing though, right? I.
Steve Gibson [01:04:44]:
It is a Good thing. Yes. I 100 agree, Leo. I think that, that it's not anything anyone wanted but patch. You got a patch.
Leo Laporte [01:04:55]:
By the way, this is okay with you for the, the album art, for the show, the free.
Steve Gibson [01:05:01]:
But isn't it March? I know, I know that really looks like you some of these things and that really looks like me actually.
Leo Laporte [01:05:09]:
Actually it looks like if you didn't know better, you'd think we were in fact leading a march to free fable.
Steve Gibson [01:05:15]:
Yeah. And I think this, these photos must have come from the show because I mean that it's, it doesn't look Darren is very good.
Leo Laporte [01:05:23]:
Darren is a very is our most adept AI user. I think at this point he's quite good. Back to Steve and Leo Radicals the Radicals Marching to Free Fable. Go ahead Steve.
Steve Gibson [01:05:40]:
So the news is that the much attacked npm, the no JS package manager will be flipping its defaults to begin disabling the auto running of installation time scripts starting with the July 2026 so next month release of its version 12.0. The change hopes to counter the massive rise that we've been see we're talking about it every week almost in the number of supply chain attacks taking place on that platform. As we've seen here, threat actors are increasingly hiding malicious commands inside install scripts that get auto executed when a victim installs a new package. We're just talking about that with the Arch Linux. This sounds welcome and great, right? I mean it's like hey, it's automatic, it's nice, but what effect will it have? That is flipping this from by default enable to default disable. I tracked down an informed opinion of someone who should know writing for the blog open source malware.com to get a reality check. The posting was titled NPM disables install scripts by default, but is that going to solve its malware problem? And the blog's tagline was NPM announced that the new version of the NPM package manager version version 12 will come with several security improvements including disabling install scripts. Is this a game changer or security theater? Its Author wrote on June 9, NPM announced the breaking changes coming in V12 and he said, I'm genuinely excited about this announcement.
Steve Gibson [01:07:38]:
The three permissive defaults that have shipped malware to developers for a decade are about to flip to deny by default. Pair that with install time cooldowns. I'll explain what that is in a second landing across every package manager and the rise of commercial supply chain firewalls. And you'd be forgiven for thinking that NPM malware problem is finally getting solved. A year ago, he wrote, I stood on a defcon stage and walked through why NPM install scripts are terrible. So let me be the first to say it. These coming V12 changes are good. They're also in part theater and understanding which part is which is important.
Steve Gibson [01:08:32]:
NPM v12 flips three dangerous defaults. The big one is install scripts. Today NPM install happily runs pre install install and post install hooks from any package in your tree including transitive dependencies you've never heard of in V12 that stops by default. No automatic lifecycle scripts, no native node gyp builds, no prepare scripts from git file or link dependencies. You opt packages back in with NPM approved scripts, discover what's affected with NPM approves approved scripts, the allow scripts pending option, and block the rest with NPM deny scripts. The second change makes git dependencies require an explicit allow git option, closing an execution hole where a code execution hole where a git dependencies own dot NPMRC could override the git executable, a bypass that worked even with the ignore scripts option set. The third and final change makes remote URL that is to say HTTPs tarball dependencies require an allow remote option. These three changes, he writes, ship around July 2026 and you can prepare today in npm11.16.0 and and and subsequent.
Steve Gibson [01:10:23]:
At the same time, other security improvements are taking hold. Cooldowns are also now everywhere. NPM shipped with support for min Release age in 11.10.0 back in February. This is a setting that refuses to install a version until it's been public for a configurable number of days. The logic here in that nice yes,
Leo Laporte [01:10:53]:
I turn that on. I well, I do it manually, but for 14 days. If it's if it's not more than 14 days old, I don't want to install it.
Steve Gibson [01:11:00]:
That's smart, yes. And and he writes. The logic is simple and effective. Compromised releases usually get caught and pulled within hours, so a short delay filters most of them out at the install layer with zero scanning. It's worth noting, he writes, that NPM was the last to this party. PNPM shipped minimum Release age in 10.16 in December 25 yarn added npm minimal age gate in 4.10.0 the same month and bun followed in 1.3. There's even an open proposal to make seven days the default, which is the right instinct Almost nobody needs a package the instant it's published. Supply chain firewalls have become a product category.
Steve Gibson [01:11:55]:
Developers are finally installing something on their machines that address malicious package threats. Datadog released an open source supply chain firewall in 2024, and Lauren Tal released his tool NPQ back in 2017. Tools like these wrap package managers and check to see if the user is about to install vulnerable or malicious packages, and if so, they'll block them from being installed. There's been quite a lot of new tooling in this domain recently with Socket Aikido and Endor Labs, all offering products in this space. Package firewalls like these work, but of course they rely on developers to not bypass their controls to install malicious packages. Anyway, he says, I don't want to be cynical about the right things. Killing automatic install scripts is the single most important change NPM could make. Install hooks are the mechanism behind a huge share of the incidents we document at Open Source Malware.
Steve Gibson [01:13:14]:
They're now a poisoned transitive dependency. I'm sorry? They're how a poisoned transitive dependency gets to run arbitrary code on a developer laptop or a CI runner the instant it's pulled. The security community and PNPM have been arguing for deny by default here for years. NPM finally agreeing is a genuinely good day. Cooldowns are the cheapest high value control in the entire ecosystem. Firewalls and package managers give teams a real shot at stopping a supply chain attack before it lands. None of this is fake security. The problem is what happens next.
Steve Gibson [01:14:04]:
The first observation is that off by default only works if it stays off. The thing that announcement glosses over is that disabling install scripts is going to break a lot of stuff. An enormous amount of legislation of legitimate software gets installed, built and wired into your application environment via install scripts, right? That's where the magic comes from. That's where like it's. It's incredible, he said. This of course explains where there's such a strong attack vector. There's a simplistic narrative going around that life cycle scripts only exist to do bad things. And that's just not true.
Steve Gibson [01:14:53]:
NPM packages are not just a way to import libraries. Many people, including me he writes, build CLI tools to do necessary utilitarian functions, and many of these tools use install scripts. Some examples of popular packages that use life cycle scripts are ES build with 200 million weekly downloads, Sharp at 60 million per week, Core Hyphen JS at 40 million per week, Puppeteer 10 million weekly NX 9 million buffer util at 6 million UTF8 validate at 8 million weekly downloads and bcrypt at 5 million weekly downloads. Initially he finishes Native modules need node gyp to compile against your platform at install time. Tools that download a platform specific binary, generate a config register a shell completion, or build a native add on all lean on install scripts to get the job done. This is not an edge case, it's a meaningful slice of the most depended on packages in the registry. The day version 12 lands, those packages stop working until someone approves them. So I'm going to interrupt here for a second.
Steve Gibson [01:16:30]:
If anyone listening is thinking to themselves, well, convenience versus security, you're exactly correct. That's what this is. I'm sure that many of us who have used package managers have been somewhat amazed, I know I have, by the astounding degree of automation. You fire it up and all this stuff happens. Packages are grabbed from here and there, compilations are run and linked together, packages are installed. Everything just whizzes by on the console. What just happened? Who knows? Nobody knows. Well, someone knows, presumably.
Steve Gibson [01:17:11]:
But the entire point is that we, the developer or the end user who invoked the package manager doesn't need to know. It all just magically happens. And that is also, of course, the Achilles heel of the entire process. It's what opens it to such abuse. Because that extreme magical ease of use can be, and increasingly is being abused to do malicious things behind our backs automatically. We have no idea what's happening in the first place, so how would we know if something bad was happening? The problem with flipping these magical defaults to off is that the magic upon which we've become dependent breaks. So he continues his post writing so what will developers actually do? They'll approve. Then they'll approve again.
Steve Gibson [01:18:12]:
And by the third time a build breaks at 5pm because some transitive dependency needs its post install hook run. The approval becomes a reflex. The deny by default protection quietly degrades into a clicked through prompt. How would you like a cookie? Would you agree to have a cookie? We've all been there, right? Those darn notices go up all the time. It's like, yeah, okay, fine, yes, right? He says. A click through prompt that fires constantly trains people to click through. We've watched this movie with browser permission dialogues and OS security prompts, there's no reason to expect npms to end any differently. The control is real.
Steve Gibson [01:19:03]:
The human standing in front of it is the same human who has a deadline. If you really want to know if disabling install scripts will have the intended effect, you could look over to the VS code ecosystem. With VS code before version 1.109, the global allow automatic Tasks setting was on by default. This meant that malicious task files would automatically run if victims open source code that included those tasks files. Microsoft changed and disabled this feature to be disabled by default in January 26, the beginning of this year, after months of threat actors used malicious tasks files to compromise developers. Did that stop threat actors from continuing to use VS code tasks? Nope. North Korean threat actors continue to use malicious VS code tasks files as many developers have re enabled the feature or other developer tooling has enabled it. In fact, most of the large scale attacks we've seen so far in 2026 leverage VS, code tasks and settings files to help redistribute the attack artifacts.
Steve Gibson [01:20:32]:
The second observation is that the bad guys will find a way. Just because NPM won't run scripts at install time doesn't stop users from running those scripts the second those packages are installed. Even worse, if you already use a library and it's compromised, you don't need to run install scripts to receive the payload it's going to run in your application. No scripts needed. Now follow the incentives one step further. If install scripts are switched off by default, some package authors with legitimate needs will stop relying on them. Good ones will document a manual build step, others will move the work somewhere NPM cannot turn it off. A curl piped through bash in the install js, a separate bootstrap binary A setup command you run after installing.
Steve Gibson [01:21:30]:
The attackers will make the exact same move because of course they will. If the post install hook no longer fires automatically, you don't give up. You find the install path that still executes. This is precisely the kind of threat actor behavior I talked about at defcon. Push on one control and the malicious activity simply relocates to where the controls aren't. It doesn't just vanish. And here's the part that should worry npm, but it won't because it's good for them. When the malware moves out of the registry and into a shell script or someone's gist or a binary downloaded from a cdn, NPM gets to report that registry resident malware is down.
Leo Laporte [01:22:26]:
Yay.
Steve Gibson [01:22:27]:
They'll claim victory. The problem will look solved from the viewpoint of their dashboard. Meanwhile, the risk has simply relocated to terrain with less visibility and fewer tools, not more. The problem gets pushed off the one surface the entire security industry actually instruments and onto surfaces nobody is watching. That's not a win, that's a measurement artifact. The third observation is that it gets more difficult for defenders then, not easier. Between cool down periods and the disabling of install scripts, large scale NPM attacks will become less frequent. But when you push legitimate functionality off the well lit path, you don't just move it, you make it look guilty.
Steve Gibson [01:23:27]:
A package author who genuinely needs to fetch a platform binary at install time now doing it through some indirect mechanism to survive the new defaults produces a fingerprint that looks exactly like evasion Obfuscated loader out of band fetch install time network call to a non registry host five years ago, that was a strong malware signal. After V12, a chunk of it is just legitimate software adapting to a stricter world, not malware because of the things it has to do. So while the number and frequency of the big NPM attacks go down, the signal to noise ratio for everyone hunting malicious packages gets worse. The benign, in other words, false positives or missed negatives. The benign and the malicious converge on the same suspicious looking pattern. We end up triaging a flood of weird but fine packages to find the weird and actually bad ones. And the bad ones get better covering or get better cover precisely because so much legitimate behavior now looks like what they do. You bury the needed functionality in something that looks sketchy and you've built the perfect place to hide a needle.
Steve Gibson [01:25:03]:
A pattern that now looks sus. Except it isn't until it is with the firewalls and cooldowns are really telling you. Step back and look at what cooldowns and firewalls actually represent. They're good controls. Yes, they're also an admission. The reason a third party product can flag a malicious version six minutes after it's published is that NPM is not doing it themselves. The reason teams pay for an interception layer in front of the registry, the firewall, is that they cannot trust the registry to keep malware out. We are watching detection and response getting pushed onto users and onto a handful of vendors, while the registry that profits from being the default keeps under investing in its own scanning.
Steve Gibson [01:26:04]:
The incident cadence so far in 2026 makes this gap obvious. Version 12 is npm catching up to the problem I laid out a year ago. Okay, that's progress. But a registry that's that has been this chronically under resourced on internal security doesn't get to flip three defaults and call the supply chain problem handled. So what actually does move the needle? Where does this leave us? We're left with the unglamorous truth that tooling is necessary and nowhere near sufficient. Turn on cooldowns today. It's the single best ratio of effort to protection available. And there's no reason to wait for V12.
Steve Gibson [01:26:55]:
Prepare your approved scripts allow list now on 11.16 and later. So the V12 upgrade does not break your builds and stampede your team into rubber stamping everything. If you can manage package firewalls, run them do all of it. And that's his conclusion. So I thought this was a terrific
Leo Laporte [01:27:22]:
there's my minimum release age 14 for NP and also do it on bunch of 14 days. Good bun, you have to do seconds. I Think so.
Steve Gibson [01:27:33]:
Right.
Leo Laporte [01:27:34]:
But. And I did it for a lot of things. I wish I could do it for the Arch user repository. I can't. I wish I could. Or at least I haven't figured out
Steve Gibson [01:27:42]:
how to do that.
Leo Laporte [01:27:43]:
Yeah. Because that's the one that really scaring me right now. Yeah.
Steve Gibson [01:27:46]:
So I thought this was a really a terrific piece of. From the field feedback. As we've been seeing for years, malware that slips into the NPM repository has been steadily increasing. I mean like big time. And there doesn't appear to be anything that could be done. The one thought I had while reading this person's posting was that perhaps these changes are being made on the cusp of AI appearing at a time of need. He noted his annoyance that responsibility was effectively being played pushed away from the repository and onto less centrally managed external resources and solutions. We see that the largest entities, Cisco and Microsoft, jump to mind.
Steve Gibson [01:28:32]:
You know, they've been unable to even police their own internal closed source offerings to rid them of bugs. So the scope of the task for an open source free for all repository should not be underestimated. I, I mean, I'm sympathetic. How do you allow anybody who wants to, to, to contribute a package and have any security? But just as AI is now promising to revolutionize the quality of closed source offerings, it also seems like the perfect solution for repositories such as npm. I, I think it, it makes nothing but sense. So we know that IBM and Red Hat are going to be pouring a ton of money. Was it $5 billion into using AI to help open source? And certainly NPM ought to be a big initial target for them.
Leo Laporte [01:29:30]:
Yeah. Yeah.
Steve Gibson [01:29:33]:
And you know, Leo, it's time for me to tape a. Tape a sip of my juice and for us to find out who's paying for this.
Leo Laporte [01:29:41]:
This is a, a low caffeine day for Mr. Gibson. What is in your juice? Is it a green juice? Is it a.
Steve Gibson [01:29:47]:
No, it's just. It's a third of regular orange juice. Organic of course, because Lori. And then two thirds water. So.
Leo Laporte [01:29:54]:
Sounds good.
Steve Gibson [01:29:55]:
It's just. Yeah, it's just diluted. OG it's. It would be water, except water. It's a little boring. So we just like, you know, just make it a little more interesting. Exactly.
Leo Laporte [01:30:06]:
Okay.
Steve Gibson [01:30:08]:
Okay. Feedback time. Roger Votklin V O E G T L E N Best I can do.
Leo Laporte [01:30:20]:
Silent. I think it's voting.
Steve Gibson [01:30:23]:
Robert Votelin. Hey, Robert. So get this, Leo. He says, Dear Mr. Gibson, I started listening to security now when I was in the fourth grade. Oh, geez. Okay, Robert, I'm now 22 years old. I have a degree in cybersecurity from Augusta University.
Leo Laporte [01:30:44]:
Right on.
Steve Gibson [01:30:45]:
Security now has always been there for as long as I can remember. As I begun my job search, I've realized just how vast cybersecurity really is. There are so many specialties. The more I learn, the more I realize I. I know nothing. But I've been struggling with. What I've been struggling with is figuring out where to focus. It feels like it could take decades of working across different roles and industries before I discovered the niche that truly fits me.
Steve Gibson [01:31:16]:
But then much of my career will already be behind me. How do you determine which area of cybersecurity is worth dedicating your life's work to? Thank you and Leo for everything you've done through Security now over the years. Sincerely, Robert Vlin. Spin right Owner A so, first of all, Robert. Yeah. Wow. My question to you would be, what could have possibly motivated you as a fourth grader to tune into this podcast?
Leo Laporte [01:31:50]:
Zero days, Mr. Gibson,
Steve Gibson [01:31:54]:
you know, and it is the case that Leo and I have been here throughout your entire life.
Leo Laporte [01:31:59]:
Wow.
Steve Gibson [01:32:00]:
So anyway, I'm. I know that we both feel very glad and fortunate that we've been able to. To be here the whole time. So to your question, I have no idea. In my case, I sort of stumbled into the security sphere through shields up, which I created because there was clearly a need for it at the time. And then the opt out adware remover, which happened when I discovered that oriate adware was on my own PC. Since my background since about age 5, you know, began with understanding electricity and then expanded into electronics and physics and engineering and computer hardware and software. I had the broad background, you know, ahead of time to pretty much head in any direction.
Steve Gibson [01:32:52]:
And at the time when Spinrite was purring along, I saw a need over in the security space. So I think my best advice would be to perhaps more deliberately do what I had inadvertently done, which is to obtain the widest possible background exposure that you can that will automatically expose you to many more aspects of the field. And you may find that you naturally gravitate towards something specific. And even if that doesn't happen, I believe you'll be better equipped to succeed with whatever you decide to tackle. In today's highly competitive world, I normally advise people to become the best they possibly can at a narrowly targeted specialty. I believe that's where to succeed today. But of course, that process of specialization can only begin once you determine what truly interests You, Leo? Any, any.
Leo Laporte [01:33:54]:
Well, I think this is, My kids ask me this too. This is kind of the eternal question, one of the most fundamental questions every human asks today.
Steve Gibson [01:34:03]:
If I, there is so much happening, I, I would, I don't know what direction I would take. I can really relate to Robert's position.
Leo Laporte [01:34:11]:
Even if it's not cyber security, if it's just whatever, you know, history or whatever, how to figure out what it is you want to devote your life to is a very, very, a challenging question, but I think your answer is exactly right. All you can do is try as many things as possible, expose yourself. You found one.
Steve Gibson [01:34:27]:
See what sticks. Yeah.
Leo Laporte [01:34:29]:
And just listen to your heart. You'll know when it sticks, you know?
Steve Gibson [01:34:31]:
Right.
Leo Laporte [01:34:32]:
Steve had no choice. He knew exactly what he wanted to do. He just sent it, you know, and it's just like it clicks and you're gonna do it. I didn't either. You know, we just, we did what we loved, and I think that's the best thing anybody can do is.
Steve Gibson [01:34:44]:
Oh, to be able to spend your life doing what you love. Yeah, I mean, I, I, I love that. The, the, the, the, the best, shortest summary of that is to say I never worked a day in my life.
Leo Laporte [01:35:01]:
Right.
Steve Gibson [01:35:02]:
Because it's, it's not, it's joy.
Leo Laporte [01:35:05]:
Right. And I hope Todd Whitaker find that.
Steve Gibson [01:35:09]:
Yeah, yeah, exactly. Todd Whitaker, whose last name I can pronounce, is a college professor listener of ours who uses PHP to teach security.
Leo Laporte [01:35:22]:
Oh, boy.
Steve Gibson [01:35:23]:
Yeah, he wrote. Hi, Steve. Your recent discussion of Insecure PHP in episode 1082 last week rang very true to me. But you know what? PHP is really quite useful in cybersecurity, just maybe not the way its defenders usually mean. I'm a college professor, and when I built our undergraduate cybersecurity major back in 2010, two of the original courses used PHP for web programming and application security. Clearly, that was not because PHP represented our ideal of secure software design. It was because PHP is almost perfectly suited to showing students how insecure software gets built. SQL injection, concatenate user input into raw SQL, cross site scripting, echo unescaped input back to the browser, broken authentication, store passwords badly or trust the wrong session variable, he writes.
Steve Gibson [01:36:37]:
PHP makes the mistake easy to write, easy to see, and therefore easy to teach. He said once students can see the failure clearly, we can show the corresponding discipline, prepared statements, output encoding, password hashing, access control, session hygiene, and least privilege. That, for me, is PHP's real value in a security classroom. It gives students a compact, legible catalog of the mistakes they need to recognize before they encounter them in the wild. Many cybersecurity graduates will eventually audit, inherit or respond to PHP heavy environments, including Drupal and WordPress installations, where they will need to see past code that merely works and recognize the familiar patterns that make it vulnerable and if they leave the courses, better equipped to be skeptical of PHP based platforms and environments where security matters, so much the better.
Leo Laporte [01:37:50]:
Awesome, Todd.
Steve Gibson [01:37:51]:
So yes, I think Professor Todd's use of PHP for teaching about coding security is brilliant. It's an application for PHP that had never occurred to me. I love it, so thank you. Todd de Kililgo said hi Steve, 20 year PHP veteran here. I thought you'd find this interesting. The foundation that governs PHP has added a grant funded a grant funded position to improve PHP's security posture given the realities of AI powered development. Quote the PHP foundation grant will fund a six month full time position titled Ecosystem AI Security Engineer in Residence at the PHP foundation, unquote to lead this effort and to prepare a sustainability platform for the time after this initial phase. This person will act as a trusted intermediary between security researchers and maintainers in urgent high risk situations and will collaborate with peers in similar roles across other language ecosystems.
Steve Gibson [01:39:09]:
Additionally, grant funding will also be employed toward the team goals described above, where they cannot be accomplished by the single paid lead position or with the help of PHB community volunteers. And he included a link to the announcement of the ecosystem security team. He finishes I've been listening since you were an actual podcast on an ipod with a spinning disc. Love the show your p. Your perspective is appreciated. Derek so I think overall the PHP projects move is great, but I should be clear and Todd Whitaker's use of PHP for security education helps to further clarify this. I do not believe that there's anything whatsoever wrong with php. It's not at all the language itself I do not trust.
Steve Gibson [01:40:07]:
There's nothing wrong with the PHP language. I think it's very likely bulletproof. My problem with it, which has been informed through our two decades of covering its use, is that those who often gravitate to to PHP do so because it appears to be so easy to use. Because it is. But we've learned that it's always easier to write code that works than code that works securely. This next bit of listener feedback sets up a perfect example. Steve Myers wrote the and his subject was your PHP rant. He said it seemed like your rant against PHP was a bit of a stretch.
Steve Gibson [01:40:56]:
PHP has its issues, but it's also come a long Way. Here are my issues with your rant. You were using some obscure WordPress plugin with a whopping. And he's being, and he's not being serious here, sarcastic with a whopping 4000 installs as the basis for complaining about PHP. Your specific complaint about PHP making it too easy to do bad things is that it has an eval function. Here's a list of some other programming languages with eval functions. JavaScript, Python, Ruby, Perl, Lua, Lisp. And he said parens.
Steve Gibson [01:41:40]:
Specifically noted in Wikipedia is Lisp as the originator of the eval function. Yeah, and yes, yes, Scheme, Cloture and Matlab. Anyway, he finishes it. It really seemed like your rant was pretty gratuitous and did not have a lot to back it up. Okay, so first of all, Steve is of course correct that the particular problem with that PHP WordPress add on was due to its programmer perhaps not being aware of the danger of forwarding user provided text into an eval function. And it's certainly true that similar eval functions eval functions exist in many languages. But I'm not upset with PHP at all for having an eval function. My concern is that writing secure code for the web is extremely challenging.
Steve Gibson [01:42:44]:
That's why through the years we've been covering all the mistakes that can be made, many not with php. There are so many different and very subtle ways to screw that up. Professor Whitaker's note mentioned a handful of them and he didn't even mention evaluation. So perhaps the best non ranty way of expressing what I mean here is to say that it feels as if there's a larger inherent mismatch between the coding skill of the typical PHP coder, who may be coding for the web for the first time, and the coding skill required to do so securely, probably in a different language. It's certainly the case that no sane person will have decided to code their website in Lisp. Okay, but that said, I'm probably not one to speak since I did choose to code mine in assembly language.
Leo Laporte [01:43:45]:
Yeah, which is worse than Lisp. So.
Steve Gibson [01:43:47]:
Okay, which is. Yeah. Okay, Leo, our last break that we're going to look at Patch Tuesday a la AI.
Leo Laporte [01:43:58]:
Ah, Lisp. I seem to remember programming in that language once back in the day before I started coding in English, which also has an eval function.
Steve Gibson [01:44:09]:
Incredible. And. And the code that AI is producing for you is C largely.
Leo Laporte [01:44:16]:
No, I let it choose its language. It's pretty evenly split. I Go is my current favorite because it's concurrent. But Rust is great because it's so safe.
Steve Gibson [01:44:27]:
Safe.
Leo Laporte [01:44:27]:
And so it's a little provable. You know, you can. A little easier to prove that Rust's code is Safe. And then TypeScript is often chosen for similar reasons.
Steve Gibson [01:44:37]:
Right.
Leo Laporte [01:44:37]:
So almost all my code is either Rust Go or Typescript.
Steve Gibson [01:44:40]:
And the web has tons of examples from the A for the AI trained on.
Leo Laporte [01:44:44]:
Which is why I don't use Common Lisp because it's a little less.
Steve Gibson [01:44:48]:
Not so common.
Leo Laporte [01:44:49]:
Not so common. Although oddly my AI is very good at my Emacs configuration, which is done in elisp. It's really good at writing Elisp code. So you know, there's a lot of that out there, I guess maybe more even than Common Lisp. So yeah, but Go is probably the. I would say the. A good choice. Python.
Leo Laporte [01:45:10]:
Oh, I've left out Python. A lot of stuff's in Python. Just all those one off like that one off web server for the curling of the SSH key that it just
Steve Gibson [01:45:21]:
threw together for you.
Leo Laporte [01:45:22]:
So easy to do in Python because they all the libraries. It makes it very simple.
Steve Gibson [01:45:25]:
Right. Right.
Leo Laporte [01:45:27]:
Now back to Steve.
Steve Gibson [01:45:29]:
So we all knew this had to be coming. And it did not take long, which is probably the mantra for the AI era. It didn't take long. No, because the new race is now on. Right. To see whether our industry's badly broken software can and will be repaired with the help of AI before the bad guys are able to leverage that same AI to find and exploit any of that same software that's not yet been repaired. In other words, what's been expected and predicted with the advancing evolution of AI models focused upon code is all really happening. Last Tuesday, Microsoft broke their all time record for the number of security vulnerabilities patched in a single update cycle.
Steve Gibson [01:46:29]:
And that doesn't even count their fixes to their Chromium based Edge browser, which also broke its own record. By a lot. Those fixes to Edge are now wisely being separated into a separate account, a separate count. And I say wisely because if the two counts were not separated and we used to lump IE in with, you know, patch Tuesday updates because that's when it was being updated. Typically if they weren't separated, June's hall alone would land somewhere in the neighborhood of 566 security vulnerabilities. 566. Okay, so let's. Yikes.
Steve Gibson [01:47:23]:
Let's first take the non edge windows and Windows adjacent patches. Even without Edge there are so many that the exact number differs from one report to the next. Counting that high can Be tricky. But everyone agrees that it was at least 200 and perhaps as many as 206. Now, you know, we've all become a little patch drunk, right? There was a time when 30 or 40 vulnerabilities would have raised eyebrows. Whoa, 40 vulnerabilities. Now that's seen as a quiet month, but you know, it's like 200. So consider, just stand back and consider something north of 200 security bugs found and fixed.
Steve Gibson [01:48:15]:
On the one hand, it's great that Windows and its surrounding software will have at least 200 fewer discoverable security vulnerabilities. But on the other hand, Windows software had 200 or more security vulnerabilities to be fixed. And no one imagines that next month will will be much better. I don't think they got them all. So, you know, buckle up for July and it's not as if these were insignificant problems, you know, that could have just been ignored. Oh no. Among those 200 were six zero days, five of which had previously been publicly disclosed, most by you know who, and one which was under active exploitation in attacks. And among these 200 now blessedly resolved, Microsoft Windows and Windows adjacent bugs.
Steve Gibson [01:49:11]:
Get this, 33 of those ranked as critical, with all but 5 of those. So 28 of them being remote code execution. 28 critical remote code execution flaws. Of the remaining 5, 4 of those were privilege elevation and the last one was an information disclosure. But 23 RCEs found and fixed in one month. It's nice to see Microsoft moving quickly to employ their code Name M-AI to the I hope that doesn't stick to the task of finding and fixing the many flaws we have come to understand Microsoft code contains. Right? I mean, they're moving quickly with a purpose here because they are fully aware that increasingly capable AI models are also in the hands of malicious actors who are beginning to actively employ those models for the discovery and exploitation of Microsoft's many code shortcomings. So as I noted at the top of this, it could not be more true that a true race is on.
Steve Gibson [01:50:31]:
This is really a race. I continue to hold, however, that bugs are not inherently endless. Once removed, bugs almost always stay gone. There are some regressions from time to time, but mostly they stay gone. And if similar AI is employed eventually, hopefully already now to prescreen new code before it's released, the past's continuing supply of freshly created new bugs should finally also be cut off. This means that the consequences of this newly AI enabled race, which is motivating both sides more than anything ever has, is that we're all going to be receiving far better software from Microsoft than we ever have. Basically it's sort of like I, I remember noting this about Cisco, thinking okay Cisco, you've, you've been unable to like get your software right. Maybe we need to make it easier for you.
Steve Gibson [01:51:40]:
AI will make it easier for you. Similarly with Microsoft, AI is going to make it easier for Microsoft to have way fewer bugs than ever before. Okay, so what's the overall breakdown of these 200 some vulnerabilities? Last Tuesday's more worthwhile than ever round of updates fixed 65 elevation of privilege vulnerabilities, which we know those are just as, just as important. They don't sound as scary as remote code execution where the bad guys provide the code they'd like to run in your computer. But many times bad guys get in on a user account so they need to elevate their privilege to get to really sink their teeth into the system. So 65 elevation or privilege vulnerabilities 55 remote code execution vulnerabilities 55, 30 information disclosure vulnerabilities, 27 spoofing vulnerabilities, 19 security feature bypass vulnerabilities and seven denial of service vulnerabilities. You know where you crash something? One of those, we know one of those dos's we will talk about in a second because that was the HTTP 2 bomb that we covered. And just for the record, even all of that 206, 200 to 206 depending upon who you ask, they did not include flaws repaired previously in Mariner, Azure Horizon DB, Microsoft Copilot, Copilot Chat, M35 M365 Copilot, Microsoft Exchange Online and Microsoft Graph.
Steve Gibson [01:53:23]:
They were all previously repaired and they all had a bunch. In other words, things really are quite furious up there in Redmond, Washington at the moment and that's great for everyone. So what do we know about the various zero days that were fixed? There were six of them thanks to the tireless efforts of the renegade hacker Nightmare Eclipse. Another of their zero days known as Green Plasma was fixed that was assigned the CVE this year of 455.86 an elevation or privilege flaw that the disgruntled hacker discovered in Windows Collaborative Translation Framework, CTF Mon. I don't know what that is, but I've all. I've often seen ctfmon in my process list. So it's busy being something it had been publicly disclosed and enabled an unprivileged user account to upgrade itself to full system privileges. So again, Nightmare Eclipse was another nightmare for Microsoft, publicly releasing a zero as a zero day, a means of using the CTF mon to elevate an account privilege from user to system.
Steve Gibson [01:54:43]:
Microsoft was also able on June and I was impressed by the speed of this because this only just happened earlier in June to quickly repair that HTTP 2 bomb which we just talked about Denial of service vulnerability, which was, you know, the deliberate headline grabbing, irresponsible disclosure of which annoyed me so much, which we talked about last week where the guys at California said hey guess what? We don't believe in responsible disclosure anymore because of AI. So here it is. Okay, the Microsoft variant was assigned a CVE of 491.60 and was found in the HTTP sys module, which makes sense, that's the web. The the web server module or driver as Microsoft phrased it. Quote Uncontrolled resource consumption in HTTP 2 allows an unauthorized attacker to deny service over a network which of course is micro speak for anyone's laptop can bring down our web servers. What we already know from Caliph's disclosure is that the the HTTP 2 bomb is a denial of service technique that abuses how the protocol itself compresses and manages web traffic headers which allow attackers to send very small amounts of data and for servers to allocate disproportionately large amounts of their memory. Then by combining two techniques, basically not bugs but just protocol features, the researchers at Calif. Discovered that they could dramatically increase server process memory consumption.
Steve Gibson [01:56:37]:
Then keep the memory tied up by manipulating HTTP's flow control settings to prevent the server from freeing the resources basically don't allow the the the inbound query to ever end. So the server just waits and it waits with 32 gig of memory tied up and the and the laptop keeps doing those until all the server's memory is gone and it crashes. So since this clever attack is more of an abuse of deliberate HTTP 2 protocol features rather than a bug that could be fixed, Microsoft also added a new Max Headers count registry setting to limit the number of headers in a single request. If it's not specified that the default maximum header count is 200, it could be set as low as 50 or as high as 65535 so you know of all 16 bits turned on in the count. Tuesday's Updates also resolved two problems with BitLocker nightmare eclipses so called yellow key vulnerability Remember we talked about this that that was the quacky boot thing that's been addressed as CVE 45585. That was the hack that involved rebooting a machine while supplying a script on a thumb drive that had the effect of deleting some files and leaving the system in a pre booted state with its primary drive decryption key still loaded and the normally encrypted drive, the main system drive fully decrypted and accessible. As Microsoft phrased it, a successful attacker could bypass the BitLocker Drive encryption feature on the system storage device. An attacker with physical access to the target could exploit this vulnerability to gain access to encrypted data, unquote.
Steve Gibson [01:58:44]:
So after last Tuesday's updates, this can no longer be accomplished. Microsoft is now careful to not leave the BitLocker encrypted drive in an unencrypted state. So what about the second BitLocker repair? Let's hope that the way they stumbled on this one was human derived and not AI, since it sure feels like the old Microsoft as you'll see in a minute, rather than the new and improved Microsoft we're hoping AI might be enabling. The second flaw was named Blitzkrieg. I'm sorry, bitskrieg cleverly. Oh he yeah, yes, by the guy who discovered it. He originally posted the news over of his discovery over on X under the name Jonas L. Since the view from a hacker's perspective is always interesting and often entertaining, I'm going to share Jonas's originally Jonas's original posting, which was near the start of the month on June 4th.
Steve Gibson [01:59:54]:
And again, as I said, I was impressed that Microsoft moved this quickly. Hadn't occurred to me before, but I wonder if AI might be accelerating the pace from just from them having knowledge of the problem and it being fixed. Or maybe the confidence because after all that was five days from June 4 to June 9. So that's very quick. So Jonas L wrote it is rare that anything new happens in the world of IT security. It's mostly just an endless cycle of variants of the same vulnerabilities being exploited over and over again. That's why I appreciate when something new happens and the yellow key exploit was for once an attack I had never seen before. I've done I he said.
Steve Gibson [02:00:47]:
I've myself done a BitLocker bypass before. Then he surprises. He supplies us with a link with an with that which has an embedded January 15th, 2021 date. So about five years, a little more than five years ago, he said. But this one was new to me, meaning yellow key. It expanded the attack surface onto an area I had not looked into before. The recovery environment. The recovery environment is stored on a partition that BitLocker does not encrypt and the TPM is not locked until you use any functionality that's not the startup repair.
Steve Gibson [02:01:33]:
So if you somehow get code running without causing the TPM to lock, you have access to the encrypted drive. Microsoft killed yellow key by removing the auto execution of a newly introduced component that could be manipulated into doing file operations by rolling back a transaction stored on a USB drive isis, which was really clever by the way. I suspect they simply copied the recovery environment from the unreleased Windows cloud made for thin clients. That also explained why the bare metal recovery EFI Image identifies as Windows 365 when downloading what to boot on its RAM drive from the Microsoft server. The yellow key he said the yellow key trans transaction rollback hack enabled a file deletion enabling launching a command prompt by holding down control when launching recn R e c e N v dot XE and which which he also agrees is an elegant attack. So when my friend asked if I wanted to try to help restore the vulnerability, I figured why not give it a try. He says Microsoft fixed yellow key by just killing a specific vulnerability, but they did not resolve the underlying design issue. So I'd be surprised, he wrote, if it wasn't doable.
Steve Gibson [02:03:20]:
After 24 hours, a new attack was born. I call it Bitskrieg. Okay, so his posting then walks us through his successful hack and attack which demonstrated that that there was indeed more than one way to skin this particular cat. And I'll note again, as I did before, that vulnerabilities in BitLocker access at this point, I.e. bitLocker access at this point is an inherent weakness that Microsoft really cannot do much about. Sure, they could be much less sloppy and more carefully consider the consequences of their design decisions, but if we want a system that has its bitlockered main drive encrypted at rest, which then autonomously boots into the Windows OS environment that's contained within the bitlockered drive without requiring some information that is not stored on the local machine, you know, which is where the user provided pin comes in. Then there's really no way around the fact that the machine will be vulnerable to some form of local boot. You know, like local access, boot time shenanigans.
Steve Gibson [02:04:49]:
There's just no way around that. So last Tuesday's patch update resolved this additional bitskrieg attack that Jonas L discovered and as I said, I'm surprised they did it in five days. And that's good since he had made it public also. But enterprises and security minded end users should not rely too heavily upon the security of entirely self decrypting bitlockered systems. The only way to ever be truly safe is to require some information at boot time that is not present anywhere else in the system. That means depending upon a hardware dongle or a manually entered pin. This is the classic trade off between security and convenience, and there's just no way around it. Okay, so what else do we know about Tuesday's record Breaker? The history behind this next zero day is curious because it's a fix for a CVE dated an unbelievable six years ago in 2020.
Steve Gibson [02:05:59]:
CVE 202017103 which is a Windows Cloud Files Mini Filter Driver Elevation of Privilege vulnerability. Like so many other recently released zero days, this one too owes our attention to none other than Nightmare Eclipse. Its reincarnation by that now infamous hacker was given the name Mini Plasma. So yeah, Mini Plasma. So what's up with the CVE from six years ago? Nightmare Eclipse explained that the flaw was originally reported to Microsoft by Google's Project Zero and indeed I found the original bug with its full description and its attached proof of concept in a zip file. However, Nightmare Eclipse stated that the flaw was still exploitable and it was unclear whether Microsoft fully patched the issue or whether the bug may have been reproduced or, I'm sorry, reintroduced. As I said, bugs sometimes come back may have been reintroduced at some point. In any event, it appears to have been fixed once again.
Steve Gibson [02:07:12]:
And this brings us to the fifth and final zero day remote code execution vulnerability. Just to be clear, this is one of the 55 remote code execution vulnerabilities that were fixed last Tuesday, though the majority while RCEs were not zero days. Remember, there were 55 of those unbelievably. But this one CVE 2026.428.97 was one of the zero days. This last one is a spoofing vulnerability that was present in Microsoft Exchange Server. It was being actively exploited in the wild to execute JavaScript in a targeted victim's browser. Microsoft explained, quote an attacker could exploit this issue by sending a specially crafted email to a user if the user opens the email in Outlook Web access and certain interaction conditions are met. Arbitrary JavaScript can be executed in the user's browser context.
Steve Gibson [02:08:25]:
So technically this last one was not part of the primary Patch Tuesday bundle. At the time, Microsoft explained that they were still working on its update and that they would be pushing it out through the Exchange Emergency Mitigation service, which should be enabled by default on certainly on Exchange Server and hopefully for users that are that might be affected by this we know nothing about two about who sorry disclosed this vulnerability nor how it was exploited, but it was a zero day scanning down the surprisingly lengthy list of critical so remember we had 55 critical remote code vulnerabilities. We find that one was present in Active Directory Domain Services and another in Microsoft Azure Kubernetes Service, Microsoft Office and the Remote Desktop client. Get this, each had seven remote critical remote code execution vulnerabilities, Remote Desktop and Microsoft Office each had seven. One was in Nuance Power Scribe three were found and removed from Windows Hyper V. Thank goodness because I'm about to start using it. There was one in Windows Development Services. Windows DHCP client had one and that's a scary place to have a a critical RCE since although it explains why it's critical since most Windows clients will be using DHCP so their client will be vulnerable remotely by default to any server that is able to supply DHCP information.
Steve Gibson [02:10:15]:
In addition to the Windows HTTP 2 bom which we talked about last week and previously this week which was that denial of service problem, the HTTP sys module also had a terrifying critical remote codecs and vulnerability fixed. I assume it was terrifying since it was in HTTP sys, that's the Windows web Server module and it was rated critical and it was a remote code execution and nothing is more exposed than a web server. Which is why the HTTP 2 Bob vulnerability was such a problem. Windows Kerberos also had a critical rce not to be left out, Windows kernel did too. And finally two RCEs were found and fixed in the windows win32k graphic grfx module. So yeah, I named today's podcast Patch Tuesday a la AI because this is what the next several months or so are probably going to look like. It's going to be very interesting to see the shape of the vulnerability discovery and remediation curve. As we know, the pre previous months meaning May patch Tuesday tied for the most ever patches in any month and that was like 125 or something.
Steve Gibson [02:11:49]:
As we know this month's handily this month's patch number count fixes far exceeded that one. So are we seeing an acceleration? I mean we are in in the last couple months certainly. What a month. What will next months look like? No idea, but it's going to be really interesting to see. And finally lastly over on the Microsoft Edge Chromium update side I will quote from bleeping computers reporting about that just one line which wrote quote There were also a massive their word there were also a massive 360 Microsoft Edge slash Chromium flaws that were fixed by Google this month. Okay. 360. And these were found in the Chromium browser, which was already the recipient of an incredible expenditure of past manpower.
Steve Gibson [02:12:57]:
But now our entire software industry is replacing manpower with AI power as rapidly as it can. And it's quickly becoming clear that at least in the field of software, there's really no comparison. Man versus machine, since the results are pretty much speaking for themselves. Machine wins.
Leo Laporte [02:13:19]:
Yeah.
Steve Gibson [02:13:20]:
And I for not, I for one, Leo, cannot wait to see what happens next. This is a real ride lately.
Leo Laporte [02:13:27]:
It's crazy. Yeah. That there are that many flaws is in Chrome and Windows is huge. I understand. But Chrome. Yeah.
Steve Gibson [02:13:39]:
And it does say that Google is busy running AI over Chrome. Yeah, I know, but I, I'm with you. I am stunned because, I mean, it was believed to be super secure.
Leo Laporte [02:13:51]:
Yeah.
Steve Gibson [02:13:51]:
And they said, whoops.
Leo Laporte [02:13:54]:
So in some ways this, I mean, if you could find the flaws, if you're a bad guy, you could also exploit the flaws. Right. I mean, that's why people are worried about Fable. And, and Mythos is finding them and fixing them is. Is tantamount to finding them and exploiting them. It's the same.
Steve Gibson [02:14:11]:
And Mythos, Mythos, we know, produces proofs of concept, so it designs the exploit that is an exploit is a proof of concept. Right.
Leo Laporte [02:14:25]:
Okay. I don't know where this is all headed. I have no idea. I know we're going to talk more about it tomorrow. I'm trying to get Katie Mazuris on as well because she's the only one who's seen this. Check the code, fix the code. Quote, Jailbreak. And Alex Stamos will also be joining us.
Leo Laporte [02:14:39]:
He has created the campaign to free Fable. We will be talking about this tomorrow on Intelligent Machines. Big time. Big time. And I'm glad, I was really glad you've been talking about it as well, because it's just, it is, it's a, it's an interesting time for security, for
Steve Gibson [02:14:54]:
cybersecurity, you know, revolutionizing cybersecurity. Utterly.
Leo Laporte [02:15:00]:
And of course, the other thing that the Fable classifier was blocking besides CyberSecurity and an AI development because they don't want somebody else to develop another AI with that power. Is. Yeah. Bio stuff. And that means bio biological warfare. And it's one thing to say, well, there's 360 bugs in Chrome, but if you could design a lethal pathogen that was highly contagious, that would be devastating. We would just. I mean, look what happened with COVID and that wasn't even designed.
Leo Laporte [02:15:35]:
I mean, that would be devastating. We could. So I understand there's a legitimate concern about this. And you know, I think we're going to be facing this one way or the other, whatever the government does in the next few years. Right? You can't keep a lid on this forever. Everybody's working to make these AGIs. Maybe, maybe anthropic was right. We should probably stop you first.
Leo Laporte [02:16:04]:
That's what they said. We'll stop when they stop. Steve Gibson's@grc.com that's where you can find Spinrite, the world's best mass storage maintenance, recovery and performance enhancing utility. Version 6.1 is the most recent and it is fairly recent and it is available. And if you have mass storage, you really should have it. Go to GRC.com and get it. There are other things there. There's his spin.
Leo Laporte [02:16:28]:
Rice is bread and butter. But he also has a lovely little $10 program, okay, 9.99, called the DNS Benchmark Pro that makes sure that your DNS is fast. You know, a lot of people think the web is slow, and then they realize it's not the web, it's the DNS server they're using is slow to catch, to find the, you know, the IP address. Speeding up your DNS server speeds everything up. And DNS Benchmark Pro can help you do that. You'll find both of those@grc.com if you want to send Steve mail or picture of the week, send it to GRC.com no, don't send it to anywhere. Go to GRC.com mail and enter your email address. Because he has to whitelist you before you send it, but he has a magic tool to do that.
Leo Laporte [02:17:10]:
Right below it you'll see two checkboxes for two different newsletters. One is of course, the weekly Security now show notes. Really nice to get that a couple of days ahead of time. The other rarely used Announcement of new products. If there is a new product, Steve will announce it through that one. Sign up for more both. But as you would expect with Steve, neither are checked by default, so you'll have to manually do that. Steve also has copies of the show.
Leo Laporte [02:17:35]:
He has unique copies, 16 kilobit for the bandwidth impaired, 64 kilobit sounds great, but it is smaller than the version we have. He also has those show notes. You can download those there. And a couple of days after the show, he'll have a transcript created by a human being. Elaine Ferris hi Elaine who does a great job with those. Those are all@grc.com along with a lot of wonderful free stuff, including shields up, which really will help you check your router before you go online. We have on our website 128kilobit audio. Long story, that's what we got.
Leo Laporte [02:18:10]:
We also have video. Long story, that's what we got. You can find both of Those@Twitt TV SN. There is a YouTube channel dedicated to Steve's show, YouTube.com SecurityNow a great way to share clips which you may want to do on any of these to, you know, let people know what you've just learned. Great way to spread the word about the show. And of course you can subscribe because it's a podcast in your favorite podcast client. We do the show right after Mac Break weekly. 1:30 Pacific, 4:30 Eastern, 20:30 UTC every Tuesday.
Leo Laporte [02:18:40]:
You can watch us do it live. If you're a club member, and I hope you are, please, if you're not, join the club. 10 bucks a month for ad, free versions of the show. Lots more. The club you can watch in the club, Twit, Discord, but everybody's invited to watch on YouTube, Twitch, X.com, facebook, LinkedIn or Kik. We stream on all those platforms so you can watch us live if you want. And we would love every Tuesday. We'll be back here next Tuesday at 1:30pm Pacific for another gripping, thrilling edition of Securing Now.
Leo Laporte [02:19:11]:
See you then, Steve.
Steve Gibson [02:19:12]:
Bye, Leo. See you then.
Leo Laporte [02:19:16]:
Security now.
