| ||||||
Description: France's Vanity Fair faces a stiff fine over cookies. GrapheneOS pulls out of France over coercion worries. The EU adds to the pile-on over underage social media. India mandates the tracking of all smartphones. Apple says no. India abandons its smartphone tracking mandate. India requires all encrypted messaging to be SIM-tied. Scattered Lapsus$ Hunters becomes SLH. AI demand has driven RAM pricing sky high. GRC's DNS Benchmark is finished and available. Cisco may talk a good game, but they're still Cisco. Browsers to ask users for local network access permission. React: The worst remote code exploit in a LONG time.
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-1055.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson is here with lots of security news. Apple says no. India says yes. Scattered Lapsus$ has a new name. RAM price is going through the roof. And Steve's announcing a new product finally available for sale as of today. All of that and the worst code exploit in a long time, next on Security Now!.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 1055, recorded Tuesday, December 9th, 2025: React's Perfect 10. It's time for Security Now!, the show where we cover your security, your privacy, and all the exciting attacks that are happening on the Internet today with this guy right here. This here is Steve Gibson, my friends. Hello, Steve. |
| Steve Gibson: A comprehensive overview of bad news. |
| Leo: Well, there's one this week. Holy cow. |
| Steve: Yeah. |
| Leo: What's coming up? |
| Steve: There is some good news, though. |
| Leo: Oh, good. |
| Steve: The Benchmark is done. And it's on sale. So we'll be able to talk about that. So for Episode 1055 for this we're cruising through December episode, which is titled "React's Perfect 10" because, oh, yeah. |
| Leo: That bad. Wow. |
| Steve: We'll get into what React is. And "Perfect 10" was actually a quote from one of the security people who said, oh, this is really - the bad guys are going to be feeding off this one for quite a while. But we're going to talk about of course a bunch of other stuff first. France's Vanity Fair facing a stiff fine over what they did with cookies. And they didn't eat them. GrapheneOS, speaking of France, is pulling out of France over, like, bad behavior of French authorities thinking that they can I guess, bully these guys because they're not Apple, or they're not Google. So let's get, you know, let's pound on the small open source guys. So they're saying, no, thanks, we're leaving. The EU is adding to the pileup over underage social media. And I thought you guys over on MacBreak had a great conversation about all this, Leo. |
| Leo: Oh, yeah. Oh, yeah. |
| Steve: That was, you know, I mean, we're all pretty much on the same page with all of this; right? I mean, why wouldn't we be? Because it's kind of - there is a right answer. Also, boy, India was busy. And I think you guys talked about that a little bit, too. I don't know what has happened in India. But they mandated the tracking of all smartphones. I heard you guys talking about GPS, which I didn't pick up on. Then Apple said no. Then India changed their mind. It's just, what? What? What's the rule today over there? But apparently, and they haven't backed down, they're also going to require all encrypted messaging to be SIM-tied. So there's another thing. We'll talk about that. Scattered Lapsus$ Hunters, the infamous and unfortunately quite well-known and quite successful bad guy group, they've got an initial now, instead of having to say Scattered Lapsus$ Hunters and not remembering who they are. Also non-security-related topic, AI demand driving RAM pricing through the roof. |
| Leo: Mm-hmm. Oh, yeah. |
| Steve: To the point where there's no fixed pricing. You've got to - it's like, well, what does the lobster cost today? So, okay. I'm going to talk a little bit about the DNS Benchmark, which went on sale on Friday after it was, like, done. And I'm so proud of it ended up being. Also we've got a couple pieces of feedback, one about Cisco talking a good game, but they're still Cisco. Also browsers - this is from Chrome - going to be asking users for access to their local networks. |
| Leo: I've seen this. |
| Steve: And why that's just not going to be, I mean, it's better than nothing, which is what we've had so far, but oh, boy. And then finally we're going to do a deep dig into what is with React, and what happened, and what does this mean. So I think maybe, you know, it's going to be okay [crosstalk] podcast, yeah. |
| Leo: We're working on it. We're getting better with age. Twenty years we've been doing this show. |
| Steve: Getting the hang of it. |
| Leo: All right. We will get to - you forgot the Picture of the Week coming up. |
| Steve: Oh, no. |
| Leo: I haven't seen it. |
| Steve: This one had an unfortunate caption. This one, I struggled for the caption on this one. I had to show it because it's such a fantastic picture. But I thought, how can I, like, give it some context? I tried. |
| Leo: All right. |
| Steve: We'll let our listeners judge how I did. |
| Leo: And maybe they'll come up with something. You never know. |
| Steve: Oh, maybe? Of course we've got... |
| Leo: Of course they will. |
| Steve: You betcha. |
| Leo: Picture of the Week time, Steve. |
| Steve: Okay. So I gave this pair of pictures the caption "Each year we jump through more hoops to increase our security. It's become a lot. How much does all that really help?" |
| Leo: Okay. |
| Steve: So that's the caption for two frames. The frame on the left shows an opening with a red rope line rope and the caption "Google when hackers try to hack my account." In other words, eh. |
| Leo: Okay. |
| Steve: Not that difficult. |
| Leo: Right. |
| Steve: And then the right one is titled "Google when I log into a new device." And this one, I didn't see the guard dog with its teeth out down in the lower right initially. |
| Leo: Oh, yeah [growling]. |
| Steve: So this one looks like something that Maxwell Smart would have confronted back in the day. It's got chains and locks and slide bars and triple hinges and a keypad and... |
| Leo: A thumbprint reader on there. That's hysterical. |
| Steve: Meaning god help you if you have to get through this door. It's going to take you an hour to unlock and deal with everything. And of course the gist of this is something that we do feel, which is accounts are still being hacked. Passwords are being obtained. People are still getting hacked. Yet we're doing all this more stuff. I mean, I have to say, Leo, I love the one-time password idea. But it gets a little tiresome after it's like, okay, you know. |
| Leo: Yeah. Again? Again? |
| Steve: Yeah, fine, 326294. It's like, okay. You know? And then, again, so it's like - so I look for those checkmarks, yes, I trust this device. Leave me logged in, please. |
| Leo: Right. Please. |
| Steve: Remember that I've been here so that you'll believe me next time with less rigmarole. Which is not to say, believe me, I like one-time passwords. All of this is good. One of the strongest measures of - one of the strongest improvements is the should you be remembered at this browser because no bad guy can be remembered as you if they've never logged in as you before from, you know, some foreign country. So it's really good protection. But yes, it is annoying. Google, when I log into a new device. Google's doing the right thing. You know, we've never seen you logging in through this device before, so we need a blood sample. That's going to be good. But, you know, you're going to end up being drained if you do it too often. So. Okay. We've noted before that regulations that are not enforced will often simply be ignored. In fact, I could probably more strongly say will be ignored until they're enforced because it's like, yeah, you know, it's the equivalent of that annoying high school tough guy whose favorite retort was, "Oh, yeah? Make me." It's like, yeah, fine. And in the news is that the French edition of the Vanity Fair website at VanityFair.fr, had their bluff called, to the tune - and it's an expensive call for a cookie - 750,000 euros. So that'll get your attention. And you think, wow, isn't that a pretty stiff penalty for just, like, some problem with cookies? The company, Les Publications Conde Nast, publishes printed and online magazines including the Vanity Fair magazine. Six years ago, okay, six years ago, way back in December of 2019, the CNIL, which is the abbreviation for - you know, it's in French - for France's data protection agency, received a public complaint. So the agency received a complaint from the association NOYB, which is Europe's Centre for Digital Rights. And it doesn't actually stand for "None Of Your Business," but it's a great abbreviation, NOYB. So NOYB, which does not stand for None of Your Business, but it's too bad it doesn't, complained to CNIL, France's data protection agency, about the cookies being placed on the devices of users visiting VanityFair.fr. This was happening without any user notification or permission. After several investigations and discussions with CNIL, Conde Nast, the parent, received an order to comply in September 2021. So first of all, almost two years, right, December 2019 this began. September 21, nearly two years later, finally find you've got to remove your cookies, fix your cookies because your cookies are not working right. And then the proceedings were closed in July of 2022. Now, it's not clear whether the proceedings were closed the next summer after verification that Conde Nast and their VanityFair.fr site was doing the right thing or not, but it was closed. A year later, in July and also in November of 2023, then again in February of '25, the CNIL carried out further online investigations. So it sounds like they just assumed Conde Nast would take care of this, get it done, following the order, after two years of negotiations. I don't know what you have to negotiate over a cookie, but okay. So CNIL went back and looked. And what do you think they found? Based on their findings, the Restricted Committee, as it's known, which is the CNIL body responsible for issuing sanctions, considered that the company Les Publications Conde Nast had failed to comply with the obligations of Article 82 of the French Data Protection Act, and imposed that fine of, I mean, 750,000 euros. The amount of the fine is intended to take into account the fact that the company had already been issued with an order to comply. It couldn't have come as a surprise after nearly two years of discussion about whether we're going to receive an order or not, after which they did. But apparently they just blew it off. As well as the other thing factored into this 750,000 fine is the number of people likely to have been affected by this misbehavior of their cookie policy, and the various breaches of the rules protecting users with regard to said cookies. So no one's going to shed a tear here except some accountant at Vanity Fair. Again, it wasn't as if the fine could have shocked anybody. They were very clearly told what they needed to do, and they apparently just blew off CNIL, saying, eh, you know, everybody else does it. So, you know, I would imagine that someone is going to lose their job, or maybe a team, whoever is in charge of cookies over at VanityFair.fr, three quarters of a million euros which could have been easily prevented. I mean, what everybody else does is bring up a little cookie banner and say, hey, we want to store some stuff on your computer. Just tell us it's okay. Click here. But apparently either they didn't do that, or they did, and they didn't honor it. Who knows? Anyway, I hope everybody else sees this, that when CNIL says you're in breach of our regulations - now, of course this is against the backdrop of this whole wacky model of cookie management getting ready to change because the GDPR is being updated. And so we have California now and the EU both saying browsers need to accept a setting from their users, transmit that setting to everywhere they go, and everywhere they go needs to honor what the user has said they want. But, you know, that was 10 years ago, right, that all that came into place. And so it's going to take a while for all this to catch up and change. Meanwhile, the very nice Android alternative, and I think you were just talking about it last week or the week before, Leo, GrapheneOS, which is an Android-compatible, API-compatible, or, yeah, right, Android alternative, API-compatible, they recently posted on 'X' that they're leaving France due to a new French law that would mandate breaking their encryption. Obviously, no. So they posted: "We no longer have any active servers in France and are continuing the process of leaving OVH." OVH is a French cloud hosting company which they've been using. They said: "France is no longer a safe country for open source privacy projects. They expect backdoors in encryption and for devices, too. Secure devices and services are not going to be allowed in France. We don't feel safe using OVH for even a static website with servers in Canada and the U.S. via their Canada/U.S. subsidiaries. "We were likely going to release experimental Pixel 10 support very soon, but that's getting disrupted." So that'll be delayed, they're saying. "The attacks on our team with ongoing libel and harassment" - and they're talking from the French authorities, from French law enforcement they're being harassed - "have escalated, raids on our chat rooms have escalated, and more. It's rough right now, and support is appreciated." So it appears that GrapheneOS believes that they may have already been compromised because they also posted: "We'll be rotating our TLS keys and Let's Encrypt account keys pinned via accounturi. DNSSEC keys may also be rotated. Our backups are encrypted and can remain on OVH for now." So that, you know, the reason you rotate keys is you worry that they could have been compromised, that your keys could be in somebody else's hands, meaning that TLS and your Let's Encrypt domains and your DNSSEC security, you know, is not as sure as you'd like it to be. So they're going to change all their keys after completely excommunicating themselves from any dependence on France-based servers. Now, in the thread that followed, which was a much more lengthy posting on 'X,' which I won't bother everybody with, where they go into all the details of what's going on and the way they're going to be moving, someone named Lars posted: "I'm lead developer for a hosting company in Denmark. We do not have any backdoors or political influence in our company, and will never have. We host everything, and we do not ask questions as long it's not illegal content. For normal FOSS projects we definitely do not ask questions." Which, and this was posted, you know, offering the option of some assistance, or an alternative, to the GrapheneOS guys in the reply thread to their posting. Whereupon the GrapheneOS guy said: "We appreciate it, but unfortunately we'll likely have issues in Denmark, too, due to their push to outlaw encryption without backdoors. We'll hopefully still be able to operate in the EU in general, but we want to avoid Chat Control-supporting countries due to this experience. GrapheneOS is not based in the U.S. and is a non-profit open source project. We're leaving France because we don't trust that French law enforcement won't coerce OVH to do something after a judge signs off based on falsehoods. We've been subject to attacks by law enforcement on GrapheneOS, including many false claims and also direct threats." Geez. So reading between the lines, it sounds as though authorities with French law enforcement have demanded that GrapheneOS unlock some suspected criminals' handsets, and Graphene has tried to explain that they do not have that capability. They wrote: "It's not possible for GrapheneOS to produce an update for French law enforcement to bypass brute force protection since it's implemented via the Secure Element." So, you know, again, that sounds like French law enforcement is saying you need to help us brute-force open these locked smartphones that are running your OS. Graphene said: "The Secure Element also only accepts correctly signed firmware with a greater version AFTER the owner user unlocks successfully." So someone may have been suggesting a downgrade attack where you deliberately load older GrapheneOS software onto the device in order to bypass some of the later protections, and they're saying, sorry, that's been accounted for in the design of this. Can't do it. They wrote: "We would have no legal obligation to do it even if we could, but it's not even possible. We have a list of our official hardware requirements including secure element throttling for disk encryption key derivation" - okay, meaning that the secure element throttles brute-force attacks, making them impractical, and that's in the hardware, and there's nothing they can do to get around it - "secure element throttling for disk encryption key derivation combined with insider attack resistance." And they wrote: "And they aren't blaming Google for this design." Meaning they're saying that GrapheneOS is at fault for making it brute-force impossible, but it's actually Google whose engineering did this properly because users don't want their smartphones to be hacked. And they finish, saying: "In Canada and the U.S., refusing to provide a PIN and password is protected as part of the right to avoiding incriminating yourself. In France, they've criminalized this part of the right to remain silent. Since France has criminalized the refusal to provide a PIN, why do they need anything from us?" Which that's some good logic. And of course we don't know anything about what the French authorities believe might be on a criminal's confiscated GrapheneOS-based smartphone. But we certainly know why a suspect might choose not to share their password with the authorities; right? We talked about that tradeoff ages ago back in the context of TrueCrypt's early whole disk encryption, which was designed by cryptographers who knew how to completely and correctly protect a hard drive's data. It was effectively and practically not brute-force crackable because it was done right. The bad guys might very well have horribly incriminating material stored on a TrueCrypted drive. So they would much rather face some charges, whatever they may be, for not providing their password, than provide the password and have authorities learn firsthand just how criminal they were. So I doubt that law enforcement authorities will ever accept, you know, ever in the future of humanity except the truth of being unable to unlock an encrypted device, or spy on encrypted communications. They just, you know, they know the data is there. They want it. So I'm sure they believe that they should have the right to see inside anything they choose under the logic of, after all, they're the good guys; right? And of course we know that the EFF would beg to differ. So there's that. But it's also happening in the EU. And Leo, I know you talked about this over on MacBreak. Here we are. It is December 9th. We are on the literal eve of the Australian law to ban the use of social media, all social media, by anyone younger than 16. As we know, this effectively requires anyone who does wish to continue using any social media to arrange to prove that they are at least 16 years old. If that wasn't the requirement, then somebody who was 14 could say "I'm a adult." Okay. So, you know, the onus has been placed, unfortunately, on the social media providers to prevent the use of their systems by anyone younger than 16. So we're recording this on December 9th. And tomorrow... |
| Leo: Of course it's already December 10th in Australia. |
| Steve: Right. |
| Leo: So it's going on now, I guess. |
| Steve: Right. Which is always weird. Why does it turn next year in New York, before it turns - I don't get that, Leo. |
| Leo: Never understand it, no. |
| Steve: But, you know, we're not a flat earth. We are a spinning globe. And, you know, it would be weird if it was midnight in the middle of the day, yeah. |
| Leo: Yeah. |
| Steve: So that wouldn't work, either. So what's different here, what's happening now in Australia, is countrywide. And that's the difference. And actually, saying that the whole world is watching is not an exaggeration. On Sunday - today's Tuesday, so two days ago on Sunday, The New York Times piece was titled "A Grand Social Media Experiment Begins in Australia," with the tag "The country is trying to wean children under 16 off the likes of TikTok, Snapchat, YouTube, and Instagram with a new law. The teenagers are skeptical," The New York Times said. Saturday, the BBC's headline was "Can you ban kids from social media? Australia is about to, but some teens are a step ahead." I read the BBC piece. Kids are using still photos of their parents. Or VPNs. Surprise. UNICEF in Australia just has a piece titled "Social media ban," was their title, and they summarized their position by writing - and this is UNICEF - writing: "From 10 December 2025, anyone under 16 in Australia won't be able to keep or make accounts on social media apps like TikTok, Instagram, YouTube, Snapchat, X, Facebook, and more." There's 10 total. "The rule doesn't punish young people or their families; instead, social media companies have to stop under-16s from having accounts or risk serious fines. And the fines are up to $50 million Australian, about $35 million U.S." They said: "The new law is meant to make things safer online, but UNICEF Australia believes the real fix should be improving social media safety, not just delaying access." And for their part the Guardian headlined their piece: "Everyone will miss the socializing, but it's also a relief." They said: "Five young teens on Australia's social media ban." And it was an interesting article. They said: "Australia's world-first social media ban for under-16s will begin in just a few days." This was written on the weekend. "Malaysia, Denmark, and Norway are to follow suit, and the European Union last week passed a resolution to adopt similar restrictions. As the world watches on, millions of Australian adolescents and their parents are wondering just what will actually change come 10 December." And NPR had a piece, as well. As I said, everybody's like, okay, these guys are going first. What's going to happen? So it's going to be interesting to see, right, how all this pans out. As I said, the economic fine for repeated failure to enforce is $50 million Australian, $35 million U.S. So that's not nothing. But there's also, of course, reputational damage. Anybody who screws this up is going to be in the news because everybody's watching. So it's clear that the 10 affected social media platforms can't ignore this and do nothing. And we know that the claim of being old enough, that no longer washes. We were all happily using that for the last 20 years, but no more. So they're going to need to adopt, what, some lame measure that allows them to avoid penalties while kids gleefully work around and, you know, spoof the proof of age. Which is what's going to be happening a lot. I mean, classrooms will be buzzing. Everyone will be talking about how they did it. There was, in the BBC piece that interviewed five teens, one 13 year old said she just took a picture of her mom and showed it that. And it said, okay, go ahead. So, you know, my feeling is that there was probably no way to avoid the present mess that the world is about to endure. And a mess it's going to be. As we know, change is difficult, even when everyone is pulling in the same direction and wants it. But change, when the platforms and their users all want to leave things the way they are, and only some unseen government legislators and their regulators want to force change, it's just bound to be a mess. I, of course, hope that some good technology will eventually step into the gap to provide privacy-respecting age verification, but we don't have that yet; and we don't even appear to be close since the handset makers are very much strongly in the "We don't want this to be our problem" camp, although I think that's exactly wrong. I think, you know, that's the point of contact between the user and the technology is the handset. And I get it that Apple doesn't want to do this. But they're inching towards it. You know, we've covered various of those measures. As is Google. So I think they probably know that ultimately they're going to need to be the place where this decision gets made. It is the right place. It's the logical place for it to be. And on the eve of this first country-wide event, I wanted to also note that the EU is now making much the same noise, which one of those articles talked about. And also, whereas Australia's human, which is to say non-kangaroo, population is about 27.5 million, the total population of the EU's current 27 member states is around 450.5 million. So a huge population. The European Parliament News recently posted a piece with the headline "Children should be at least 16 to access social media, say Members of the European Parliament." Those are Members of the European Parliament. MEP is an acronym, MEPs. However, things may be better in the EU from a privacy and accuracy standpoint. At least we can hope. A vote was held two weeks ago Wednesday, where the Members of the European Parliament, these MEPs, voted to adopt a non-legislative report by 483 votes in favor, 92 against, and 86 abstentions. The report and their votes expressed deep concern over the physical and mental health risks minors face online and called for stronger protection against the manipulative strategies that can increase addiction and that are detrimental to children's ability to concentrate and engage healthily with online content. So here's the part that caught my eye in that EU's adopted reporting. They wrote, just it's a short paragraph: "Expressing support for the Commission's work to develop an EU age verification app and the European digital wallet, the eID wallet, MEPs insist that age assurance systems must be accurate and preserve minors' privacy." Which is to say everyone's privacy; right? Because, again, you need to assert that you're not a minor, and you'd like your privacy protected. It's funny how no one really latches onto that in any of this reporting. "Such systems do not relieve platforms of their responsibility to ensure their products are safe and age-appropriate by design," they add. But, you know, so these guys may be moving forward in the right way. And with 450 million users, and Stina over there in the EU, it's just not being a hard problem to solve if you want to solve it. I'm hopeful. So the idea that that Commission would be pressing for an EU age verification app, that's really good news. Given some means for establishing an individual's date of birth - which we know that may be the European digital identity - that date can easily be protected inside the device while simple assertions of "older than x" are then trivial to generate with total security and anonymity. As I said, crypto can do this without breaking a sweat. So my takeaway here is that, yes, we're about to descend into some extremely messy, chaotic times. But given the kicking and screaming by the platforms and their users, this was inevitable, given that the legislations and the legislators are just barreling ahead without any solution to the, well, we'll let other people solve the problem approach. So the right people understand the concepts of accurate privacy-preserving solutions, and they know this is possible. So I doubt that the world's going to have to wait that long, and that we're eventually going to finally obtain a good solution. And I know, Leo, you guys were talking about it over on MacBreak Weekly. The loss of absolute unaccountability is going to be mourned by some, but Jason was talking about the loss of privacy. That's just interim. We can do this without any loss of privacy. Yes, you will have to identify yourself in order to securely embed your date of birth in the device. But once that's done, all the people using it, that's the real difference here, we do not want to have to be showing a driver's license individually to every website we visit. You're going to have to show it once to your device, and then be biometrically locked to that so that it knows that you didn't use your license for a friend's phone in some fashion. So, you know, it needs to be done right, but it can be. And once that's done, then that strongly constrains any further dissemination of privacy loss. That's where we're going to end up being. So it'll be fun to watch it here on this podcast as it happens. And it'll be fun for me to take a sip of coffee, Leo. |
| Leo: Well, that we can arrange. I don't know if we can help with the other one, but I think we can arrange... |
| Steve: We can at least be here cheering. |
| Leo: Yes. All right. Back to Steve. |
| Steve: So this is such a weird path. Staying with the topic of government legislators seemingly losing their multidecade, simultaneously all losing their multidecade shyness toward legislating our use of personal technology, which sort of seems to have happened globally all at once, we have the news that the government of India intends to verify and record every smartphone in use by their citizens. That was essentially TechCrunch's headline last week, under which they wrote: "The Indian government is widening the scope of its anti-theft and cybersecurity initiative to cover both new and used smartphones, an effort aimed at curbing device theft and online fraud, but a move that's also raising fresh privacy concerns." Yeah, no kidding. They wrote: "As part of the expansion, the Indian telecom ministry is requiring companies that buy or trade used phones to verify every device through a central database of IMEI numbers. This comes in addition to a recent directive ordering - get this - ordering smartphone manufacturers to preinstall the government's Sanchar Saathi app on all new handsets and push it onto existing devices through a software update." Ordering smartphone manufacturers to do that. Uh-huh. Good luck with that. In other words, India is now requiring all handset makers both to pre-install a state-mandated app and also to retro-install the app into all existing devices. TechCrunch continues, writing: "Reuters first reported the news on Monday, which was later confirmed by the ministry in a public statement. So the ministry said, yup, that's right, got to do that. Launched in 2023, the Sanchar Saathi portal allows users to block or trace lost and stolen phones. The system has blocked" - I was a little surprised by these numbers, Leo. "The system has blocked more than 4.2 million devices and traced 2.6 million more devices, per government data." |
| Leo: India is a big country, and there's hundreds of millions of cell phones in use. |
| Steve: Yeah, yeah. "The system expanded earlier this year with the release of a dedicated Sanchar Saathi app in January, which the government says helped recover more than 700,000 phones, including 50,000 in October alone." Wow. So I guess they've got a smartphone theft and reuse problem, and they're taking steps. TechCrunch said: "The Sanchar Saathi app has since gained broad adoption. The app has been downloaded nearly 15 million times and saw more than 3 million monthly active users in November up more than 600% from its launch month [which would have been 2023], according to marketing intelligence firm Sensor Tower. Web traffic to Sanchar Saathi has also surged, with monthly unique visitors rising more than 49% year-over-year, per Sensor Tower data shared with TechCrunch." So, okay. Up to this point it appears that the choice to have one's smartphone protected with this tracing and recovery app has been the user's. But TechCrunch explains what's changed. They wrote: "The government's order to preinstall Sanchar Saathi has already drawn significant backlash from privacy advocates, civil society groups, and opposition parties. Critics argue the move expands state visibility into personal devices without adequate safeguards. The Indian government, however, says the mandate is intended to address rising cases of cybercrime, such as IMEI duplication, device cloning, fraud in the secondhand smartphone market, and identity theft scams. "Responding to the controversy, the Indian telecommunications minister said Tuesday that Sanchar Saathi is 'a completely voluntary and democratic system' - okay - and that users can delete the app if they do not wish to use it." Which, again, sort of flies in the face of the other things that were previously said. "The directive, reviewed by TechCrunch and circulating on social media on Monday, instructs manufacturers to ensure the preinstalled app is 'readily visible and accessible to end users at the time of first use or device setup' and that 'its functionalities are not disabled or restricted,' raising questions about whether the app is truly optional in practice. "India's deputy telecom minister said in media interviews that most major manufacturers were included in the government's working group on the initiative, though Apple did not participate. "Alongside pushing the Sanchar Saathi app, two people familiar with the matter told TechCrunch that the telecom ministry is piloting an additional program interface an API that would allow re-commerce and trade-in platforms to upload customer identities and device details directly to the government. The move would mark a significant step toward creating a nationwide record of smartphones in circulation. "India's used-smartphone segment is expanding rapidly as rising prices of new devices and longer replacement cycles push more customers toward cheaper alternatives. India became the world's third-largest market for secondhand smartphones last year in 2024. "But as much as 85% of the secondhand phone sector remains unorganized, meaning most transactions occur through informal channels and through brick-and-mortar stores." 85%. So only 15% are being formalized and tracked. "The government's move covers only formal re-commerce and trade-in platforms, leaving much of the broader used-device market outside the scope of the current measures." Well, unless manufacturers are going to be back-porting, you know, back-installing this thing in any software updates, which may still be happening on remarketed phones. Anyway, TechCrunch said: "While announcing the preinstallation of its app, the Indian government said the move would help enable 'easy reporting of suspected misuse of telecom resources.' Privacy advocates say that the growing data flows could give authorities unprecedented visibility into device ownership, raising concerns over how the information could be used or misused. "The head of programs and partnerships of the Toronto-based nonprofit policy lab Tech Global Institute told TechCrunch: 'It's a troubling move to begin with. You're essentially looking at the potential for every single device being databased in some form.' And then what uses their database can be put to at a later date, we don't know. "The Indian government has not yet detailed how the collected data will be stored, who will have access to it, or what safeguards will apply as the system expands. Digital rights groups say the sheer scale of India's smartphone base estimated [to your point, Leo] at some 700 million devices means even administrative changes can have outsized consequences, potentially setting precedents that other governments may study or replicate. "'While the intent behind a unified platform may be protection, mandating a single government-controlled application risks stifling innovation particularly from private players and startups who have historically driven secure, scalable digital solutions,' said the director of the New Delhi-based technology think tank Esya Centre. "If the government intends to build such systems, they must be backed by independent audits, strong data government safeguards, and transparent accountability measures. Otherwise, the model not only puts user privacy at stake, but also removes fair competition for the ecosystem to contribute and innovate." Right. If the government's already got that locked up, then third parties need not apply. How can they compete? "The Indian telecom ministry did not respond to TechCrunch's request for comment. "'While the Sanchar Saathi app is visible on a user's phone, the broader system it connects to operates largely out of sight. The permissions, its data flows, and back-end changes, including the planned API integration, may be buried in long terms-and-conditions documents that most people never read, or even see,' he said. 'As a result, users may have little practical understanding of what information is being collected, how it is shared, with whom it's shared, or the extent of the system's reach. "'You can't go about restricting cybercrimes and device thefts in such a disproportionate and heavy-handed way.'" Boy, is that a common theme. He said: "'The government is basically saying that, look, you need to put my app on every device that's sold, on every existing device you have to install it, and in anything that's being resold, as well.'" So, wow. We know... |
| Leo: I think they felt the pressure because this is a press release from the Department of Telecommunications in India. They gave up. |
| Steve: Yes. And in fact I've got that after I tell you what Apple said. |
| Leo: Yeah, Apple wasn't too happy about it, I know that. |
| Steve: So on a practical side, we know about the tyranny of the default; right? If the app is pre- and post-installed, a great many more people will end up using it. Way more than 50 million recent downloads. There's 700 million phones in circulation. Most people will not remove it. They'll just assume, oh, whatever that is, you know, it's good for me. And it's not completely clear whether removal will even be an option, since the Indian government's intention looks to be more aimed at assuring that all smartphones participate. And of course one wonders what Apple, right, would think about such a mandate. On the other hand, India is now producing Apple's smartphones, so who knows. Well, it turns out Apple does indeed say no. I dug around some more and discovered, to no one's surprise, Apple does not plan to abide by India's order. The India Times headline was "Apple to resist DOT order" - that's India's Department of Telecom - "to preload state-run Sanchar Saathi app as political outcry builds." And we get a little bit more interesting information about disabling or removing that makes somewhat more sense. The India Times wrote: "Apple does not plan to comply with a mandate to preload its smartphones with a state-owned cyber safety app and will convey its concerns to New Delhi, three sources familiar with the matter said, after the government's move sparked surveillance concerns. The Indian government has confidentially ordered" - although it didn't stay secret, of course, you can't, those sorts of things - "confidentially ordered companies including Apple, Samsung, and Xiaomi to preload their phones with an app called Sanchar Saathi" - or which in English is Communication Partner is what that means - "within 90 days. The app is intended to track stolen phones, block them, and prevent them from being misused." So that was news. Block them? So meaning that the government can prevent a phone from operating? I didn't pick up any of that in the previous reporting. So, you know, you would call that "a biggie." That suggests that this Communications Partner app would have the ability to shut down a phone. And if that's the case, it's no wonder that Apple is saying "no thanks." The reporting continues from India Times writing: "Reuters was the first to report on Monday that the government also wants manufacturers to ensure that the app is not disabled. Also, for any devices already in the supply chain, manufacturers should push the app to phones via software updates. "The telecom ministry confirmed the move later, describing it as a security measure to combat 'serious endangerment' of cyber security. But Minister Modi's political opponents and privacy advocates criticized the move, saying it is a way for the government to gain access to India's 730 million smartphones." So anyway, I'm going to skip the balance of this. Basically a bunch of opinions were polled by Reuters talking about it, you know, being more than a sledgehammer. It's more like a double-barreled shotgun. And someone saying that there's no way Apple would ever agree to do this. And in fact we know that that's the case. So following on the heels of that, as you said, Leo, India decided, okay, I guess that's not going to fly. They backpedaled on their requirement. Their official press release from the Ministry of Communications which you had on the screen, proclaims across its top: "Government removes mandatory pre-installation of the Sanchar Saathi App." So it turns out that the government changed its mind two days after the announcement following extensive public criticism of what everyone was concerned was veiled surveillance. And I decided to keep that original reporting in place for the podcast because it's still useful to understand what's in the air. And this is in the air. You know, India may not be done meddling its communications because the India Times also had a headline, "Why your WhatsApp Web may now log out every six hours." India's Department of Telecommunications said, or I'm sorry, the India Times is quoting them saying in their story: "Due to a new directive from the Department of Telecommunications, WhatsApp Web will automatically log out its users every six hours. Under the new rule, the Department of Telecommunications requires messaging apps, including WhatsApp, Telegram, and Signal, to implement 'SIM binding.' In other words, linking of the users of services to the SIM card used for registration via its IMSI identifier. If the original SIM is not present, access to these apps will be blocked 90 days from the directive's issuance." So there's a 90-day get-up-to-speed period from the publication of the directive. Within 90 days, this technology has to be in place for all text messaging apps. And, you know, whereupon I think, well, you know, good luck telling Signal's Meredith Whittaker that you're requiring Signal to bind to specific SIM cards. As we know, Signal has historically been bound to a user's phone, but there's no way that Signal would be modifying their app if it meant the slightest reduction in the privacy of their users. And if this move did not represent some enhanced form of government control, then why would India be mandating this change at all? Okay. But there's more. The India Times explains: "Under the same directive, web versions of these applications will log their users out periodically, no later than every six hours, and force a re-authentication via a QR code scan. A user logs into WhatsApp Web through a browser, by scanning the QR code through the phone application. According to the authorities, this is to curb cyber fraud by preventing misuse of apps without active SIMs, often by scammers operating from abroad. Platforms are required to comply within 90 days and submit reports within four months, potentially by around February of next year. The rules will apply to WhatsApp, Telegram, Signal, Snapchat, and other OTT (over the top) messaging platforms operating in India. "Users are likely to face workflow disruptions, especially multi-device professionals and travelers and small businesses that rely on shared devices. WhatsApp has 500 million Indian users, and a major chunk of its business users are also in the country." "One user wrote on X: 'Sim binding rule shall be a major disruption for professionals and businesses using web accounts of WhatsApp, et cetera. It won't eliminate the fraud completely, as Sim Cloning and Sim Spoofing will still work.' "While a section of the tech industry believes that the DoT might have breached its regulatory mandate, officials clarified that the directions issued to the apps are within the purview of telecom cyber security rules. An official told the India Times: 'It's only for the entities that use telecommunication identifiers like a mobile number for their services. If they don't want to do the SIM binding, they should not use the mobile number as an identifier.' "Industry representatives also questioned the effectiveness of SIM binding in curbing fraud originating outside India, noting that scam operators can still obtain Indian SIMs through mules or remote devices, while a significant volume of fraud originates within the country." So, you know, we really appear to be entering a period where government legislators are feeling increasingly empowered, Leo, to dictate the operation of the personal communications devices operating within their jurisdictions. And I've found no indication yet that India will be backing down from this latest, you know, SIM binding deal on messaging platform apps. |
| Leo: Yeah. |
| Steve: Wow. So what do you think that's about? I mean, that's just like tying, like... |
| Leo: I'm not sure, to be honest. |
| Steve: WhatsApp is based on your phone number; right? Because we have the story... |
| Leo: It doesn't have to be anymore. It used to be, but it no longer has to be. |
| Steve: Okay. Because we had that story that we talked about last week where there was no rate limiting on brute forcing WhatsApp Web to look up people's identities just by trying every possible phone number. |
| Leo: Right. Right. I guess you do have to submit a phone number. Your ID can just be, like my ID on WhatsApp is leolaporte.24. So that was a change that they implemented last couple of years, maybe in the last year. I guess that's why it's 24. |
| Steve: So you can look up by ID or by phone? |
| Leo: Yeah, yeah. |
| Steve: Okay. |
| Leo: But I don't know if you can look up by phone. That's an interesting question anymore. |
| Steve: And of course I get the idea was... |
| Leo: I think you need a phone number to register it. So, yeah, they have your data. That's right. |
| Steve: Yeah. And I guess the idea also was that WhatsApp could - you'd give it access to your contacts, and it would go through your contacts, take all the phone numbers out of your contacts, and then cross-reference that with WhatsApp users in order to populate your WhatsApp contacts. |
| Leo: Right. Oh, I was thinking of Signal. I'm not - you're right. WhatsApp I don't know. I don't use WhatsApp. I think it is tied to your phone number. You're right, yeah. And of course every Facebook app asks for access to your contacts, and I always say no. |
| Steve: Yeah. |
| Leo: Because I'm not going to... |
| Steve: What good could come of that? |
| Leo: I'm not giving out Steve Gibson's phone number and home address and email. What good could possibly come of that? If you want me to know you're on WhatsApp, you'll let me know on your own WhatsApp; right? |
| Steve: Yeah. |
| Leo: You know, you had a sentence in here that I think you could shorten, where you say that countries are increasingly feeling... |
| Steve: Ah. |
| Leo: "Legislators are feeling increasingly empowered to dictate the operation of the," et cetera. Just say "Legislators are feeling increasingly empowered," period. And I think that's really what's happening is that governments worldwide are becoming more and more authoritarian and more and more interested in enforcing their worldview on their constituents. And I don't think that's a good trend at all. |
| Steve: No. And unfortunately, the technology allows that; right? I mean... |
| Leo: Well, technology has stimulated it because they feel like they've lost control of us. |
| Steve: Right. But the technology also is a control mechanism. |
| Leo: Right, exactly. So they've discovered that, and they're trying to use it. And, yeah, I don't have high hopes for this. You know, I think what happens, you give people power, they want more power. |
| Steve: Yeah. |
| Leo: And you can do everything you can. John Adams said that. I was watching the great Ken Burns documentary on the Revolutionary War. And John Adams said, "You know, we can make a democracy, but I feel like people's greed for money and power is so great that it's unlikely we can sustain it." |
| Steve: Right. And Washington, you know, responds famously to that woman who asks after the signing of the Declaration of Independence, but what did you just... |
| Leo: Franklin [crosstalk] keep it. |
| Steve: Oh, Franklin. |
| Leo: Yeah, yeah. |
| Steve: Yes, a democracy, or no, a republic, if you can keep it. |
| Leo: If you can keep it, yeah. I think even in the beginning they knew that this was going to be difficult. |
| Steve: Well, and, you know, we all grew up, all of us are... |
| Leo: Of a certain age. |
| Steve: Yes, the pigmentation has left our hair. |
| Leo: Or our hair has left our head. |
| Steve: It's always been the way it is, and it's always going to be the way it is. And but that's not the history of democracies. |
| Leo: Right. |
| Steve: They have a period. |
| Leo: And if it's at all encouraging, we've been through bad times in the U.S. before. There have been many anti-democratic eras in the states. |
| Steve: Yes. |
| Leo: And we survived [crosstalk]. |
| Steve: Yes, and we have swung back. |
| Leo: Yeah. |
| Steve: Yeah. |
| Leo: So let's hope. |
| Steve: Let's take a break. We're at an hour in. We're going to talk about the abbreviation of Scattered Lapsus$ Hunters. It's not an inspired abbreviation, but it helps. And then a bit about RAM pricing. It's gone nuts. |
| Leo: Unbelievable it's gone up, RAM pricing. You know, I'm glad I'm well equipped with computers, but I'm worried about the future. I don't know. |
| Steve: In fact, that thing I had to sign for, I just purchased a machine, probably my final computer, for my new office that I'll be setting up in a month or two. |
| Leo: Ah, nice. |
| Steve: And I did it. |
| Leo: Desktop or laptop? |
| Steve: It's a small, what do they call it, small form factor. |
| Leo: Oh, like a NUC. |
| Steve: Yeah, that kind of thing. |
| Leo: Yeah. Yeah, I think, I'm thinking maybe, I was going to wait until next year, Apple has OLED screens coming, and I really love OLED screens. But I just got a PC instead. They have plenty of OLED PCs. And just put Linux on it. |
| Steve: Well, and of course I will do - what this thing has is three display ports on the back. |
| Leo: Nice. |
| Steve: Because I am a three-screen person. That works for me. And I made the mistake on the system I have in my place with Lorrie of having that curved high-resolution screen. |
| Leo: No. |
| Steve: Uh, no. |
| Leo: No I don't like the curve. |
| Steve: Because I have lower resolution on the sides. And when you drag something across the boundary, it gets - it's all screwed up. |
| Leo: It's like your peripheral vision on the screen. That's not... |
| Steve: Not good. |
| Leo: Yeah. |
| Steve: So I'm going to go three flat screens, all the same resolution. |
| Leo: Do you organize it - I'm sorry. Parenthetically. We'll get back to the show in a moment, folks. |
| Steve: Yes. I have... |
| Leo: Do you organize, like do you have code in one window? |
| Steve: Yes. Yes. I generally have static things in different locations. So like I always have Windows Explorer open on the right half of the right side. And that's just where it lives. |
| Leo: It's always there. |
| Steve: Yes, it's always there. |
| Leo: That's smart, yeah, because you always know to go there. |
| Steve: And it's interesting because Lorrie and I have very different organizational approaches. And she wants, like, she's an organizer, but she likes to put things in bins. And I'm a position-based organizer. I know where something is like in location. And so I go right to it. But if she organized it, it's gone. So it's like, "Honey, what happened to the...?" She says, "Oh, I organized that." Oh. |
| Leo: No. |
| Steve: Where is it now? |
| Leo: We have that problem in the kitchen. I now know where everything is in the kitchen. But if we reorganize, I'm in deep trouble. Deep trouble. |
| Steve: So a random observation that I'm beginning to see, the infamous Scattered Lapsus$ Hunters being referred to by the abbreviation "SLH." I said no biggie, but SLH, I don't know if it'll catch on, but they have been so much in the news that the security industry appears to feel that they've become "abbreviation worthy." So the news blurb that caught my eye referred to SLH. It was a note saying that the security firm believed that they have seen SLH's focus shifting from Salesforce over to Zendesk. So SLH appear to be enamored of the SaaS model, the Software-as-a-Service exploitation, like, of customers of that. There was at this point a lack of razor-sharp attribution for some of the very recent Zendesk-related attacks, but there have been some, and the suspicion it is SLH. So we now have SLH as an abbreviation for Scattered Lapsus$ Hunters. Not quite as fun as Scattered Lapsus$ Hunters, but what the hell. And just completely off topic, I suppose we should have seen this coming. This next bit of news is not security related, but it's tangentially AI related. And I thought that our computer-centric listeners would find it interesting. The short blurb that first caught my attention, and I'd seen something about it pass by, but I hadn't paused, was: "Micron exits consumer RAM market." And the little blurb said: "American hardware vendor Micron will leave the consumer RAM market and discontinue its Crucial brand." And of course Crucial has been a well-known consumer RAM memory brand for years. They wrote: "The move comes as the AI boom has led to an explosion in prices in RAM and SSDs as AI companies build data-guzzling data centers and have swallowed almost the entire market output for the next few years." So, okay. You know, I guess we should have seen this coming. That led me to look for some additional detail which I thought that our listeners would appreciate. I found a nice piece over on The Verge, whose headline was "RAM prices are so out of control that stores are selling it like lobster." They wrote: "Michael Crider's headline at PCWorld today perfectly captures how ridiculous the PC memory shortage has become. Stores like the San Francisco Bay Area's Central Computers are beginning to sell RAM at market prices, like you'd pay for the catch-of-the-day at a seafood restaurant. A message posted in the store's display case reads: 'Costs are fluctuating daily as manufacturers and distributors adjust to limited supply and high demand. Because of this, we cannot display fixed prices at this time.' Micro Center is apparently doing the same: 'Due to market volatility, we ask that you please see a Sales Associate for pricing.'" They wrote: "It's hard to overstate just how quickly the RAM crunch is changing the affordability of computers and it might soon impact other realms as well, as everything from game consoles to smartphones require RAM to function. Three months ago yesterday," the author said, "I bought 32GB of memory for my gaming PC, and the price of that exact kit has more than tripled since then." Three months ago. He says: "It now costs $300 more, now $440 versus $130, in case you're curious," he said, "for 32GB." He said: "A more common version of the same kit went from $105 to $400. Some prices have doubled since October, and while you can still find some 32GB kits for as low as $230, a 64GB DDR5 kit can easily run you $700, $800, even $900. Some high-profile product launches might be impacted by the price of memory. Valve pointed to the RAM crunch as one of the reasons it could not promise a specific price for its Steam Machine just yet." The author said: "Just as out-of-control GPU prices from earlier this year have finally settled down, runaway memory prices might make them shoot back up again. Every graphics card requires gobs of VRAM, more is better, and word is that Nvidia and AMD are preparing to raise prices to compensate for the crunch. Digital Foundry is recommending you buy a GPU at or below MSRP while you still can, one with 10GB or more of VRAM. Microsoft may also have to raise Xbox prices yet again to compensate, but Sony has stockpiled enough RAM for the PS5 to last some number of months. Epic's CEO Tim Sweeney says it may take years for high-end gaming to recover from the RAM crunch, because of AI. He says 'factories are diverting leading edge DRAM capacity to meet AI needs where data centers are bidding far higher than consumer device makers.'" Wow. So I noted another piece in the news yesterday that said 200 environmental groups - first of all, I didn't realize there were 200 environmental groups. Two hundred environmental groups are demanding - I love that choice of words - a halt to the construction of new U.S. data centers. I guess just on principle. First of all, you know, good luck with that. That might have stood some chance of happening, you know, if we had a bleeding heart democrat running the country at the moment. But our President Trump recently again declared that global warming was a hoax, and that wind turbines cause cancer. So I would be highly skeptical that any number of environmental groups, doesn't matter how many you gather together, are going to get much traction in the Washington climate at the moment. But what's interesting from a technology standpoint is that it does appear that the desire to concentrate an unprecedented amount of computational capacity within a comparatively small physical area is truly causing trouble; right? If nothing else, we know that just getting that much electrical power service to a single location is not something that the existing power grid was originally set up to deliver, nor does it accommodate much variation without a lot of lead time. And when you step back to think about it, the only reason to want, or to arguably, you know, make a case for needing that much computation in such a small physical space has to be economies of scale. What I mean by that is that what's being built is not a single humongous brain. It's a very large number of individual small brains. And they don't actually all need to be under the same roof, or even in the same state, for that matter. It's just more convenient and more cost-effective if they're all grouped together in one place. That way they can all share staff and utilities and walls and security and cooling and a parking lot, and so on. You know, and this sort of suggests that a reasonable compromise might be to limit the total size of individual AI data centers, have more of them, and spread them around more. And that said, I certainly get the coolness factor of having a massive AI data center. I mean, I understand that that appeals to the tech bros. And, you know, if AI actually made money and could pay for itself, then you'd have a potentially viable business model. So I guess you have to save as much money as you can on facilities, hoping that, you know, you're saving money everywhere you can because none of this yet makes economic sense. You know, Leo, what does make economic sense... |
| Leo: Is it that time again? |
| Steve: No. |
| Leo: Oh. What makes economic sense? |
| Steve: What makes economic sense is GRC's new DNS Benchmark. |
| Leo: Oh, I can't wait. We've been waiting. How long have you been - well, first of all, you wrote it once before. |
| Steve: Yes. I actually had, and somebody found in a directory of theirs, the beginnings of a DNS speed test in 2002. So... |
| Leo: Wow. |
| Steve: Yeah, long time ago. And I distinctly remember in '08, in 2008, writing the first version 1 of the DNS Benchmark at Starbucks. I had a little, like, road show, you know, because I have to have a clanky keyboard; right? And so I had a... |
| Leo: There's that guy with that clanky keyboard again. |
| Steve: Well, and of course Starbucks, the Starbucks I was going to was across from UCI. So it's all students. |
| Leo: Oh, UC Irvine, yeah, yeah. |
| Steve: And they all have, you know, spongy quiet Apple keyboards. |
| Leo: Sure, right. |
| Steve: And I'm over in the corner going clankety-clankety clank-clank-clank clankety-clanky. You know. And I would get there, they opened at 4:30, so I would get there because I had to have my... |
| Leo: 4:30 a.m.? |
| Steve: Yeah, 4:30 a.m. Yeah. |
| Leo: Okay. |
| Steve: And so, and I had to have my corner; right? So I would be the first person there. |
| Leo: I'm thinking you were. |
| Steve: I would unlock the door because they hired university students who were short, and they couldn't reach the door's upper lock. And so... |
| Leo: Along comes the guy with the clanky keyboard. He's going to unlock it. Okay. |
| Steve: Having me there, having me there, they wouldn't have to drag... |
| Leo: Do you still get up at 4:30 a.m.? |
| Steve: No. Lord, no. |
| Leo: Oh, this is a long time ago. This is in your youth. |
| Steve: This was in - I happen to know that it was in 2008 when I wrote the Benchmark. |
| Leo: Okay. Okay. |
| Steve: Yeah. And so I just sat there. And then I was part of a group of regulars. And so around 6:30 some of the regulars would start showing up. And so I'd pause and, you know, talk to them. And then they'd wander off, and I'd go back to work. |
| Leo: Now I understand why you go to Starbucks, because I wouldn't want to be in a crowded coffee shop trying to focus. But at 4:30 a.m. you've got the place to yourself. And lots of coffee, to boot. So that's good. I can see, get those two hours of solid work there, yeah. |
| Steve: Yes. And I would leave at a little after 4:00. So I would spend about a full 12 hours in a single stint. And then I'd go find some dinner. |
| Leo: Holy cow. |
| Steve: So that was my routine. And I also perfected the putting the sponge ear foam things deep into my ear canal and then putting these Bose sound blockers on top of that. So, you know, I would just see people's mouths moving, but I'd just be in my zone for about 12 hours a day, writing the Benchmark. |
| Leo: Wow. And you did this at Starbucks why? |
| Steve: Because it was better than being home alone. |
| Leo: Okay. Okay. |
| Steve: Yeah. I mean, you know, a little socializing. |
| Leo: With some people around, yeah, yeah. |
| Steve: Yeah. And I didn't have to walk far to get more coffee. So it was good. Anyway, so... |
| Leo: I did not - I've known you for so long. I had no idea that's what you were doing. Wow. |
| Steve: Yeah. |
| Leo: Okay. So you're in a sprint to write this. |
| Steve: And wait. This would have been '08. This was during the podcast. |
| Leo: Yeah. |
| Steve: Yeah. |
| Leo: Like I said, I had no idea. Okay. |
| Steve: Anyway, so put this on GRC, made it available, and as I've mentioned before, for many, many, many years it was seeing more than a thousand downloads a day. |
| Leo: I used it all the time. I still do, yeah. |
| Steve: We have more than 9.7, I think it is, or maybe 8 million total downloads. And I just - and it had gotten to be 16 years old. And so it was a year ago, it was in December of 2024, that I'd finished with SpinRite 6.1. That was finished. Put it to bed. It's like, okay, I've made my commitment to give everybody a free update to SpinRite, even after 20 years. And I thought, okay, I want to see what I can do with, like, bringing the DNS Benchmark back up to speed. Anyway, so I spent a year working with a bunch of neat guys and Layla, who may be our one female in the GRC dns.dev group, you know, our newsgroup, old-school NNTP servers. And for a while I remember I talked on the podcast about having, imagining having - well, so the idea was to do something GRC has never done before, which is to have an inexpensive commercial product. You know, the only thing I ever had was SpinRite at $89. And I wanted to try doing a, you know, under $10 - well, a little bit under $10, $9.95 - fill it with features, bring it up to date, and offer something that I thought was a good value for a good price. So it happened on Friday was that it, you know, we had a couple almost finished things that needed to get fixed and changed. As everybody knows, the original Benchmark only did - was only able to benchmark IPv4 servers, which is all there almost was back at the time. So the big change was I needed to add IPv6 support. But then of course none of the UDP resolution is encrypted. So it's not authenticated. It's not encrypted. So we have DoH and DoT. Android devices support DoT natively. All of our browsers support DoH natively. So, and in fact in the picture there, Leo, you can see the IPv6 addresses being lots of little digits in two rows. |
| Leo: Yeah. Yeah. They're huge. |
| Steve: And fourth from the bottom is a DNS over TLS server that's also in the list. Anyway, essentially what's happened is, over the course of these 16 years, the Internet has changed a lot. |
| Leo: Oh, yeah. |
| Steve: And the big problem I had was that I had a bunch of false starts trying to figure out how to get this thing to do IPv6 and TLS connections because IPv4 addresses fit in 32 bits. And I was working in a 32-bit architecture. So resolver addresses were, like, they fit in registers. Well, not in the future they didn't. So that all had to get changed. But the biggest thing that has really changed is that version 1 prioritized cached lookups over all else. And that's changed. When we've been talking about things like uBlock Origin and other content-control utilities, we've noted that the content of today's websites are now being pulled from scores of different places, you know, from all over the Internet - libraries and ads and trackers and like chat add-ons and AI pop-ups and all this junk that are now on web pages. Well, those all require DNS lookups. So what's changed is that, whereas a server's caching performance was probably most important back in 2008 when I wrote version 1, that's no longer true. So what the original DNS Benchmark has done, I mean, has always done and still does at version 1, is it first sorts the resolver performance by their cached performance. That completely dominated, by design, all of its resolver ranking. Cached performance, you know, was, as we know, would be the amount of time the resolver would need to reply to a query for a domain's IP that it already knew, that it had already cached locally from someone, you maybe, or someone previously asking for it, and it not having yet expired because IPs, you know, all of the records that DNS caching resolvers cache has an expiration time which allows the Internet to update itself for changing IPs. It turns out that Internet transit times completely dominate that measure, whatever it is we're measuring when we measure cached performance, all of that time is the time it takes the query to get to and back from the resolver. So it is essentially equal to just pinging the resolver. We've tested that. It's about the same. You know, and while it may not seem very useful to know what a resolver's, essentially its ping time is, it turns out that DNS performance is all about connectivity. How well are you connected to the resolver that you are asking IP addresses from? So as I said, the problem was that's all that version 1 of the Benchmark took into consideration. If a resolver close by you could beat out other resolvers, then version 1 of the Benchmark gave it the highest rating. It was at the top of the list. And it was only in the case of a tie in cached performance within its one millisecond resolution that the uncached lookup performance would be considered as the second sort key. Essentially it was like a multi-key sort where the first key, you know, does the gross arrangement, and the second sort key does the finer grain arrangement within the grossly arranged first key. So the problem with that was that a resolver might reply to cached queries in five milliseconds, but then take 10 times as long, like 50 milliseconds, to perform a lookup for something it didn't already have in its cache. Whereas another resolver might take only 1 millisecond more, 6 milliseconds, to reply to a cached query, but be much faster for looking up uncached data, like 10 milliseconds. So you'd much rather be using that second resolver. Unfortunately, well, again, in '08, cached performance dominated because most of the material was coming from the domain you were browsing to. Most servers were providing you all of the content. Now, that's no longer the case. So the other little confounding thing is that 16 years ago, in 2008, no one had local border NAT routers that were also serving as caching resolvers. You know, we had NAT back then, but those early NAT routers were not doing DNS lookups for their NAT clients, as they are now. So that matters because the original version of the Benchmark would be seriously over-impressed by the performance of that local caching DNS resolver sitting right there on our LAN. How could any remote DNS resolver, no matter how fast it might be, possibly compete with a caching resolver that was sitting right next to the user on their own LAN. So, you know, just try pinging your LAN's gateway, and you'll see how quickly it responds. No other DNS resolver out on the Internet can compete. And again, version 1 of the Benchmark was only looking at cached performance. So what does the new version 2 do? It takes the average of all three types of DNS queries: cached, uncached, and dotcom resolution. It's got four sorting options. The original cached-first sort, you know, it's still there for anyone who might want it for some reason. But the new default is "Best" performance, which averages all three types. So anyway, I've spoken before about all the features that are in there. We learned that we were not getting much Benchmark-to-Benchmark consistency. It turns out that even asking 50 different domains for their IPs for each of your resolvers, there's enough jitter in the Internet because the Internet's gotten busier, and it's gotten bigger than it used to be. It turns out that we need to do more asking in order to get statistical significance from the data that we're collecting. So this thing allows you by default to run essentially five rounds of the Benchmark and aggregate all the data. But you can also go for 10, 20, 50, and 100 if you don't mind waiting, like, four hours for a 100x Benchmark. And what's interesting is that you see all of the sorting stabilizing after a while because initially the ranking is jumping around because of Internet jitter. And it actually takes a lot more looking. Anyway, short version is, I'm done with the Benchmark. Anyone can have it for $9.95. I appreciated what Andy was - not Andy. |
| Leo: Alex? Jason? |
| Steve: Alex. Yes, thank you. Although Andy did chime in. Alex has all of our sentiments about how much he hates subscription stuff. |
| Leo: Yes, yes. |
| Steve: And I hate it as much as everybody. So the deal here, you buy this one time, I will never ask you, no matter what happens, for anything for the DNS Benchmark again. All updates and versions, no matter how big or small, they are included in the one-time purchase price. You get to own it for life. And you are also purchasing its entire future when I cycle back around to it and continue to update and improve it. So anyway, I'm done with that. I'm going to get moved into my new home with my wife, and then I will be starting in on ValiDrive 2, which is my next project. |
| Leo: Oh, okay. |
| Steve: To work on a major improvement to ValiDrive, which is now GRC's most often downloaded freeware. |
| Leo: This is the app that lets you determine if you're getting the proper amount of storage on your USB thumb drive. |
| Steve: Yes. |
| Leo: Or if it's just a bogus, which many are, it turns out, even for [crosstalk]. |
| Steve: It turns out many are. More than a thousand copies are downloaded every day. |
| Leo: Holy cow. |
| Steve: Now I think we're up to about 1,100 copies a day. |
| Leo: That's amazing. Wow. |
| Steve: And I'm going to do a lot more for version 2. So the gang who worked with me for a year on testing and came up with lots of good ideas for the Benchmark, I mean, Leo, this is, like, things like it looks at the resolvers, and I do something called "sidelining" because, if a resolver, it very clearly doesn't have any chance of even being in the running, it just gets sidelined by version 2 of the Benchmark so that we don't waste time asking it a lot of questions because it's just too far away. Physical distance on the Internet is what really ends up making the difference. And so anyway, this thing is just - it's got a whole bunch of pop-up dialogs and - anyway, I'm very proud of this last year of work, and before long we'll be onto the next one. |
| Leo: Yes. Congratulations. That's fantastic. All written in assembly language, we might add. |
| Steve: All in assembler. Version 1, I think it was 163K. I think this one's 200K. |
| Leo: Holy cow. Jiminy Christmas. [Crosstalk]. |
| Steve: So I couldn't make it any [laughing]. It does run under Wine. And Leo, it's very cool. It runs on ARM Macs. |
| Leo: Really. |
| Steve: Yes. |
| Leo: Under emulation. |
| Steve: Yes. So the Mac is emulating Intel, and Wine knows how to run on a Mac and use the Intel emulation. So we've got guys in our newsgroup who are running it on ARM, maybe it's Windows ARM. We know that. But I'm sure someone's running it on a ARM-based Mac using Wine and the Intel instruction emulator. |
| Leo: Well, and because this is about network performance, not processor performance, running it in emulation is harmless. That's not... |
| Steve: Right, right. |
| Leo: Nothing wrong with that, yeah. |
| Steve: Right. |
| Leo: Nice. Very nice. Congratulations. GRC.com for more information. |
| Steve: And then the top of every page says "Click here for GRC's new DNS Benchmark, version 2." |
| Leo: Nice. |
| Steve: Oh, and I got rid of all the Plus and Pro. I did talk for a while about having a Plus version and a Pro version. |
| Leo: Right. |
| Steve: I just ended up putting everything into the one version. |
| Leo: One version. That makes sense. |
| Steve: That was just the right thing to do. |
| Leo: Yeah, that makes sense. And 10 bucks, come on. That's nothing. Spend more than that on an ice cream sundae. |
| Steve: Well, you may spend more than that on our next advertiser. |
| Leo: I hope you do. |
| Steve: I'm going to take a sip of coffee, and then we're going to look at some feedback. |
| Leo: I'm praying that you will. Absolutely. 4:30 a.m.; huh? I had no idea. |
| Steve: Yeah. Yeah. |
| Leo: Somebody in the YouTube chat says that you said that before, but I must have missed it. I knew you went to the Starbucks for that quad venti latte. But I didn't know you stayed all day. Not anymore. |
| Steve: I think I was drinking Americanos back then, which was the, you know... |
| Leo: Oh, okay. Stronger, yeah. |
| Steve: Shots of espresso in hot water. |
| Leo: Oh, yeah, that's right. So it's espresso. |
| Steve: Yeah, so it's - it was the right thing at the time. So, yeah. |
| Leo: It's what you needed [crosstalk]. |
| Steve: And, you know, we had a great group of people who became, I would say lifelong friends, except COVID extinguished it. |
| Leo: It really was a social thing for you as much as anything else. That's interesting. Yeah. |
| Steve: Yeah. Yeah, it was fun. |
| Leo: Yeah. |
| Steve: Okay. Stefano from Sunny Italy, as he put it. He said: "Hi, Steve. I feel there's a specific aspect which has been left out in this whole Cisco improvement of resilience see-the-light moment." He says: "As a long-time network engineer, I always found infuriating the hoops that I have to jump through in order to download a patched firmware image from any of the biggest vendors, especially Cisco. Them crying about the fact that there are so many unpatched devices still exposed is peak irony, and it is partially on them. "If I buy some piece of hardware, I expect you, the vendor, to support it and patch it for a reasonable amount of time." I would argue, you know, the device's useful life, but okay. He says: "But within that reasonable time frame I must be able to easily access updates without them being locked out behind 'support contracts' or similar immoral (in my eyes) double dipping. Device lifecycle management is perhaps the hardest part of this job. The strings of the purse are never in our hands, so it's not our call. Only the consequences are on us." Oh, meaning that he's on the IT end, not on the management budget pay-for-it end. So, you know, it literally, if he doesn't have the support contract or the paid-for access or whatever, he can't update his hardware. He finishes, writing: "I'm sure many more fellow engineers have been in my same situation, perhaps after changing jobs and ending up in a barely maintained infrastructure or simply having to wait for the next round of funding in order to swap out some old lemon. Quoting Cisco's Anthony Grieco: 'This is further amplified by the fact that many organizations have not updated and maintained their network infrastructure, missing opportunities to fix known vulnerabilities." He said: "Then stop preventing me from doing so, Anthony." Signed, the Steve from sunny Italy. So his note reminded me that back when I was running a bonded pair of T1 trunks - remember those old days, Leo, when we were doing this over those - to my home here, I was using a Cisco router to do the work. It's one of the reasons I know it intimately. And Cisco was not wonderful to deal with back then. I had assumed that they were better now, but sounds like it's really still the same Cisco, based on what Stefano has indicated. So let's hope that Anthony, now in charge, apparently having seen the light, does something with it. That'd be really good. Blair Learn wrote: "Hi, Steve. I ran across an item I don't believe you've covered yet. Google recently rolled out in Chrome 142 something they're calling 'Local Network Access.' The gist of it is that, if you have a public website such as example.com, it has the potential to host malicious JavaScript code which attempts to access resources on your local" - your local - "network. For example, the router admin interface on 192.168.0.1." He says: "The technique seems similar to the issue you described a month or two back with adware setting up a server on a phone's localhost address to be used by the adware vendor's ad code for tracking purposes." He said: "Local Network Access is a new permission in the browser." It's not quite that, but I'm going to explain exactly what it is. "The user is prompted to allow access to devices on the local network; and, if permission is denied" - he's right about this - "then code on example.com is prohibited from contacting resources in the myriad local networks." Now, you might ask, "Why would you ever want to allow such a thing in the first place?" He says: "My use case was a development website hosted by an external vendor, with a JavaScript application contacting a test version of an API that was hosted on a server which is only accessible via VPN." He said: "Probably not something most home users are going to encounter, but I have to imagine our enterprise developers would." He said: "Google has a blog post about it," and then there's the link in the show notes, and the spec can be found at, and he has the W3C's, you know, the World Wide Web Consortium's URL. He says: "I always look forward to the next episode of Security Now!. SpinRite licensee, Club Twit member, and general-purpose geek. Blair." Okay. So this issue that Blair mentions Google finally addressing has been a significant and growing problem forever. And I'm surprised, actually, that it hasn't been causing more havoc. There was a point, I think it might have been during the pre-release of IE11, which was surprisingly long ago - time flies, Leo - where Microsoft, and I've mentioned this before, flirted with flatly denying their IE11 browser access to the localhost address 127.0.0.1 and/or the local LAN. This came up at the time because I was working on SQRL. And one of the ways, that is, Microsoft's plans of blocking localhost access came up at the time because I was working on SQRL. And one of the ways SQRL robustly prevented interception of any secrets was by allowing the user's local browser to connect to a little web server running in SQRL on their machine. This gave the browser a private connection to the SQRL authenticator, which they could use to cut out any possible man in the middle. Now, Passkeys, as we've discussed, implements the same form of protection with users' smartphones over a Bluetooth link to create a local link between the web browser and the smartphone Passkeys authenticator that no remote attacker can possibly intercept. Now, in the case of Microsoft and IE11 and the localhost IP, they fortunately came to their senses and realized that there were far too many valid use cases where a web developer, for example, might be running a local web server or web services on their local machine and need to be able to access it with their browser during the development and testing. Until now, this has remained an unsolved problem which was really in need of a comprehensive solution. Our browsers, as we know, are no longer just passive content displays. Technologies such as JavaScript and WebAssembly have turned them into effective application platforms. So just to be completely clear about the nature of the problem, from the perspective of any web browser device, you know, web client, web-browsing client, sitting on a private local area network, that web browser has network visibility into two completely different networks. It can obviously "see" and access the global public Internet because it's able to access and obtain remote content. But the browser can also just as easily "see" its own local area network. We know this because, for example, LAN routers are managed by aiming a browser at the LAN router's gateway IP, which is typically 192.168.0.1 or .1.1 or something like that. Our web browsers can see everything on our own LANs. So the problem is that a user might visit a malicious remote website which causes their web browser to download and run some malicious JavaScript or WebAssembly or whatever code. Now that the code is running inside the user's browser, essentially the Trojan horse has been invited into the house. So unless something is done, that malicious code that's now running in the user's browser has the same access to their LAN as they do. It can reach out and log into their LAN router, scan their network for other juicy targets, you know, find printers, transfer code, upload firmware, you know, get up to whatever mischief it might wish to. When you stop to think about it, it's somewhat amazing that this big loophole has not been closed a long time ago. So the good news is, it's finally going to happen. The W3C's specification for this new feature explains its entire purpose and scope. They write: "Although RFC1918" - that's the thing that set aside our LANs 192.168.x.x, the whole 10-dot network, the 172.16 through a bunch of other successive IPs. Those were all set aside by the specification of RFC1916 long ago. So they said: "Although RFC1918 has specified a distinction between 'private' and 'public' Internet addresses for over two decades, user agents have not made much progress in segregating one from the other." This is the W3C writing this. "Websites on the public Internet can make requests to local devices and servers, which enable a number of malicious behaviors, including attacks on users' routers." Then they list a whole bunch of examples. They said: "Local Network Access" - that's the formal name for this - "Local Network Access aims to prevent these undesired requests to insecure devices on the local network. This is achieved by deprecating direct access to local IP addresses from public websites, and requiring that the user grants permission to the initiating website to make connections to their local network. The overarching goal is to prevent the user agent" - the browser - "from inadvertently enabling attacks on devices running on a user's local Intranet, or services running on the user's machine directly. For example, we wish to mitigate attacks on users' routers or on software running a web interface on a user's loopback address, 127.0.0.1. For better or worse, this is becoming a common deployment mechanism for all manner of applications, and often assumes protections that simply do not exist. "There should be a well-lit path," is the way they described it, "to allow these requests when the user is both expecting and explicitly allowing the local network access requests to occur. For example, a user logged into plex.tv may want to allow the site to connect to their local media server to download media content over the local network instead of routing through remote servers. "The specification then clarifies the intent of this with a couple of quick examples." They said: "Alice is at home on her laptop browsing the Internet. She has a printer on her local network built by Acme Printing Company that's running a simple HTTP server. Alice is having a problem with the printer not functioning properly. So Alice goes to Acme Printing Company's website to help diagnose the problem. Acme Printing Company's website tells Alice that it can connect to the printer to examine its diagnostic output. Alice's browser asks Alice to allow support.acmeprintingcompany.com to connect to local devices on her network. "Since this is something Alice wants and is expecting, she grants explicit permission for that website to connect to local devices on her network. Acme Printing Company then connects to her local printer's diagnostic output through Alice's web browser." And I'll just note that it may be a little bit unnerving for people to realize this is possible, that is, it is possible for Acme Printing Company to connect to Alice's printer through her web browser. I mean, these browsers have become incredibly powerful now. They can act as proxy gateways into our LAN. So Alice's web browser says yes, tells Alice that it is part - oh. So Acme Printing Company then connects to her local printer's diagnostic output through Alice's web browser and tells Alice that a part is malfunctioning on the printer and needs to be replaced. Then W3C also provides an alternative sample: "Alice continues browsing online to find the best price for the replacement part on her printer. While looking at a general tech support forum, she suddenly gets a permission request in her browser for https://printersupport.evil.com to connect to local devices on her local network. Being suspicious of why printersupport.evil.com would need to connect to local devices, she denies the permission request." And I'll just, ahem, we hope. Okay. Which is to say all of this, of course, presents us with a new problem because while, yes, it's 100% true that for the first time ever, the user sitting in front of their web browser will be required to proactively allow some remote website to access their network, and that definitely represents a nice step forward in security capability. The trouble is, it's still just a capability because we've also just saddled users with the new responsibility of determining what's benign and what's malicious. How is anyone really going to know? If we've learned anything, it's that many users are unable to reliably tell the difference. And it's not their fault, since we've also seen bad guys who are highly motivated and very inventive, cooking up all kinds of tricky schemes to trick people. We know that the so-very-human user remains the weakest link in the security chain. So now Chrome, as of Chrome 142, and presumably other browsers to follow since this will be, you know, this is a W3C official specification, all the browsers will be popping up notifications when something you're doing requires a remote site to have access to your local network. Allowing that to happen without any notification, as we have been doing until now, is certainly not safe. But no one should imagine that, if any really juicy targets should appear on user networks, the bad guys aren't going to wait; right? They're going to cook up some very reasonable appearing reason why users should give their remote web domains that will not be called evil.com. They're going to be called heavensent.com, you know, access to the user's local network devices. It's going to happen. So I'm sure that the Google Chrome guys, who were the driving force behind this W3C spec, they know this is an imperfect solution. But they also know it's the best that they could come up with. They needed to put up some roadblock so that browsers could not do this behind users' backs. They know that they really can't count on users to be judicious about what to and to not allow. I saw a sample Google pop-up, and it just says, "Example.com wants access to your local network." Hopefully people know that should be no, unless there's like... |
| Leo: Unless you want to go to sample. |
| Steve: ...a reason for it to happen. |
| Leo: Because I go to localhost all the time. And if you don't want to... |
| Steve: Well, and see, that - I'm glad you said that, Leo, because that's a good point. What we, thanks to the security work that's been done so far, there is a clear binding between any script or web assem and the domain from which it came. So essentially you are temporarily whitelisting that domain to have access to your local network. Which is to say, you know, a browser will have multiple tabs open, and there will be scripts running from advertisers and from all of the different domains you're visiting. They will not have a whitelist for access to your LAN. It's only the script that you've whitelisted from that domain that will. |
| Leo: Okay. |
| Steve: And the point is, you'll be able to still put 192.168.0.1 directly into your URL and go there because you are the source of that access to the local domain, you at your browser, not indirectly through some remote domain. |
| Leo: Yeah. |
| Steve: So unless something remote wants to do this, most users, even power users who are logging into their local routers or going to their printer's HTTP server, you know, their browser will just allow that without any trouble. You won't get challenged when you're initiating that to your own LAN yourself. Only when some remote domain wants permission to do that. And then you get a pop-up which will only temporarily whitelist any script running from that one domain. And here we are, two hours. It's time to talk about the - oh, boy - the latest disaster. |
| Leo: The worst CVE in history. |
| Steve: Yeah, it's really bad. |
| Leo: Well, there's nothing worse. |
| Steve: No, you can't get better [crosstalk]. |
| Leo: No elevens. |
| Steve: It's too bad they didn't give it an 11. That would have been fun. |
| Leo: A remote access to React sounds pretty - about as bad as you can get. |
| Steve: Oh, boy. |
| Leo: We'll talk about that. |
| Steve: It's the definition. In fact, we're going to start off by defining what would be, because our listeners all know now enough about this. What would be the characteristics of the worst possible exploit available? |
| Leo: Okay. This is a little thought exercise. Think about that for a moment. |
| Steve: We've had them all. |
| Leo: All right, Steve. Now, on we go. |
| Steve: So as I said, by this time, from everything we've seen and shared on this podcast through the years, we can probably all define what a worst-case vulnerability looks like. It would affect any popular, widely present Internet-facing server. It would not require the remote attacker to be in any way "authenticated" on that server. It would allow said attacker to whatever code they would wish any such server to execute on their behalf. And the attack would have a low complexity so that no rocket science is needed. Taken together, in the parlance of the day, we would term this as a critical, unauthenticated, low-complexity remote code execution vulnerability. A shorter, though less descriptive summary, might also be "CVSS 10.0." |
| Leo: Yeah. |
| Steve: Because, you know, most of what we see is they're trying to get there. They're a 9.8, but they're not really completely, just unbelievably bad. |
| Leo: Underachievers, obviously, yeah. |
| Steve: This, yeah, they were - this is a 10.0. The headline given to Dan Goodin's reporting of just such a vulnerability last Wednesday, so not even a week ago, in Ars Technica was "Admins and defenders gird themselves against maximum-severity server vuln." In the subhead it says "Open source React executes malicious code with malformed HTML, no authentication needed." So there's a lot to cover here. Let's begin with Dan's description in Ars Technica. He says: "Security defenders are girding themselves in response to the disclosure of a maximum-severity vulnerability disclosed Wednesday in React Server, an open-source package that's widely used by websites and in cloud environments. The vulnerability is easy to exploit and allows hackers to execute malicious code on servers that run it. Exploit code is now publicly available. "React is embedded into web apps running on servers so that remote devices render JavaScript and content more quickly, with fewer resources required. React is used by an estimated 6% of all websites and 39% of cloud environments. When end users reload a page, React allows servers to re-render only parts that have changed, a feature that drastically speeds up performance and lowers the computing resources required by the server. "Security firm Wiz said exploitation requires only a single HTTP request and had 'near-100% reliability' in its testing. Multiple software frameworks and libraries embed React implementations by default. As a result, even when apps don't explicitly make use of React functionality, they can still be vulnerable, since the integration layer itself invokes the buggy code." In that sense it's a little bit like log4j, right, which we recall, although that wasn't bad as it turned out. This has already turned out to be bad. "The combination of the widespread use of React, particularly in cloud environments; the ease of exploitation; and the ability to execute code that gives attackers control of servers has earned the vulnerability a severity rating of 10, the highest score possible," writes Dan. On social media, security defenders and software engineers urged anyone responsible for React-related apps to immediately install an update released Wednesday. One researcher wrote: 'I usually don't say this, but patch right freaking now. The React CVE listing (CVE-2025-55182) is a perfect 10.' "React versions 19.0.1, 19.1.2, or 19.2.1 contain the vulnerable code." So that's worth noting. It's only this year's Reacts. So this happened this year. I hope you're not running an older one because that would be worse. But, you know, so update again. "Third-party components," writes Dan, "known to be affected" - so these are third-party things that have React in them - "include Vite RSC plugin, Parcel RSC plugin, React Router RSC preview, RedwoodSDK, Waku, and Next.js, that being a biggie, of course. According to Wiz and fellow security firm Aikido, the vulnerability, tracked, as I said, 2025-55182, resides in Flight, a protocol found in the React Server Components. Next.js has assigned the designation" - they have a different CVE - "66478 to track the vulnerability in its package." And then Dan hits us with the nature of the vulnerability, which will also come as no surprise to our longtime listeners since this podcast long ago identified "interpreters" as a particularly tough problem for secure systems. Dan writes: "The vulnerability stems from unsafe deserialization, the coding process of converting strings, byte streams, and other 'serialized' formats back into objects or data structures in code. Hackers can exploit the insecure deserialization using payloads that execute malicious code on the server. Patched React versions include stricter validation and hardened deserialization behavior." In other words, they fixed a bug in the deserializing interpreter, which interprets the serialized stream and makes a mistake. "Wiz explained: 'When a server receives a specially crafted malformed payload, it fails to validate the structure correctly. This allows attacker-controlled data to influence server-side execution logic, resulting in the execution of privileged JavaScript code.' They added: 'In our experimentation, exploitation of this vulnerability had high fidelity, with a near 100% success rate, and can be leveraged into a full remote code execution. The attack vector is unauthenticated and remote, requiring only a single specially crafted HTTP request to the target server. It affects the default configuration of many popular frameworks.' "Both companies," writes Dan, "are advising admins and developers" - meaning React and Next.js - "both companies are advising admins and developers to upgrade React and any dependencies that rely on it. Users of any of the Remote-enabled frameworks and plugins mentioned above should check with their maintainers for guidance. Aikido also suggests admins and developers scan their codebases and repositories for any use of React." Meaning you might have included it as a dependency in some build structure and not even know it's in there. But React is still accepting that stream when it comes to it and could then trip over its own feet and execute bad code in your system. Dan's article quickly generated 79 comments from which the Ars staff chose one, which reads: "Just ask Grok for a proof of concept. Basically the deserialiser can be made to execute any arbitrary code by encoding a nested object with an eval expression into Base64 bytes. Shockingly easy to do," he wrote. Okay. So now let's step back a bit to answer the question "What is it?" Wikipedia sums it up nicely, writing: "React (also known as React.js or ReactJS) is a free and open-source front-end JavaScript library that aims to make building user interfaces based on components more 'seamless.' It's maintained by Meta and a community of individual developers and companies. According to the Stack Overflow Developer Survey, React is one of the most commonly used web technologies today. "React can be used to develop single-page, mobile, or server-rendered applications with frameworks like Next.js and React Router. Because React is only concerned with the user interface and rendering components to the DOM, React applications often rely on libraries for routing and other client-side functionality. A key advantage of React is that it only re-renders those parts of the page that have changed, avoiding unnecessary re-rendering of unchanged DOM elements. React is used by an estimated 6% of all websites." Okay. So now we have some sense for what React is. How widespread is its use? The platform security company "Ox" titled their reporting of this Wednesday "Millions of servers vulnerable to RCE in React Components." They wrote: "A critical vulnerability in React and Next.js allows attackers to execute code on vulnerable servers without any authentication, potentially exposing millions of applications to immediate risk. React is one of the most popular JavaScript libraries for building user interfaces, created by Facebook (Meta), with over 1.97 billion total downloads." Almost two billion downloads. |
| Leo: That's a lot of downloads. |
| Steve: That is a lot of downloads. "Discovered today (Wednesday), this vulnerability affects the React and Next.js ecosystems, which power over 10 million active websites globally, including major platforms built with React such as Instagram, Netflix, and Airbnb that serve billions of users daily. With React downloaded over 20 million times weekly, new vulnerable applications are being deployed continuously. The potential exposure is massive, spanning e-commerce platforms, financial services, healthcare applications, and enterprise systems worldwide." Okay. So you know the bad guys are going to be just salivating. They wrote: "What we know: React (CVE-55182) and Next.js (66478) contain a critical RCE vulnerability, enabling the attacker to execute arbitrary, privileged JavaScript code on the vulnerable server. While the core issue stems from the React vulnerability, the Next.js vulnerability exists only because it directly used a vulnerable version of the React framework itself. The attack doesn't require any kind of authentication from the attacker or a valid running session for the RCE to work. "Who is affected? Any server running an unpatched version of React or Next.js, or any package based on a vulnerable React component. Using Shodan, we found that there are over 571,249 public servers using React components, and 444,043 using Next.js." So together more than a million. "While we don't know the versions of each of those servers, it would be safe to assume that even if a small number of them are inside the vulnerable versions range, the impact is on a high scale and should be addressed immediately. "Since this issue impacts any server online running React or Next.js, which are highly popular JavaScript-based packages, this means that attackers could now scan and directly exploit those servers. This potentially could harm millions of servers around the world causing information leakage, secret extraction, and more." All right. So it's not good. Did anyone notice? Ha. You betcha. Two days later, Friday, December 5th, "Ox" followed up with their report of active exploitation under their headline "React's CVE-2025-55182 Is Now Actively Exploitable: Verified PoC." They wrote: "Hacker maple3142 published a working Proof of Concept for 55182 which we successfully verified. Just two days after we published our initial analysis of the React/Next.js server-side RCE vulnerability, a fully functional exploit has been released publicly. The Proof of Concept works exactly as expected and results in unauthenticated remote code execution on vulnerable servers. "The exploit abuses React's..." blah blah blah, we all know about that. So then they get into details of the attack and congratulate the exploit's author, this maple3142, calling it great work. They also provide a link to maple's exploit demo on GitHub. And I have a link at the bottom of page 20 in the show notes for anyone who's interested. To no one's surprise, the industry has jumped to get this resolved. This is an emergency. And there were apparently a few hiccups along the way. Cloudflare notably suffered a 25-minute oopsie! outage while working to protect all of the servers behind them from the abuse of the vulnerability. "Network World reported under their headline: 'Cloudflare firewall reacts [pun there] badly to React exploit mitigation," with the subhead "In attempting to fix one problem, Cloudflare caused another." They wrote: "Cloudflare's network suffered a brief but widespread outage Friday, after an update to its Web Application Firewall (WAF) to mitigate a vulnerability in React Server Components went wrong. At 9:09 a.m. UTC, the company reported that it was investigating issues with the Cloudflare Dashboard and related APIs, warning that customers might see requests fail or errors displayed. Just 10 minutes later, they had deployed a fix." And actually it looks more like it was a 25-minute outage. So maybe it was 15 minutes into it, then 10 minutes after that they had a fix. So a total of 25. They wrote: "But not before a flood of reports of problems with Cloudflare and its customers poured into uptime tracking sites such as Downdetector.com. During the same window, Downdetector saw a spike in problem reports for enterprise services including Shopify, Zoom, Claude AI, and Amazon Web Services, and a host of consumer services from games to dating apps." Cloudflare explained the outage on its service status page, writing: "A change made to how Cloudflare's Web Application Firewall parses requests caused Cloudflare's network to be unavailable for several minutes this morning. This was not an attack. The change was deployed by our team to help mitigate the industry-wide vulnerability disclosed this week in React Server Components." The Ox report said: "Cloudflare was no doubt attempting to protect those of its customers who have not yet had an opportunity to patch the vulnerability in the two days since it was revealed. The wobble in Cloudflare's services comes just two weeks after a much bigger one rendered its customers' websites inaccessible," and so forth, blah blah blah. So anyway, I appreciated how these guys at Network World concluded their posting. They wrote: "There are some advantages in relying on single service providers such as Cloudflare or AWS for these tasks, including economies of scale and service consistency. But it also makes them single points of failure. When they go down, everything goes down with them." This is what we were just talking about two weeks ago. In such a monoculture, the alternatives that might be able to take up the slack have already been weeded out. Meaning acquired or put out of business, or just not available for whatever reason. So I think that gets it exactly right. Cloudflare's own posting about this noted that their logs did not capture any evidence of successful exploitation of this vulnerability against any of their free or commercial customers. And by the way, both were protected by this. Cloudflare's WAF, their web application firewall update also protected anybody on the free plan. They never said explicitly that their apparently WAF change service outage was a mistake, but it certainly seems like it had to be. You know, they're continually updating their Web Application Firewall patterns with new detections and blocks, and their customers are not experiencing system-wide outages on an ongoing basis. So I think they, you know, fumble-fingered it, you know, something somewhere. And of course AWS and Fastly and other CDNs also quickly deployed their own network protections for their customers. So everybody pretty quickly got protected. I should also mention that two China-based threat actors were seen to immediately jump onto this exploit with attacks beginning within hours of the vulnerability's public disclosure. Well, remember that was Wednesday. And the CDN protections didn't snap into place for a full 48 hours. So there was likely some serious damage done during this window from disclosure to fix. Which sort of suggests that this could have been done better. There's no reason, for example, that the major CDNs, at least, could not have been brought into a loop on the DL and allowed to have their application firewalls updated so they would have been protected before the disclosure. No reason for that not to happen. So maybe somebody will be thinking about that. The AWS security team linked the attacks that they saw to two groups tracked as Earth Lamia and Jackpot Panda. AWS wrote: "Earth Lamia is a China-nexus cyberthreat actor known for exploiting web application vulnerabilities to target organizations across Latin America, the Middle East, and Southeast Asia. The group has historically targeted sectors across financial services, logistics, retail, IT companies, universities, and government organizations. And Jackpot Panda," they wrote, "is a China-nexus cyberthreat actor primarily targeting entities in East and Southeast Asia. The activity likely aligns to collection priorities pertaining to domestic security and corruption concerns." Whatever that means. So Amazon says the attackers used anonymizing proxies to hide their infrastructure so requests were being bounced through other systems, and also deployed exploits for other vulnerabilities using these as the backdoors to get in. Interestingly, both groups used their own homegrown exploit implementations. Remember the proof of concept, even that took two days before it went public. But this thing was so dead simple to do that no one waited. You didn't have to wait two days. These things, the attacks started within hours of the disclosure that there was a problem. And they rolled their own exploits because it was so easy to do. So then later, multiple public proof-of-concept exploits were released, including one from Lachlan Davidson, a security researcher we've talked about before. He was the guy who initially found and reported this devastating vulnerability. So it's likely not an exaggeration to say that this vulnerability is probably going to haunt the developer ecosystem for some time due to its ease of exploitation, widely available proofs of concept, its low complexity versus its power, as well as React's popularity. Next.js is currently considered to be the best web technology available for producing very SEO-friendly content. If a technology was ever expected to replace WordPress, people in the know argue that it would be Next.js that would be the replacement for WordPress. Palo Alto Networks wrote: "Ultimately, this incident underscores the inherent friction between performance and security in modern architecture. While React Server Components optimize data fetching and search engine optimization by moving logic closer to the source, they simultaneously move the attack surface closer to organizations' most sensitive and valuable data." Which I think that's a terrific perspective. So anyway, I wouldn't say we dodged a bullet. I would say that a bunch of people probably got hit. And over time we may get some more news, like by next week, of what organizations are in trouble as a result of this. We could see that those who weren't immediately reactive, so to speak, are going to be in trouble. And we'll start getting, you know, extortion notices and data exfiltration and all of the follow-on, you know, badness that comes after a network is penetrated. |
| Leo: Yeah. Wow. And so it's been patched. |
| Steve: Yes. |
| Leo: And our - does React work to automatically update itself? Or do you have to explicitly... |
| Steve: No, there's no - you need to get the... |
| Leo: There's no updates. |
| Steve: ...the updated stuff, yes. |
| Leo: Wow. |
| Steve: And I should mention that the Benchmark that is now available does have "Automatically check for updates" enabled. |
| Leo: Oh, good. |
| Steve: And it will alert its user every time they use it. All I do is send a short DNS query to GRC. I'm using DNS in order to... |
| Leo: Oh, that's clever. |
| Steve: In order to send back the most recent release number. And so it checks that against its own release, and it lets you know if there's something better, and also gives you the link to update and puts your transaction code from your purchase into Notepad, I mean, into the Clipboard, so you can paste it directly into the form and get the download link for the new one. We had, thanks to a year of development, we had lots of time to polish the whole update delivery system. |
| Leo: Feedback's great. That's really great. |
| Steve: Yeah. |
| Leo: Well, good. Everybody should go to GRC.com and get your copy of the DNS Benchmark Pro. You're not calling it Pro, you're calling it Version 2. |
| Steve: Just v2, Version 2. Buy it once, own it forever, and own its entire future. |
| Leo: Nice. |
|
 | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2026 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |  |
| Last Edit: Dec 16, 2025 at 10:35 (156.01 days ago) | Viewed 6 times per day |