Security Now Episode 850 Transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show.

Leo Laporte (00:00:00):
It's time for Security Now, Steve Gibson is here. We have yes, of course. More on Log4j, the worst security exploit of all time. At least that's what I'm thinking is Steve continues to describe how bad it is yet. Another let's hope. It's the last zero day for Chrome. Yes, they're gonna fix it and Flipboard in the cloud. What could possibly go wrong? It's all coming up next on Security Now.

New Speaker (00:00:30):
Podcasts you love from people you trust. This is TWiT.

Leo Laporte (00:00:38):
This is Security Now with Steve Gibson. Episode 850 recorded Tuesday, December 21st, 2021. It's a Log4j Christmas. This episode of Security Now is brought to you by Andela. Andela is a global talent network. Connecting innovative companies like yours with quality technical talent. So you have more time to focus on your core business. Visit to schedule a complimentary consultation and receive a two week no risk trial with their vetted technical talent and by Stripe, whether you're an online or in-person retailer software platform, marketplace, or subscriptions business like ours, visit to learn more about how Stripe can support your business today and by Userway ensures your website is accessible, ADA compliant, and helps your business avoid accessibility related lawsuits. The perfect way, way to showcase your brand's commitment to millions of people with disabilities. It's not only the right thing to do. It's also the law go to for 30% off user way's AI powered accessibility solution. It's time for security now. Yes, indeed. We're gonna soon rename this to the Log4Shell show <laugh> Steve Gibson is here. He's a security in Chief Security Officer. Hello, Steve.

Steve Gibson (00:02:12):
Hello, Leo. That's an unofficial title by the way. I just gave it to you. I do respond to that. So that's fine. Yes. here, this, this is episode 850, and it was like, wow, that makes the remarkable really easy because it means we've got 150 left and then

Leo Laporte (00:02:33):
You're gonna make why do you keep bringing that up? I think you're gonna make me cry, dude. You're gonna make me cry.

Steve Gibson (00:02:36):
Well, that's gonna be that's three years, Leo. That really should do it. We'll I think Log4j will finally be resolved. Well, actually there are some opinions about that. Google will, we'll be talking about that about the depth to which this thing has been submerged into our Java libraries, but the other nice number is 12 21 21, which is today which I guess means Christmas is not far off. Not far. I should go get some wrapping papers. Anyway, it gets me too <laugh> first get presents to put in the wrapping paper then wrapping paper. But, but, but yes to day's title is it's a Log4j Christmas and actually the CISA has for forbidden any it people to open any presence before they have fully remediated their federal enterprises of for Jay, which is nice to say, I mean, you know, you can say it, but it's not happening.

Steve Gibson (00:03:45):
And we'll be talking about that because Google did some, some interesting analysis. But of course there was no way that a massively widespread vulnerability in Java carrying a CVSs score of 10.0 could possibly have been wrapped up last week. So this week we'll be looking at the further consequences of the Log4j vulnerabilities, including the two additional updates the Apache group have since released as a consequence of more eyeballs, looking at the code and going, oh, Hey what about this little problem over here, God? Oh my God. But before that, we're gonna look at what will hopefully be Chrome's final zero-day patch of the year fire foxes, surprising refusal last week to take its user over to, what, and Mozilla's decision to protect its users from windows 10, cloud-based clipboard sharing, cloud-based clipboard sharing, you know, that just, it, it, you don't even have to wonder what could possibly go wrong with that.

Steve Gibson (00:04:59):
Yeah. Yep. Oh, we have a new and interesting means of increasing the power of fraudulent cell tower, stingray attacks and a continuing threat from cross radio wifi to Bluetooth leakage within our handsets. I wanna touch briefly on a sci-fi reminder about what's happen tomorrow. I'll be on the couch with popcorn <laugh> and I've, I've got a spin right update and, and that's actually Lori and I will both be on the couch with, so with sore shoulders, because we have a 9:00 AM appointment in the morning. Oh, good for you. Yay. To, to, to boost ourselves. Yeah, we were for a while, we were thinking, well, actually I was wanting to wait to see if Amron would produce some change. And I, I was gratified to hear in the background, one of the talking heads saying that although modern is looking at an altered booster one, one of the consequences of Aron appears to be the booster fall off is much more rapid than it was with Delta it's pro providing on the order of only a few months of protection against Aron. I'm gonna start

Leo Laporte (00:06:16):
Giving shot. I said, <laugh> whatever it takes, you know, what

Steve Gibson (00:06:20):
A mess. Yeah. A mess. Anyway. So that scifi reminder an update on, on some interesting stuff that has happened with, in my spin right world this past week. And then we're gonna dig into everything that's happened in the previous week on the Log4j front. So I think another, I final podcast, not of forever just of the year <laugh> we got three more to go, at least. So <laugh> 

Leo Laporte (00:06:48):
We actually I want to while I'm doing this ad point, you to you probably read it the project zero analysis of how the Pegasus exploit got around Apple's blaster. Have you read it yet? Oh,

Steve Gibson (00:07:02):
I did not read, oh

Leo Laporte (00:07:03):
My God, you will get such a kick out of it because in a sense, essentially, the way it worked was as, as you know, it's these rendering engines that are always, always the flaws, it's the interpreter and the PDF rendering engine that they use for Apple's messages is an old open source X PDF. So program, and it turns out it's got a buffer overflow and, you know, and your overflow, these things happen. And, but the bad guys, I guess, I guess the NSO group figured out that by ending that a GIF file was a GIF file and actually making a PDF would trigger the PDF renderer, and then they could trigger the overflow. And then they discovered that you could in effect, put four logic gates in a random location of memory, an and gate and Norgate or, and, or gate Exor. And and there's one more and another, or no, no, yes. I think it's an Exor or something like that. But with those four, they could make a touring complete system. They basically built an operating system and code rendering engine. They gave them registers. It gave them comparators gave 'em everything.

Steve Gibson (00:08:24):
Oh my

Leo Laporte (00:08:25):
Lord. It's it's a, you know, if it weren't so evil, it's really a work of genius. It's amazing.

Steve Gibson (00:08:32):
Yeah. So, so you're saying that they, that they located four locations where they could get that work and then they knit those locations together. Exactly. In order to create basically pseudo code yes. Out of those. Yes. It's brilliant.

Leo Laporte (00:08:48):
Wow. wow. It's a, it's a two parter. The, the project zero team put up at Google project, zero blog spot dot com. And the second part is not out yet, but I think you will, it'd be a good Christmas Eve reading, maybe you and Lori can gather around the fire and you can read it out loud, I think. Well, and if there's any more surprises that haven't already been given away, maybe it's the first, our first podcast of the new it'd be. I would, I would love to hear you talk about this. Yes, absolutely. But before we do all of that, let's talk about Anela. I love Anela S motto brilliance is evenly distributed all over the globe, but opportunity is not. Now, this is nice because your business probably needs some very skilled, talented coders, developers, people to help your engineering team.

Leo Laporte (00:09:38):
But you've, you know, you're, you're looking at people next door. You're competing with all those other companies, including the big tech companies, maybe you've run out of, of great coders locally. And D is a global talent network with a mission to connect that brilliance a all over the world with opportunity they're developers in Africa that are well trained, super skilled, brilliant, just as an example, but there's not the opportunity there. There's no companies hiring so ELA. And I think they started in Africa. They're worldwide. Now has found a way to, to find these people, to vet them top tier vetted engineers for your company. They use expert technical recruiters who go out in the field, find these people, proprietary, matching algorithms. They're literally connecting you with the best developers in the business, which means you can focus on getting the job done in your company.

Leo Laporte (00:10:35):
You can accelerate productivity. You can drive revenue. You can scale your business with great engineering talent. This rigorous feting process makes sure that the hiring is quick, it's efficient, but maintains the highest quality standards to ensure they place you with top quality engineers at scale, because it's so hyper competitive out there. Companies that limit themselves to local hires are at a real disadvantage with A N D E L A. You could tap into their pool of highly qualified talent from around the world, cut your timelines down from months to days. And by the way, they are embedded, they are not like contractors. They're not working in a distance and kind of out of, of touch Andela engineers will be efficiently onboarded. They'll be ready to deliver within days, they guarantee at least five hours of overlapping working time with the rest of your engineering team.

Leo Laporte (00:11:30):
They're really, they're, they're not part-time support. They're fully part of your organization. I'll give you some examples. You'll find plenty of references for Anela on the website. Companies have discovered Anela delivers the best engineering talent Mindshare partnered with Anela to quickly hire 10. They need 10 new digital experts, and they needed them yesterday. And I'm talking high level talent, like data scientists, machine learning specialists. They needed software developers of all kinds of analysts. The executive director and head of business intelligence at Mindshare gave us this quote. He said, as we continue to enhance the synapse platform, got his plug in there. Good job, time to values, very important. And Dell is a good partner in helping us identify the talent that's fit for different purposes. They use Anela. I think you should check it out. Tap into a wider talent pool. Stop competing with major tech companies, spend less time interviewing more time getting the job done. Remember brilliance is evenly distributed all over the world, but opportunity is not. And that's an opportunity for thanks to Andela visit a to schedule a complimentary consultation. You can even get a two week no risk trial with their vetted technical talent Great is out there waiting for you. Andela.Com/for-companies, and now onto the picture of the week.

Steve Gibson (00:13:06):
So this one nominally has a Christmas theme. Yeah. Since it's about wrapping things we have uncle Sam in his flag theme stovepipe hat and, and he is apparently bring bringing to the table to be wrapped a box on, on one edge. It says us government and then proudly in the front, it says control of end to end encryption mm-hmm <affirmative>. And so that's gotta get wrapped. And so if we have a corporate media Schmo who is in the, in the talk bubble is asking uncle Sam, how would you like this wrapped? And then against the back wall, we see two rolls of wrapping paper, one titled anti, and the other protect the kids. <Laugh>

Leo Laporte (00:13:59):
It should be a third. Think of the women. That's a that I guess that's out of date now, but yeah.

Steve Gibson (00:14:04):
<Laugh> oh yeah. Geez. That's right. How are we gonna sell this sucker? Okay. so early last week, Google pushed and emerge and see Chrome update to resolve the 16th in the wild zero day being actively used in attacks against its users by this time every, and even in this case, I, which surprised me is like, oh, good. I don't have to ask for it. Everyone using Chrome on windows, Mac or Linux desktops should be at 96.0 46 64 0.110 that eliminates a high severity once again, use after free flaw, which really seemed to be the, like, <laugh>, they're, they're all over the place in Chrome. This is in Chrome's V8 JavaScript engine, which someone had found and was using. And as usual, because it's Google, that's all we know about it since Google has no motivation, no need or reason to share anything more.

Steve Gibson (00:15:17):
Like why would they, what the, what good's that gonna do? They wrote quote, Google is aware of reports that an exploit for CVE 20, 21 41 0 2 exists in the wild. And they thanked an anonymous security researcher for their report, which allowed them to fix this. And since we're wrapping up the year in this week's podcast, we got one more to hold our breath after this. We'll note that along with Chrome's extreme, popul comes a big bullseye painted on it since the bad guys get the most bang for their buck by attacking the market, leading web browser and thus all of its many users, Chrome had its first zero day flaw patched at the start of February, then two, March another two in April. One in may in June offered us a pair. July had only won September Cape. The Patch's very busy by closing five, zero days just here in this past September, October, or had one November snuck passed without any.

Steve Gibson (00:16:36):
And assuming that we're able to close out the year without any others, December will have brought us the 16th and final zero day. I know for 2021. And as I noted before, I don't think this means anything about Chrome, other than it's receiving more than its fair share of scrutiny. One of the, one of the best models I think this podcast has developed for security is this idea of porosity complex software security barriers are just, they're not secure. There's no other way to read. <Laugh> the last 17 years of this podcast's evidence. You know, we haven't figured out how to do that yet, or at least we haven't made it a priority, probably because it doesn't seem to really be such a big problem. You know, other are, people are being attacked, so, okay. But if our software security barriers are not absolutely secure, then what are they?

Steve Gibson (00:17:46):
You know, they resist penetration though imperfectly. And this is why I'm enamored of the idea that our barriers are porous. The more pressure, the bad guys place against the barrier, the more problems sneak through. And, you know, the closer we look at our software, the more problem ones we find, there was only one known problem with Log4j before researchers began steering at it closely for the first time ever, which revealed two additional or three, depending upon how you count new problems. And we'll be talking about those developments at the end of the podcast. You know, none of those was quite as bad as the first, but all needed fixing one, one got a 9.0, which is pretty high up there. And the same thing as we know happened with Microsoft's ill faded exchange server and windows printing throughout all of 2021 <laugh>.

Steve Gibson (00:18:46):
And this is why, of course there's money to be made from bug Boies. Companies will pay to learn of problems in their own software. Their own people should have found them or never created those problems in the first place. But like I said, we don't really seem to care enough to prevent them. So there's revenue available for anyone who enjoys looking at code. And speaking of looking at there is absolutely. And I know you'll agree with this Leo, no better way to improve one's own coding skill than by reading the work of other coders. Oh yeah, absolutely. You will. Anyone who hasn't will be stunned by how much you can learn by looking at the way other people have solved problems. It's I mean, you could spend half your life if you were like really into coding, reading other people's code and saying, Hey, I didn't know.

Steve Gibson (00:19:42):
You could do that. Yeah. That's that's really cool. Yeah. Yep, exactly. Right. Yep. Yeah, just happens. And I think that's for, for you and me, that's why we are so passionate about code. Is it, it is so big. It is so open ended. It is, you know, it can ask as much from you as you're willing to give it mm-hmm <affirmative> so mm-hmm <affirmative> anyway, as for browser vulnerabilities there's currently a lot to be annoyed with Microsoft about, but I just wanna say again, as we, cuz we talked about this over the last couple weeks, that that idea they had of backing off of chromium's extreme optimization in order to reduce the browser's attack surface at the minimal cost cost of what is probably unneeded performance gain. I really think that's quite compelling. I that's one that I hope Microsoft ends up proving and you know, back ports into the chromium build and maybe gives to, you know, Chrome users and other users of the chromium engine.

Steve Gibson (00:20:53):
I think that seems like a real win. Okay. Now <laugh> get a load of this one. I encountered it too. Firefox had a bit of an adventure last week when it began refusing to connect to And, and I don't recall now what had me going to I don't go often, but I encountered the error myself and it caused quite a stir online. Now, back in the early days of this podcast, we discussed the many problems surrounding web server certificate revocation. In fact, it got to be a hobby horse of mine. I created a RO just to demonstrate how poorly browsers were handling Oaked certificates by like putting one there and saying, look, your browser doesn't know it's been revoked. It's it's been revoked a long time. No one cares. So what happens is certificates expired only. And in the old days you could get five years now or three for some for that keeps getting whittled down as a means of still trying to deal with this problem of stale certificates that you know, might have gotten out of someone's control.

Steve Gibson (00:22:18):
So one of the solutions to the problem of erroneously trusting a revoked certificate was to have the web browser <affirmative> perform. That is the user's web browser perform an on the fly query of the certificate issuer issuers, OC S P server, where OCS P stands for online certificate status protocol. So in this way, a real time verification of the current validity of an identity certificate, which had just been received from a remote web server could be verified by the browser client. Now, the problem with this is that it takes time to do that. And back when OCS P was still young SB OCSP servers were often overloaded or sometimes UN unresponsive. And the last thing a browser wanted to do was to slow down its users. There's no faster way to lose your, your, your user base than to be a slow browser. So OCS P was often set kind of uselessly to fail open, meaning that only if an affirmative negative response came back, would the site be blocked either an, an affirmative positive response or no response at all, would let the user keep using that site.

Steve Gibson (00:23:53):
And the problem was that the bad guys who may have stolen someone else's valid certificate might arrange to block a negative OCS P response from getting back to its user, thus causing their browser to erroneously trust a fraudulent website. Okay. So the concept of stapling was introduced, which I just think is brilliant with stapling rather than asking the users web browser to go get an OCS attestation. As they're referred to the web server itself, the web server itself could periodically obtain a recently signed and timestamped assertion from its own certificate authority to accompany its the, the certificate it was providing to browsers. And it would, and this was the term staple that that new, fresh assurance to its own multiyear, lifelong identity certificate, the staple OCS P attestations would only be valid for a short time, perhaps just a few hours. So the web server would periodically reach out to renew this attestation, that it was stapling to all of its outgoing certificates.

Steve Gibson (00:25:18):
Well, before they would expire. And the final bit of perfection comes from the web servers certificate, having a flag known as OC S P must staple set this completes and locks down the system by affirmatively telling any browser that receives this certificate, that it is only to be considered valid. That is this certificate itself is only to be considered valid if it also is accompanied by a, a valid recently signed stapled OCSP certificate. So that measure protects the certificate holder from the theft of their certificate. If it were found, be stolen, it could be immediately revoked by its original issuer who would then refuse to issue any further valid OCSP certificates for stapling. And since by design all OCSP certificates expire quickly, the stolen certificate will, would quickly become useless because you couldn't because the certificate itself said this, this certificate must be accompanied by a valid stapled OCS P attestation.

Steve Gibson (00:26:43):
So what happened, huh? Last week with this wonderful system, having long been in place at Microsoft and everything going along swimmingly the now outdated SHA one signature was silently dropped from the certificate ID fields present in Microsoft's OCSP certificates. And apparently no one else has done this. Microsoft led the charge since the newer SHA 2 56 signature hash was still present. Safari and Chrome had no complaint and didn't even notice the change nor did their users, but somehow Firefox had never enabled their browser support for SHA 2 56 hashes in OCS P stapled certs. The code was in there and ready to go, but someone forgot to turn on <laugh>. So around the middle of last week, Firefox began refusing to allow any of its users to connect to most of Microsoft's various domains, including itself. The servers certs were flagged, as I said, as OCSP must staple, but from Firefox's vantage point, the stapled certs appeared to be unsigned and thus invalid.

Steve Gibson (00:28:11):
So Microsoft properly kind of refused to allow its users to go any further. Fortunately, the problem was quickly remedied, as I said, it was a matter of turning it on and pushing out and up to eight last Thursdays, December 16th, release of Firefox 95.0 0.1 fixed this immediately Mozilla's bug number 1 7 4 5 6 0 is titled fixed frequent Mozilla P K I X error OCS B response for cert missing error messages when trying to connect to various domains. So anyway, I just thought that was interesting. I, I know it popped up on my Firefox and I thought, oh, what do you know? There's a, him with OC S P I didn't dig any further. I didn't like look into turning it off or anything cuz you know, I've got Chrome right next to it. So I just used Chrome to do whatever I had to do and that, that worked and I figured they'd sort things out as then.

Steve Gibson (00:29:20):
They indeed did. But anyway, just sort of interesting little misfire from, you know, I mean, and this is, there is sort of a lesson here, right? Which is the, it is certainly possible to tighten the screws down so much so that, you know, absolutely nothing will get past, but boy, if you do that, you really need to make sure that all of the links in the chain are working correctly. You know, I I'm put in mind of the H S T S the, the strict the, the HTTP strict transport security, where that's the hitter that you're able to add to your server that tells the, the browser, you know, you got a secure connection now and here's an expiration all on how long we want you to remember that you should only get secure connections from this website, you know, and best practice is that you set that to infinity essentially.

Steve Gibson (00:30:32):
But if you do that, <laugh>, you better absolutely know that you're gonna be able to have, you know, TLS certificates for their end of, of time. Otherwise users are just not gonna be again, able to get to your site. So, yeah, again, neat that we have these technologies that allow us to tighten things down so much, but you know, you need to make sure they don't go wrong. Okay. Since we talked about Firefox and Microsoft here, here, as I mentioned at the top was another one of those, what could possibly go wrong features in windows, which to their credit Mozilla has dealt with. It's known that as win? Well, the, the feature is known as windows, cloud clipboard. It was added to 10 way back in September of 2018 back with win tens 1809 release. And it is what, it sounds like a feature that allows users to sync their local PCs, clipboard histories to their Microsoft accounts.

Steve Gibson (00:31:43):
Fortunately, <laugh> what seems like an abuse prone feature is disabled by default, but, and yeah, and I mean that seriously you'll, you'll see, but when enabled it allows windows users to access the cloud clipboard by pressing the windows key shortcut. So instead of like, you know, control V for local paste, you do windows V for galactic <laugh> cloud paste. And this grants users access to clipboard data from all their other devices. Again, as I said, what could possible they go wrong? And more than that, the service also maintains a clipboard history, allowing users to go through past items they copied or, or cut and then rep paste the same data into new contexts, whatever that might be. So what recently came to light and what Firefox fixed in last month's Firefox 94, remember just last week was 95.0 0.1 to, to fix this mess.

Steve Gibson (00:32:59):
So last month was nine was Firefox 94. What happened was they realized that usernames and passwords copied from the browser's password section were being recorded on demand as with everything else into this shared cloud clipboard repository with history. So is that a bug or is that a feature <laugh> either way Mozilla decided it was not good, you know, and you know, and there's a work around, right. If you really want that, then copy it to notepad and then copy it from notepad to the cloud. But not directly. My Mozilla says, no, we don't want people to, to like when, when you, when you're just copying it for some reason from Mozilla that should not be recorded in your permanent clipboard history shared by all your PCs. So in a blog post last Wednesday, Mozilla said they're with release 94, they've modified Firefox. So that usernames and passwords copied from the browsers password section, you get to that with about cold and logins in the URL will no longer be stored in the windows cloud clipboard, but instead will be stored on locally.

Steve Gibson (00:34:22):
You know, in a separate clipboard section, Mozilla said it considered this behavior. That is the no normal behavior, dangerous Uhhuh. Since any threat actor with access to a sync device could simply press the windows V keyboard combination and access any clipboard data from a user's past activity on other devices. You know, now I suppose that as long as a windows power user understands the inherent danger, this clipboard cloud sharing could come in handy, but Mozilla felt that this was especially dangerous in the case of the export of the browsers, stored user names and passwords since no trails or local logs of any kind or, or retained. So you wouldn't even see that this had happened. Mozilla also said that they had added even more protection to their private browsing windows, so that nothing copied from a, from a fire F private window would be synced to the windows cloud clipboard, not just an exclusion for user credentials, but everything, and for what it's worth be warned, no chromium based browsers include this protection and user names and passwords from Chrome were synced to Microsoft cloud servers when this feature was tested. So users should be aware of who might access their passwords if they use the cloud clipboard. You know, if it's enabled and are using any non Firefox browser on windows. But as I said, even that is still some weak protection. It's not that difficult to get around it if you wanted to. So, wow. You know, this, the idea of synchronizing your clipboard to the cloud real has the feeling Leo like a, you know, a feature in, in desperate search of need. <Laugh>,

Leo Laporte (00:36:24):
You know, apple has a sort of a similar thing, which is, if you copy something onto the clipboard on a Mac, it will then go to your phone, but it doesn't go to the cloud. It just goes to your phone, the, yeah. Why put your clipboard in the cloud? That seems like a, it does, it's a selling

Steve Gibson (00:36:41):
Point and not, and not just the last thing you pasted, but like the whole thing, the history.

Leo Laporte (00:36:46):
Yeah. That's, that's, you know, that's passwords, that's everything. Yeah. That's not a good idea. Yeah. Obviously just the name of it. 

Steve Gibson (00:36:53):
I'm gonna take a sip and I we're at, at a good point because the latter half of this is, is gonna be a big bird. So <laugh>, I think that would be

Leo Laporte (00:37:03):
Prepared for the big bird or bird, whatever it is. And we were Berg. It's a bird, it's a bird, it's a plane. It's Superman. All right. Coming up. But right now I want talk about Stripe. And I think probably you all know Stripe. You certainly use Stripe. Anytime you're doing payments online. You're almost certainly you're using Stripe. We use Stripe as a business, when you join club TWI, that's how your payments go through Stripe stripes is the best known leader of payments platforms. If you're a business that is moving with the times, if it were, you certainly should know about Stripe with Stripe businesses can optimize their payments infrastructure easily. They could simplify their expansion plans. They can create new revenue streams, all to help 'em grow and initiate change rather than, you know, reacting to it. Bus big businesses. You Stripe, the reason I think you probably experienced it.

Leo Laporte (00:38:00):
If you've used Shopify, you've used Stripe, Twilio uses it. Postmates uses Stripe all to power their global payments. And when I say global, I mean, it, that was one of the things we needed of course, was a, a global payment platform because we certainly want people to join club TWI from all over the world. Stripe let's us accept 135 plus different current and payment methods. That's really nice. The other thing that's big, and I didn't know anything about this until I, you know, started, started doing it. Authorization rates can cost you Stripe helped Postmates increase their authorization rates, meaning they were able to stop more fraudulent transactions from processing. Those fraudulent transac actions will kill you. And yet you don't, you know, you don't want false positives and you don't want false negatives. You, you don't wanna block a legitimate transaction either. And, and Stripe helps you do both protects you against fraud, but doesn't stop the legitimate transactions.

Leo Laporte (00:39:00):
And for Postmates, get this. I mean, this is how big a deal. This is. That meant an additional 70 million in revenue over a 12 month period. That's what this means. When you start, you know, using stripes scale stripes, easy to use too, by the way, once integrated their single platform, world class docs, let businesses easily experiment do AB tests, things like that to scale and, and grow revenue. And don't worry about scale. Speaking of scale, Stripe processes, billions of dollars a year for every size of business from Pree startups to fortune 500 company, these 99.99, 9% five nine uptime on the API. They do more than a quarter of a billion API requests a day. So they are prepared to handle your business. And I love it because they're always releasing new stuff. Hundreds of features and improvements every year to stay ahead of industry shifts.

Leo Laporte (00:39:56):
We launched club TWI this year, we chose Stripe for our payment platform. We love it. It's seamless and accepting payments and issuing refunds should that ever have to happen. We've had a few and it's just easy. It's easy for us. And I think it's reassuring for our club members too. We just couldn't be happier. We're able to focus on the business of producing high quality podcast, our business. We let Stripe handle the business of payments and money movement. That's their business. I love it also that as a customer, with a click of the mouse, you can direct a fraction of your revenue to help scale emerging carbon removal technologies. They call it Stripe climate, check it out. It's one way Stripe is investing in a, a better planet for us all. And we're glad to participate in that too. So whether you're an online or in person retailer, if you're a software platform, a marketplace, a subscriptions business like ours, go to and learn more about how Stripe can support your business today. We love it. Couldn't be more happy to more and get started today. We thank you Stripe for helping the club get on its feet. And we thank you for supporting security now with he now fully hydrated, Steve Gibson <laugh>

Steve Gibson (00:41:10):
So, so turns out there is a, did not a huge weakness, but sort of an interesting problem which has existed in all cellular networks since two G a paper was just published under the title. Don't hand it over vulnerabilities in the handover procedure of cellular communications. Now, handover is the official name for what we normally call cellular inter tower handoff. It's the process by which, as we know a phone call or a data session gets transferred from one cell site base station to another, without losing any connectivity during the transmission. Of course, it's the, was the key innovation of the whole cellular radio system and, and a brilliant invention. And of course it's crucial to establishing and maintaining cellular communications while the user's on the move so that you, you know, you, you are driving along and everything seems fine yet your connection is being handed off from one cell tower along the side of the freeway to the next as you drive.

Steve Gibson (00:42:32):
Okay. So here's how this works in a little more detail, which pertains to what has been the ex exploit that's been worked out the user's equipment. Typically a handset sends its received signal strength. That is the signal strength its receiving from multiple nearby towers to the network so that the network can determine whether a handoff is necessary. And if so the network facility that that network facilitates a switch between base stations when a more suitable target station is available or is soon to be available. Although the signal readings are cryptographically protected, it turns out that the content of these reports is not verified. And this lack of verification allows an attacker to spoof these reports and to thereby force a device, to move to a cell site of their choosing typically operated by an attacker. So, and this attacker arises because as I said, these unverifiable signal, strength reports are undetectable.

Steve Gibson (00:43:47):
They're they're, they're part of the system. It was just, you know, in this long established protocol this aspect was never really properly designed to be spoof proof and has indeed been proven now not to be, it doesn't create a huge new problem, but it does mean that the effectiveness of fake cell stations, you know, often called stingrays can now be in increased. It used to be that a stingray needed to be located in close proximity to its target so that it would have the stronger signal and that the normal signal strength juggling process would cause the, the targeted user to switch their traffic over to the stingray. But this new research dramatically reduces this requirement. So now any user within range can have their traffic rerouted through a man in the middle us what these stingrays are typically used for. It can be used as a denial of service.

Steve Gibson (00:44:56):
If, if there's some benefit for like disconnecting someone from the cell system, you can essentially commande their phone by switching it to a, to a, to a stingray that doesn't proxy E for the, the regular network as is normally done in their, in the researcher's experimental setup, they found that all devices they tested a one plus six, an apple iPhone five that's an oldie Samsung S 10 5g, a WowWay pro P 40 5g and others, every, every one of them was susceptible to both a denial of service, meaning just, you know, cutting you off from the network. And man in the middle attacks, they presented their findings at the annual computer security applications conference, AC E SAC earlier this month. So again, it's not like any new, big problem crack in cell coverage, but have literally everything from two G all the way up through five there is no, and, and of course, this is never gonna change now, right?

Steve Gibson (00:46:10):
You, you can't change this protocol. It's too late to all of the infrastructures deployed. All of the devices exist. All you can do is, you know, know about it and, you know, maybe an an, you know, certainly to the degree that now we're, we're in, in the case of data, we're encrypting our traffic before it goes over L connection, thanks to HTTPS. You know, there's not much that a bad guy could do. We already have. We already know that HTTPS itself is providing strong protection against any man in the middle attacks. You know, a denial of service would be a vulnerability that would be effective, although, you know, potentially less devastating, but it might, you know, be used cleverly to get someone to move from where they are trying to, you know, like, can you hear me now? Can you hear me now?

Steve Gibson (00:47:02):
Who knows? But anyway the technology exists it's public. And so given the way things are these days, we could expect it to be incorporated into next gen stingray systems before long. <Laugh> another thing that's not gonna change, unfortunately is protection against this next problem, which is cross wifi to Bluetooth leakage, a team of German and Italian researchers have significantly updated their previous research couple years ago. They first like, like raised the alarm. Actually it was at a black hat conference several summers ago and nothing, no really took that much notice of it. The problem being, or the reason being probably is that it is not easy to fix. So they updated their research regarding a class of what they call coexistence attacks against wifi and Bluetooth. Their research paper is titled attacks on wireless coexistence, exploiting cross technology performance features for intership privilege, escalation and the abstract of their paper explains what they've done.

Steve Gibson (00:48:24):
They, they wrote modern mobile devices feature multiple wireless technology, such as Bluetooth, wifi, and LTE, you know, cellular. They said each of them is implemented with a separate wireless chip, sometimes packaged as combo chips. However, these chips share components and resources such as the same antenna, wireless spectrum, wireless coexistence interfaces enable them to schedule packets without collisions, despite sharing these resources, which is essential to maximizing networking performance. Today's hardwired, coexistent interfaces are clear security boundaries and separation between chips and chip components. They said this paper shows practical coexistence attacks on Broadcom, Cypress and Silicon labs chips deployed in billions of devices. For example, we demonstrate, they said that a Bluetooth chip can directly extract network passwords and manipulate meaning wifi and manipulate traffic on a wifi chip coexistence attacks enable a novel type of lateral privilege. Escalation across chip boundaries. We responsibly disclosed the vulnerabilities to the vendors yet only partial fixes were released for existing hardware since wireless chips would need to be redesigned from the ground up to the presented attacks on coexistence.

Steve Gibson (00:50:15):
In other words <laugh> don't hold your breath. Okay. So to put some additional context to this, I wanna share the top of their papers introduction, which I think everyone will find interesting. And unfortunately, somewhat worrisome. They explain wireless communication is enabled by systems on a chip SOC implementing technology, such as wifi, Bluetooth, LTE, and 5g. While while SOCs are constantly optimized towards energy efficiency, high throughput, and low latency communication, their security has not always been prioritized. New exploits are published continuously firmware patching to mitigate flaws require strong collabo between vendors and manufacturers leading to asynchronous, incomplete and slow patch cycles. In addition, firmware patch, ding can provide attackers with systems on a chip vulnerabilities months before their public disclosure, you know, not to speak a of their actual installation into their user's phones. If that ever happens, they said mobile device vendors account for potentially insecure wireless SOCs by isolating them from the mobile operating system and hardening the OS against escalation strategies.

Steve Gibson (00:51:52):
For example, on Android, the Bluetooth demon residing on top of OS, Dr. Of OS drivers runs with limited privileges is sandboxed and is currently being reimplemented in memory, safe language. As a result, recent wireless exploit chains targeting the mobile OS instead of the system on a chip are rather complex and need to find a bypass for each mitigation. They said, we provide empirical EV evidence that coexistence IE, the coordination of cross technology, wireless transmissions is an unexplored attack surface. Instead of escalating directly into the mobile OS wireless chips can escalate their privileges into other chips by exploiting the same mechanism they use to arbitrate their access to the resources they share. For example, the transmitting antenna and the wireless medium, this new model of wireless system exploitation is comparable to well known threats that occur when multiple reds or users are able to share resources like processors or memory.

Steve Gibson (00:53:17):
This paper demonstrates lateral privilege escalations from a Bluetooth chip to code execution on a wifi chip, the wifi chip encrypts network traffic, and holds the current wifi credentials thereby providing the attacker with further information. Moreover, an attacker can execute code on a wifi chip, even if it is not connected a wireless network in the opposite direction. We observe Bluetooth packet types from a wifi chip. This allows determining keystroke timings on Bluetooth keyboards, which can allow reconstructing texts and on the keyboard. And we've talked about keyboard timing attacks you years ago, and they're real and surprisingly effective when you put enough, you know, AI behind the timing and they finish since wireless chips communicate directly through hardwired coexistence interfaces. The OS drivers cannot filter any events to prevent novel attack despite reporting the first security issues on these interfaces. More than two years ago, the intership interfaces remain vulnerable to most of our attacks. They said, for instance, Bluetooth wifi code execution is still possible on iOS 14.7 and Android 11 wireless coexistence is indispensable for high performance wireless transmissions on any modern device. We experimentally confirm that these interfaces exist and are vulnerable today. So maybe in 2022, we'll be talking a little bit about the mischief that has been leveraged taking advantage of Interra leakage. Yeah. Unfortunately

Leo Laporte (00:55:24):
I think the mischief will be MIS you know, kind of mysterious because it's gonna be things like those DC stingrays that are gonna get better and nobody's gonna know anything about it, right? Yep. Right. It's gonna be kind of transparent. Yep.

Steve Gibson (00:55:36):
Yeah. Yep. Okay. So I said a brief sci-fi reminder and that's for the matrix resurrection. Yeah.

Leo Laporte (00:55:49):
I hope it's good. Cause one was great. Two and three. Weren't so

Steve Gibson (00:55:53):
Great. You know what I'm saying? I, in complete agreement, I'm in complete agreement it starts airing at some a if like 3:00 AM or something in the morning tomorrow. It's co rereleasing because it's Warner brothers, it's COEs in the theaters and on HBO max. And you know, despite the fact that IMDB currently PS it at a 6.8, which falls beneath my normal IMDB threshold of 7.0, you know, I find that that's sort of about the, the level of pain, you know, I'm quite certain that Lori and I having received, as I mentioned, our vaccine boosters at 9:00 AM tomorrow morning will be snuggled up on our couch. You won't be able to move, so you'll be forced to watch the matrix. Yeah. But, and, and maybe we ought be shot into, it's like taking the red pill. You, you know, it's a, that way we, we could put the popcorn in between us.

Steve Gibson (00:56:48):
Yeah. Yeah. One hand can move. The other one will just lie limped. Yep. And Leo, I'm not expecting much. And I don't expect to be wowed or surprised, you know, Mo movies don't seem to be that much anymore. No. You know, there, there are a lot of special effects and I liked June. We liked you liked June. Right. That was good. That's true. That is. But at, yeah, that, that that's, but it wasn't like, oh, you know, when have we had that? No, it's been a while. It's mostly long, long form TV shows that really these days are the, are the things we get excited about. I don't know. I'll be interested. Oh, I, I, I can't wait. I just lost two and a half hours. Yeah. Goodbye. Yeah. <Laugh> midnight alley. Is that what it's called? It looks good too. Anyway, there's some good movies coming out this week.

Steve Gibson (00:57:33):
Thank goodness. And are they available without, yes. Going to a theater cause I ain't going to no theaters. No no. So as planned last week I brought up GRCs own instance of GitLab. It's a big lumbering engine X and Rubion rails conglomeration that also drags in all manner of other accoutrements and watching a it go in it it's really so clear why security has become such a problem for our industry. I mean, you push a few buttons and then you stand back while screen after screen scrolls by, you know, as module after module, I mean, hundreds and a hundred of the little buggers download, install themselves and set up shop, you know, just so just stand back and hold your breath. What are they all doing? No one knows you know, this one needs that one and that one needs another one.

Steve Gibson (00:58:41):
And before, you know, it, 150 million bites of your mass storage has been commande by the forces of darkness. Processes are now running that are presumably all supposed to be running, you know, and you know, what choice do you have? It's free you know, do you want it or not? <Laugh> you know, and what are you gonna do right at your self? And actually there was a comment over on GRCs spin, news group, urging me to please not spin off and write a bug tracking system in assembly language, not to worry that won't be happening ever. You know, so I put this thing because I don't trust it. You know, trust has to be earned. I put this thing on its own physical free BSD server and sequestered its network behind a physical firewall with its own dedicated port. The only thing it, any access to is the outside world.

Steve Gibson (00:59:43):
It can see out, but it can't look around. And all that said, GitLab really is a very nice piece of work. I don't feel like I know it fully yet or really trust it, but now that we have it, I think it makes sense to you. It, our, as I mentioned before, our threaded conversation, textual only news groups are really perfect for what they are. They're fast and simple for casual use, and they allow us to move with great speed when we're all moving forward as a group. And they've served us well until now, but they're not ideal when we get stuck on a problem. We already have the web forums, but those are really targeted at our future spin right end users. That's where I want, you know, that'll be the official GRC support side. And GitLab is clearly not aimed at the uninitiated end.

Steve Gibson (01:00:42):
You know, there, there's a lot of, you know, where's the button I'm supposed to push at, certainly at the start, but I GRC and spin, right. Have been blessed with a bunch of really amazing and terrific testers who have large arrays of hardware at their disposal and who have shown an enduring interest and willingness in, in actively participating in spin rights development testing. So I think that this GI lab instance will be there for them to use if they choose to use it. Many testers are understandably much less involved in this entire process and that's fine. I, I, I, you know, we need them too. They, they tend to swing by every week or two to give the latest release a try. And they generally just post that. It worked again as usual as they all do. And you know, I don't wanna mess with, you know, that, you know, or, or given them any kind of a burden.

Steve Gibson (01:01:44):
So we'll still have the news groups for quick, you know, just drive by posting of go, no go notes of SP success of spin, right. Test releases. But I think that GRCs GitLab instance will be a very valuable resource for those who are interested in working with me when sticky problems arise. Oh, and I did wanna mention one thing just because I hadn't, and it changed my life a few months ago. Last week I posted a shout out to the free service whose performance has stunned me. What I tweeted was a shout out to at stop forum spam. I said GRCs forums were drowning in forum spam because forum spamers are people typically in the east block who create temporary throw away Gmail accounts and manually bypass all capture challenges. But after adding stop forum spam, not a single fake registration. So, you know, it, it really works. I looked high and low for some solution and turns out it was built in to Zen four. It already had support for it, but for some reason I hadn't turned it on in the beginning. So the moment I did this problem disappeared. Do you get a lot of false

Leo Laporte (01:03:17):
Positives though? Like people who Aren

Steve Gibson (01:03:20):
Spammers one so far. Okay. One in one in six months must be good. Yeah. Very impressed by, by that. And, you know, and, and when it happens, you know, they, they use the contact form to say, Hey, what's up. And I, and I say, sorry about that. And I, you know, I, I, I approve them. So what I'm hoping is that I can find this for GitLab because, you know, I just don't want, it just bugs me, you know, sort of just from a, you know, get off my lawn <laugh> standpoint. I just don't want a bunch of crap, you know, in my forums or in, you know, burdening my GitLab instant, that just it's annoying. And eventually they're gonna be posting crap and they, they ultimately get around to doing that, which is annoying too. So it turns out that there's an old project on GitHub from seven years ago.

Steve Gibson (01:04:15):
It it's a stop form. Spam has a very simple you know, web AP. So it's simple to, for some code to reach out and query the IP, the email address and the username to, to see if it's on the blacklist. And boy does it work? So you know, maybe there will, there'll be some way an easy way to get this added, to get lab. That would be, that would be my dream. But for what it's worth from forum spam, I, I did some looking around when I was trying to find a good solution before it occurred to me. Oh, just turn, turn it on. It's a real, it's, it's a big problem for a lot of people, so yeah. I just

Leo Laporte (01:04:59):
Manually approve

Steve Gibson (01:05:00):
Everybody. I, yes. And,

Leo Laporte (01:05:04):
And I can, you can usually tell us Bamer they, it's funny. They don't try to, I shouldn't say this out loud, get into our forums very often, but they try to get in RMA on instance, usually, you know, about nine to one

Steve Gibson (01:05:17):
Requests to join are from spamers. Yes. I know. In fact, when I, when I whittled them down, we lost three quarters of what looked like people who like members on GRCs forums. It was, was crazy. Yeah. It was just crap. I mustn't. So our forums mustn't yet be on the list of attackable forums. I won't tell anybody. Yeah. Stay off mention it can mm-hmm what, what forum? No, we don't have a forum. No. So as for spin, right? I think a pattern is beginning to emerge. I mentioned last week that I'd purchased some stuff on eBay, all of that new all, actually three different motherboards have come in. What I'm seeing is that all of my, all of my new spin right code generally works perfectly on all newer hardware, which is like behaving correctly. Pretty much anything I do just works right off the bat there, which is why the asked majority of people who are in, in the spin news group, just say, yeah you know, I've never had a problem.

Steve Gibson (01:06:25):
I don't know. I don't know what's up with you other guys, but everything Steve does just works. But it's on older hardware, typically very old hardware where, what I think early and probably slightly incompatible operation was originally being hidden behind those older systems biases. But now that spin right is bypassing the bios. We are encountering a few gotchas, which is what I'm now in the process of addressing there. Like, you know, there, I, I got one, it was an Asus M four like M four, a 78 motherboard or something like from, from the last bios was 2010, so 11 years old. And when I got it and ran spin, right, the benchmark was like stuttering. And I immediately noticed that the progress bar wasn't moving smoothly for 7.2, five seconds, as it's supposed to, well, it's being moved by the clock tick, which occurs at 18.2 hurts.

Steve Gibson (01:07:41):
And it's the highest priority interrupt in any PC is that timer, cuz you don't wanna lose track of time. And it's very brief it just increments a counter and then, and then returns control. My point is that progress bar can't hesitate. I mean it can't it's, you know, it's like, so something is very wrong somewhere if it's only advancing as the drives transfer completes, which is on, on, on an old, I had a, a 300 gig max store drive IDE and it took a substantial amount of time to do one of these big block transfers, a 16 megabyte transfer. And what I was noticing was the, the progress bar was jumping ahead by a big chunk every time a transfer finished as if somehow like the clock interrupt was not happening. It's like, what? So anyway, I, I that's my project for tonight. Is I gonna, you know, roll?

Steve Gibson (01:08:48):
I'm gonna rub my hands together. Oh, I forgot to mention that when I, so it was doing that, but not crashing where it was crash on the two other systems that are, that the two people who have these were trying were, were testing, spin right on. But it also had an old bios when I updated to the latest bios. Now it crashes. So like what <laugh> anyway. Why, so why should I'm not using the bios? So why should changing the bios have any effect on the hardware? I don't know. Anyway I, these are the problems I live for and, and I've got three mother boards that are, that are causing these problems at the moment. They'll probably be fixed by the time everyone hears from me again in two weeks. Oh God, we have, we have vacation next week. Anyway, that's my fun, Leo. I'm gonna take a sip of water and then we're gonna talk about the, the lack of fun that everybody in involved with remediating this Log4j nightmare. Oh my goodness is having the, you know, the nightmare before Christmas. Oh.

Leo Laporte (01:09:57):
And then, and the gift that keeps on giving too

Steve Gibson (01:10:00):
A and will, will be continuing to give. Yeah.

Leo Laporte (01:10:05):
Let's talk about something happier user way. Our sponsor user is making the web accessible for more than 60 million Americans with disabilities. I don't know how many million or billions it is worldwide. Probably hundreds of millions worldwide though, in the United States anyway, and I'm happy to say it. There's something called the ADA, the Americans with disabilities act that requires that public entities be accessible. And the Supreme court has ruled a website is all websites are public entities. They need to be accessible. That means it needs to work with a screen reader. That means your visitors, whatever their disability should be able to use that site just as I can or Steve can. And, and that's what user way does, does I, I just think this is such a good service. Every website has to be accessible. It's the right thing to do.

Leo Laporte (01:11:02):
It's also the law user way has an incredible AI powered solution that does it for you. With one line of JavaScript, it tirelessly enforces the hundreds of web content, accessibility guidelines. They call it woo C and it can do more than really a whole team of developers, which is a relief. Because if you run a website and you know, you have to make it accessible, you might be thinking as I did that's gonna cost a lot of money. I'm gonna have to hire a whole bunch of people. This is gonna be complicated. User ways, AI and machine learning solutions, power accessibility for over a million websites, big sites. Some of the biggest in the world Disney uses it. UNICEF uses it. Walmart Coca-Cola eBay, FedEx, all use user way to make their sites legal and accessible. And now user way is making these best in class enterprise level tools available to small and medium sized businesses at a price we small businesses can afford.

Leo Laporte (01:12:00):
It's really affordable. And it, and, and the, you know, you will be glad to know as you get big user way scales along right next to you. If they can handle Disney, I think they can probably handle any site and accessible come client website. Isn't just the right thing to do. It makes business sense. Achilles heel for so many websites are shopping carts. You don't wanna, you, you want people to buy stuff from you. You don't wanna leave 60 million Americans out registration forms. You know what I hear all the time from our blind listeners, nav menus. I mean, I think excited users have a hard time figuring out what that three line hamburger menu means. Well, imagine if you're using a screen reader, what does that mean? User way? Fixes it all for years, user way has been on the cutting edge, creating innovative accessibility technologies that push the envelope of what's possible with AI machine learning, computer vision.

Leo Laporte (01:12:53):
I'll tell you, I'll give you an example. It uses computer vision to generate the alt texts. Every image in your site can have an associated text tag that makes it accessible to screen readers. Most people don't do it. And the idea of going in and annotating every image on your site might be daunting. One line of JavaScript. It does it. It's done. They automatically fix violations at the code level. They auto generate the alt tags with computer vision. They remediate complex nav menus. They make sure popups are accessible. They fix vague link violations, broken links. They make sure that the accessibility layer remember the, the browser has a regular layer, but also an access layer. That's where these changes occur. They make sure the accessibility layer uses web accessible colors. So people with low vision or difficult to seeing or whatever can, can see it without changing your brand, which is nice.

Leo Laporte (01:13:49):
You get a detailed report of all the violations that were fixed in your website. There's a really nice interactive mode that lets you go through those Al tags. Add to them if you want modify 'em, if you need whether you're using WordPress or Shopify or wicks, it's so easy to install. In many cases, there's just a, a plugin that will work and do it for you. AEM site core SharePoint works with that. It works with my hand coded site, cuz it's just a line of JavaScript pulls in the, the, the scripts it needs and, and, and runs automatically let user way help your business meet its compliance goals, improve the experience for all your users. And incidentally, at least do this for me, go to user and check out the scanning tool. Cause you can scan your site and see whether it's compliant and see what the problems are. At least you owe it to yourself. You owe it to your users to do that, right? Ask Susan Bennett, the former voice of Siri. What she thinks of user way watch

Speaker 3 (01:14:43):
User way is trusted by more than 1 million websites and 60 million users with disabilities visit you user to learn how one line of code can make your website accessible.

Leo Laporte (01:14:57):
Absolutely it can user, make your website accessible ADA compliant. And right now, if you go to user 30% off user ways, AI power at accessibility solution showcase your brand's commitment to millions of people with disabilities. It's the right thing to do. It's good business too, user way, making the internet accessible for everyone user user Okay. Miss Syria. And I are gonna fade to the background because we're ready to hear about more troubles with Log4j.

Steve Gibson (01:15:39):
Well, so we all knew that nothing as ubiquitous and pernicious as Log4j was gonna be wrapped up in a week. And indeed there's a lot more to talk about this week. And I guess if last week's podcast served to introduce the problem this week, we're gonna gain some perspective on its consequences. As we know Log4j earned the, I don't know if we've ever seen it before CVSs score of 10.0, but you

Leo Laporte (01:16:09):
Don't get much worse than this. I think that's fair to

Steve Gibson (01:16:11):
Say. And Leo, I I'm put in mind of that old joke about the volume controls of massive stereo amplifiers, which, because they have so much power need to have their volume controls range from zero to 11. Yeah. If there was ever a case for a CVSs score of 11 to 10, yeah. Long for Jay is as good a case as any. Okay. So since last week much has happened on the remediation front while the audio was still reverberating from last week's podcast, recording the Apache software foundation published an updated fix for the, for J vulnerability after it was discovered that the previous patch, the one that, you know, from the previous Thursday was incomplete in certain non default configurations. And so it was, it was technically the second but related vulnerability. So, you know, it was given its own CVE 20 21, 40 5,046. And because it didn't induce nearly as much hyperventilation among security experts, it was initially he rated at a CVSs of 3.7, which, you know, you don't even get outta bed for that.

Steve Gibson (01:17:36):
Because it was initially believed to only have dos, you know, as in you could crash something denial of service consequences. But apparently the bad guys couldn't do any worse than that, but that unexciting score was soon amended to a brightly glowing 9.0. Once it became clear that an attacker could send specially crafted strings, which could lead to information leakage and remote code execution in some environments and local execution in all environments Whoopie. So that was important. So the second discovery affected all versions of Log4j all the way from 2.0 beta nine, which is where the whole Log4j two began up through two point point 12.1 and two point 13 through two point 15.0 remain. And remember that 2.15 was the big fix that the Log4j project maintainers had just shipped the week before that was obsolete now.

Steve Gibson (01:18:48):
So we had 2.6 and this J N D I lookup was essentially disabled by default as a consequence. That what, by the, you know, after all the headache with 2.15 and saying, well, you know, we're gonna filter this and gonna try to eliminate that. They, they just decided no, J N D I, this is just too big a mess. Nobody really needs it in loggings. And if you do okay, then as, as we mentioned last week, you, you could turn on anyway, it's, it is much more firmly disabled now in 2.16. And that's for Java eight. If for some reason you are on Java seven, then look for 2.1, 2.2, as soon as it becomes available. That's the one you that you'll need for Java versions, seven, you know, Java major version seven the Apache software foundations, Ralph goers said, he said, quote, dealing with CVE 20, 21 44, 2 28.

Steve Gibson (01:19:59):
That was the original one has shown that J N D I has significant <laugh>. I mean, it's hard to even say that little illustrate face, significant security issues. Yeah, really, while we have mitigated what we are aware of, it would be safer for users to completely disable it by default, especially since the large majority are unlikely to be using it. But until now course, even though it's always been true that the large majority are unlikely, unlikely to be using it. We had it turned on, okay. Lesson learned. And since last week, the lineup of well known affected organizations has of course only grown. Here we are on Tuesday last week, the list in alphabetical order of the biggies was Akamai, Amazon, Apache apparel, Atlassian Broadcom, Cisco Cloudera, ConnectWise, Debian Docker for net Google IBM Intel Juniper networks, Microsoft Okta, red hat, solar wind, Sonic wall Splunk Ubuntu, VMware vScaler and Zoho.

Steve Gibson (01:21:14):
Holy moly, a through Z baby. Oh, and, and we'll be looking at why in a minute here also as of last week, 10 different attacking groups been identified and roughly 44% of corporate networks globally have been under attack. The us CSA, you know, the awkwardly named cybersecurity and infrastructure security agencies, C I S a has given all federal agencies, the deadline of Des 24th. That's Friday to this Friday to fully incorporate all patches for the vulnerability. And I'm gonna explain why that can't possibly happen. You know, no one gets to have Christmas until every agency's Log4j vulnerabilities have been fully remediated. The only way to do that is to pull the plot because the fixes are not available. And Google is estimating. We got years before that's gonna happen. And I'll explain why in a minute, Soho, senior threat researcher, Sean Gallagher said that adversaries are likely grabbing much access to whatever they can get right now with the view to monetize and or capitalize on it.

Steve Gibson (01:22:38):
Later on, there's a lull before the storm. He's saying in terms of more nefarious activity from the Log4Shell or Log4j vulnerability, the most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate, exposed, and potentially compromised systems. This vulnerability can be everywhere. He said, okay. So that took us from 2.15 to 2.16, but wait, there's more later in the week, researchers discovered an entirely new log for Jay attack vector. We knew that was gonna happen. We talked about it, right? I mean, there are other ways to get there, which enables adversaries to exploit servers locally by using a Java web socket connection. Matthew Warner, the chief technology officer for blue Myra said, and get low to this one, quote, this newly discovered attack vector means that anyone with a vulnerable log for Jay version on their machine or local private network can browse a website and then have this vulnerable that triggered.

Leo Laporte (01:24:07):
Now of course you have to be logging using Log4j to log that traffic. I mean, it won't just, it can't just be sitting there not running and be affected. You have to, it has

Steve Gibson (01:24:16):
To be running right. Well if, if, if Log4j dot jar is in your process tree somewhere. Yeah. Then your browser can be the way trigger it. Yeah. To

Leo Laporte (01:24:33):
Get to it. Yeah, I

Steve Gibson (01:24:33):
Understand. Yeah. Yes. Right. So it won't launch launch it most, most

Leo Laporte (01:24:37):
Harm users. Aren't running Log4j.

Steve Gibson (01:24:40):
No, no, no. I mean, it can be any of the, let's see, Google counted it at something like 30 full or thousand different Java things. So any of those being used, brought Log4j along with it. Right, right.

Leo Laporte (01:24:56):
Yes. But I think mostly those are gonna be associated with some, I mean, you don't log, well, maybe you do. I don't know you. I mean, there's

Steve Gibson (01:25:04):
Have you looked like at some of

Leo Laporte (01:25:05):
Your directory? Yeah. Yeah. You know, I'm logging, but I'm not using, I don't think apple or Microsoft uses Log4j to log the console log. Maybe, I mean,

Steve Gibson (01:25:16):
Oh no, no, no. It it's the I don't know. I we'll have plan. We'll have plan to talk.

Leo Laporte (01:25:26):
I that's the real question. Yeah. I mean, is, is how much should people who are not knowingly running servers worry about this. Might they have Log4j I mean, I run Minecraft servers, so I know I probably have Log4j running, but <laugh> but you think, but if you're running, but that's, but I know cuz I'm running a server, most people are not running servers in their out of their house. I'm hoping that most people would not be exposed to this, but I might be wrong. I'm just curious. I might be wrong.

Steve Gibson (01:25:56):
So, so the, the, so the it's not only for servers, servers were the initial vulnerability mm-hmm <affirmative> because they listen, mm-hmm <affirmative> for bad guys on the outside. Mm-Hmm <affirmative> any, you know, if I've got some I don't know if it's Java based. I think it is. It it's a, it's a it's a raid Intel's raid monitoring package is, is, is Java based. So it could be cross-platform. And so, you know, they brought it along as part of, you know, part of the, the easy way of implementing things. And

Leo Laporte (01:26:36):
It's, it's normal for software to have run logs. Cause they keep, keep track of errors and things like that. Every

Steve Gibson (01:26:43):
System is, and yes, and I was gonna say, if you've ever like dug deep into some like directories under your own user tree and windows, there's like logs. It's like, what is all this crap? It is like, you know, but it's,

Leo Laporte (01:26:56):
It's just occasionally you use 'em, you know? 

Steve Gibson (01:26:59):
Yeah. And it's on and I'm on a workstation yet. It's

Leo Laporte (01:27:02):
Still happening. Oh, me too. I'm even on a home now. There's a request in the Chatman. I, I agree with it. You need to write never Log4j. You need to do that right now. Forget it. Just go out, write it, never Log4j. <Laugh> put it up on this site. You'll have a million downloads. Cause there is really right now to my knowledge, there's no way to say mean you could, you could attempt to trigger it I guess, but there's no way to say, oh, I'm not running it. You know? 

Steve Gibson (01:27:31):
Yeah. That's a very good point. It would be worth, worth someone I'm I have, I'm gonna be debugging spin right tonight. No,

Leo Laporte (01:27:40):
I know you're busy. I know. But you gotta watch a movie about if <laugh> Neo and the bay, I stand, you got priorities <laugh>

Steve Gibson (01:27:50):
You don't work for 24 7,

Leo Laporte (01:27:53):
But I mean, in theory, I mean you could your IOT devices maybe running it. I mean, many of these IOT devices could be running it. I would be surprised. Well,

Steve Gibson (01:28:03):
Eh, where are they gonna put their log? But you're right. They might be rolling their log daily and having it available in CA in case case case you a

Leo Laporte (01:28:11):
Then you can, how often do you see that? In the preferences? Well, you know, here you can upload the log to the 

Steve Gibson (01:28:18):
Support. Yes I, yes. Yes. You know who knows? What's in our routers.

Leo Laporte (01:28:24):

Steve Gibson (01:28:25):
Yes. Anyway, so, so Matthew Warner said at this early stage, there is no proof of active exploitation, meaning that your browser can be the entry point. He said, but this vector significantly expands the attack service and can impact services even running as local host, which were not a exposed to any network. And so that's what makes this latest, the, this latest local attack vector such a concern. So while this latest discovery can be resolved by updating all local development and internet facing environments last Friday, Apache rolled out yet another version of log for J 2.1 7.0. So now we had the original CVE, 44, 2 28 with its ESS score of 10.0, fixed by version 2.15, then CVE 20 21 45, 0 46 with its score upgraded from 3.7 to 9.0. And that was fixed by 2.1 6.0 and finally CV 20 21 45, 1 0 5 with its CVSs of 7.5, cuz it's local only, but still can get you, which is fixed by 2.1 7.0.

Steve Gibson (01:29:55):
By the way, my router is running Log4j I forgot cuz I'm using a ubiquity router and oh, that's right. Ubiquity's on the list. Unify unify uses EP. Yep. Yep. It's nice. Jake. William. Yeah, there you go. What good possibly. Anyway, Jake Williams, the CPO, the CTO and co-founder of the incident response firm breach quest said we should't, as in, should not be surprised that additional vulnerabilities were discovered in log for Jay given the additional specific focus on the library, similar to log for Jay this summer, the original, and this is him Jake saying print nightmare, vulnerability disclosure led to the discovery of, of multiple additional distinct vulnerabilities. The discovery of additional vulnerabilities and log for J should not cause concern about the security of log for J itself. If anything, log for J is more secure because of the additional attention paid by researchers.

Steve Gibson (01:31:01):
And I would just say the turn off that, that variable interpretation and expansion that's where all of the problem came from, not from logging, but, but from the fact that it was like ridiculously open ended and overpowered. So, so that you could cause variable expansion to go do a DNS or an L D a query or, and that, or download Java and run it. I mean, that's just that just nuts. Okay. So not too surprisingly additional problems were found with the original vulnerability, right. And the initial fixes needed fixing. And so that's happened. So now anybody who thought, okay, a good, I installed 2.15. Well, no, now you need 2.17. So that would probably be a good idea.

Steve Gibson (01:31:54):
So what have we learned about the extent of Log4j's usage, which need to be found and fixed? And this is <laugh>, this is really interesting. Okay. So one source of appraisal is Google who had their open source team scan ma central ma central is today's largest Java package repository. What they found was that 35,863 individual Java packages were either directly or indirectly using vulnerable versions of Apaches log for J library. Their scan looked for packages that used log for J versions, which were vulnerable to both the original log for shell exploit. We first talked about last week and also the second remote code execution bug discovered in the log for shell patch members of the Google open source insights team said when a major Java security flaw is found it major, right? I mean past major Java security flaws generally affect around 2% of the ma central index.

Steve Gibson (01:33:20):
However, thanks to the prevalence of the use of Log4j the 35,863 Java packages vulnerable to Log4Shell account for roughly 8% of Maven Central's total of around 400 and thousand Java packages. This was an impact that the team members characterized as enormous. And despite the effort and focus, fixing everything is a monumental task. Google published their report at the end of last week on the 17th, where at that point 4,620 out of the total 35,863 packages have been updated. But we've seen that these things tend to taper off exponentially, right? With the most work immediately being done. And with the pace inevitably slowing with each passing day and week and month because of this, the Google guy said they didn't expect the log for shell issue to be patched in full at least four years.

Steve Gibson (01:34:43):
One contributing reason is because Log4j is more often than not an indirect dependency. Java libraries are built by writing some code, which uses functions available in other Java libraries, which they import. And those are built by writing some code, which uses functions from other Java libraries and so on. That's really how it happens. So the problem is more often, not that a Java, a library directly uses Log4j 17% do it's that the other 83% instead use another Java library, which might use Log4j or might use another library that does. And so on. And as a result of this multiple depth inheritance maintainers of vulnerable Java packages are forced to wait until other developers and maintainers of the packages. They depend upon have updated their own libraries. The, to put some numbers to this Google explained, and Leo, I have a really cool histogram on the next page 11 on the show notes.

Steve Gibson (01:36:07):
Google explained that Log4j is only a direct dependency in approximately 7,000 packages of the more than three 35,000 vulnerable libraries. So many Java developers either need to wait for the packages they use to be updated or search around four and switch to alternative solutions that are not vulnerable. When Google was asked by fixing the JVM ecosystem, them was so hard. Their open source team explained that by far most Java modules depend upon Log4j in directly. And the deeper the vulnerability is down the dependency chain, the more steps are required for it to be fixed since the bottom most module where the direct dependency exists must be fixed first. Then the module that depends upon that module needs to be rebuilt using its dependency, which is now fixed. And then the module above that one needs to be rebuilt and so on.

Steve Gibson (01:37:19):
So Google's report used a histogram to elegantly summarize the dependency chain depths they encountered when they were exploring each of the approximately 440,000 dependency chains in search of any that used vulnerable for J instances now. And I've got, as I said, I got that chart in the show notes, you'd, you'd expect to see more or less decreasing incidents statistically, as the depth increases and overall that's what we do see, but there's a weird jump upward at a dependency depth of five. The histogram shows that about 14.75% of all dependencies occur at a depth of four. Now that now that's, I should also mention that, like, it looks like 17%, as I mentioned before, have a depth of one meaning that they the package directly uses Log4j but then looks like around 21% have, are using a package where that package uses Log4j. So a depth of two has 21%. And of, so of course you have to sum those to, to, to get the total packages with one or two, then a depth of three drops to around looks like 12%, a depth of four, for some reason, as I said, it goes up to 14.75, but then for some reason that almost doubles at a depth of five to 26.5% of all dependencies occurring in a depth to five, which is more than one in four almost vulnerable packages.

Leo Laporte (01:39:15):
One package, a lot of people use that depends upon Log4j. Right, right. And so it's gotta be, there's gotta be one outlier package that is the, you know, as, as Log4j deep, very deep within its dependencies <laugh> that everybody uses, you know, and it might be Apache. It might be, you know, some of these just widely used, that's gotta be it. Right?

Steve Gibson (01:39:39):
Yeah. It's gotta, it's so weird. I think, I think that because, I mean, it just it's like its complete statistical outlier because then as if to make up for that big almost doubling, it just goes away five, then it crashes right. Then it drops to 6% of them at a depth of six and looks maybe like a half a percent at a depth of, of, of seven or eight. So, but what, what this means is that if the root Log4j dependency is five dependency layers down, then all five of then, then, then that package must be fixed. And the, the packages that depend upon it must be fixed. Then the packages that depend upon it must be fixed and fixed again and fixed again. And it has to be done in sequence, right? Because, because you have to be able to import the fixed dependence, the packages you're dependent upon rebuild your, your, your library using the updated dependencies only then can the, the person maintaining the library that's dependent upon yours update theirs.

Steve Gibson (01:40:57):
And if at any point in that chain somebody's, you know, on vacation or, you know, got tired of that project and like, eh, you know, then everything comes to a grinding halt, nothing beyond that can get updated. So I mean, it it's really bad. I mean, it's kind of a messed up system from, from that standpoint and you have to say, wow, it's amazing. It does as well as it does, you know? And of course it reminds us of that, that, that crazy stack of blocks where there was one little twig holding the whole rickety thing up. Right. And everyone's hoping that, you know, that that block of tower tower blocks is not in California where

Leo Laporte (01:41:44):
We tend to have earthquakes naive. Yeah. Naive question. I think I know the answer. Why don't I just search for all occurrence is of log for J dot jar and delete it.

Steve Gibson (01:41:58):
Oh. Cause it could be a binary inclusion. It, it, it could be linked

Leo Laporte (01:42:03):
Into, oh, so it wouldn't necessarily be a Log4j dot jar file. It could be linked in. It could be, you might not see it

Steve Gibson (01:42:09):
Jar. Yes. Yes. The, the Log4j functionality built into to a package,

Leo Laporte (01:42:15):
Not to mention you probably break a bunch of stuff,

Steve Gibson (01:42:17):
You delete it,

Leo Laporte (01:42:18):
You know, and some software will go, oh, I, somebody deleted my log forg. Let me just download that again. Wow. And I imagine in the manifest, if you had a good package manager, oh, that's just a mess.

Steve Gibson (01:42:31):
There are some that allow you to specify ranges.

Leo Laporte (01:42:34):
You should say nothing less than whatever it is. Two point 15,

Steve Gibson (01:42:38):
But it may well have been that someone said two point 12 to two point 15, cuz those are the ones that were known to be compatible. And we don't know about 16 or 17. Right. So it's like, yeah, no, no, I don't want that

Leo Laporte (01:42:50):
One. We've kind of, we know about this world because this is, this is what happens with Python and a lot of programming languages. And you do, you know, in the manifest you'll specify, no, it has to be this version or this version. Right. And and we just won't, it won't compile and won't run

Steve Gibson (01:43:08):
Right. What a mess. So it's difficult to estimate at this early stage, but yes, Leo, it, it is an incredible mess. We don't know, you know, so much depends upon the maintenance of packages, which may not be receiving routine updating in attempting to get some answer to this question. Google looked at all publicly disclosed past critical advisories. Okay. All publicly disclosed past goal advisories affecting Maven packages to get some sense of how quickly other vulnerabilities in the past have been fully addressed. Okay. You ready? Less than half 48% of Java packages affected by a previous critical vulnerability have ever been fixed that's oh, nice. <Laugh> so Google says we might be waiting for a long time. Wow. Likely on a scale of years. Holy moly. Yeah.

Steve Gibson (01:44:16):
On the other hand, those vulnerabilities may not have made the front page and there might never have been the pressure to fix them that there has been on this one. So we can hope, you know, in less than a week, 3,620 that's 13% of those known to be vulnerable have been fixed. But we can also assume that those had shallow dependency depths and didn't require some guy, you know, there there's one that's eight layers down. How, how are you ever gonna get all a, of the packages in an eight layer dependency tree fixed? I don't know. I don't know. So what's happening on the attack front? <Laugh> no good news. There mm-hmm bit defender. The Romanian AV maker said it has spotted the first ransomware group using the log for Sheryl vulnerability to and encrypt unpatched systems. The first attacks were spotted on Sunday, December 11th.

Steve Gibson (01:45:19):
Okay. This was, remember, this was announced on the ninth. So it, it took two days, two days to incorporate log for Jay into a ransomware attack are being carried out using a new strain of ransomware named Kaari. Kaari means bloodshed in Persian, the Kaari ransomware. Yeah. Great. Is coded and can only target windows systems. And it has not impressed Reese. Richers the malware hunter team and Michael Glassby. He he's that guy that, you know, does all of the free decoders where or decrypter when they can be done, they both described it <laugh> as low effort skid wear <laugh> assembled from publicly available. I'm not gonna, I'm not gonna go too far down the road of this, but I think I know what skid wear implies <laugh> but I'm, I don't wanna go too far down that road. Yeah. Only leave it to an exercise for the reader.

Steve Gibson (01:46:26):
That's their term. But despite rather low quality, the ransomware is functional and can successfully cryp after a successful log for shell attack, Kosari uses properly designed encryption and no flaw so far has been found in it. A group that doesn't produce low effort skid wear is the professional Conti ransomware gang responsible for hundreds of millions in received ransomware payments. They were the second ransomware group to immediately jump on the vulnerabilities in log for Jay, with scans and attacks beginning on Monday, December 13th. So four days following the December 9th public disclosure of the vulnerabilities, the KTI gang are specifically targeting at least now VMware V center servers, which are known to be vulnerable, to log for shell attacks when exploited, they gain access to the server and then immediately move laterally across enterprise networks. So it has to be the case, Leo, that we've got a lot of insinuation into networks, which as the researchers has said, no one's jumping on or not.

Steve Gibson (01:47:48):
Everyone is necessarily immediate jumping on leveraging their newfound footholds. They're just wanting to get in immediately before the, the, the, the openings are closed. And once in we'll figure out what to do later. <Laugh> well, we're in there. Just get in now you'll think of something later. We'll look around and see who we landed. Yeah. So besides the threat from Kosari bit fender also report defender also reported on other malware groups that have been using vulnerabilities in log for J to install DDoS and crypto mining botnets, the Chinese security firm. Khoo 360 said last Monday that they've been tracking at least 10 different groups abusing the vulnerability as well. And checkpoint has reported that it is seen at least 66, 0 variations on the log for shell exploit. So far as a result of bad guys, working around the quick mitigations, which were put in place after the exploit first became public.

Steve Gibson (01:48:57):
Remember we talked about that different ways of, of, of obscuring the, the variable expansion in order to avoid the, the filters that that people just quickly did. And of course, all the serious players jump on this immediately. The a P T advanced persistent threat groups based in China, Iran, North Korea and Turkey were immediately active. The strategy appears to the vulnerability, as we've said, by discovering and establishing a foothold. And then, yep. We'll see what we find. 1.8 million attempts to exploit the log for J vulnerability had been recorded as of early last week. This thing just took off like a rocket and initial access brokers. Remember those are the Myres who first penetrate systems to then sell their illicit access to others to exploit Microsoft's at intelligence center. The Ms T I C said it had observed IAB BS. These initial access brokers immediately leveraging the flaws and log for Jay to obtain initial access to target networks that were then sold to other ransomware affiliates.

Steve Gibson (01:50:24):
That's a good idea. Break into em. And you say, I got access. Anybody wants to buy it. That's brilliant. What's it worth to you? What's it worth to you? Oh yep. God, this is ambition mic. I know on really it's bad. <Laugh> Merry Christmas. In addition, Microsoft said that dozens of malware families running the gamut from crypto currency, coin miners and remote access Trojans to botnets, the web shells have been identified, taking advantage of log for J the industrial cybersecurity firm. Dragos noted that this cross cutting vulnerability, which is vendor and builds both and, and I'm sorry, and effects both proprietary and open source software will leave a wide swath of industries exposed to remote exploitation, including electric power, water, food, and beverage manufacturing, and more, they said, log for J is used heavily in external internet facing and internal applications, which manage and control industrial processes, leaving many industrial operations like electric power, water, food, and beverage manufacturing, others exposed to potential remote exploitation and access. It's important to prioritize external and internet facing applications over internal applications due to their internet exposure. Although both are vulnerable as network defenders close off, more simplistic exploit paths and advanced adversaries incorporate the vulnerability into their attacks. More sophisticated variations of log for J exploits will emerge with a higher likelihood of directly impacting operational technology networks.

Steve Gibson (01:52:30):
So as we said last week, while I don't plan to dwell on the issue to excess, I have the feeling that the impact of log for Jay will be laced throughout the early months of 2022 Leo and boy, it really does. When you look at what Google's research showed the depth of, of dependencies in the Java you know, package trees it's gonna be some time before this is able to get itself fixed. And I

Leo Laporte (01:53:03):
Don't know how well all documented dependencies are. So if it, if it's compiled into something that you use, how do you know? I mean, if you're lucky, maybe in the documentation or somewhere, it says, I mean, sometimes you hit the, you know, you do a, a man on a, a command and it'll show you dependencies at the bottom, but sometimes not so, but yeah.

Steve Gibson (01:53:25):
Eight layers down. Yeah. Some, you know, some guy in incorporated it and then maybe not even using it, but it's there because, you know, Hey, it's free. So let's just say, yeah, wow.

Leo Laporte (01:53:37):
And really all it takes to trigger. It is a, is a malformed string that it logs. So if it's logging stuff, including in web traffic, if it logs that mal form string you're done,

Steve Gibson (01:53:51):
And it could have set up a Ram buffer to, to like log it in, in, in, in, in a ring so that it just has like, you know, if something happens, it's able to say here's what was going on. So it doesn't even have to be writing it. It J it, it could only, it, it, it could be just doing it in order to, in order to like hold a most recent event in, in, in memory, in case it had a problem. And even that would be triggering this problem.

Leo Laporte (01:54:21):
There are the chat rooms telling me Dr. FLA that there are some vulnerability checkers on GitHub. There's one called G R Y P E. I, I don't know how well it works. I don't know if it's just comparing stuff you've installed to a list of known problems or if it's actually testing it or but it's, I mean, and then there's another one called log four, shell dash testing her from hunter.

Steve Gibson (01:54:48):
I was glad that when I installed GitLab, it was Ruby and not Java. Yeah.

Leo Laporte (01:54:53):
<Laugh> but that's not a guarantee because you don't know down the road, there might be a dependency that is in Java. So you're running GitLab now. That's, I'm glad to hear that at. Yeah. Yeah. That's just for your that's right. I remember you talked about that for your source code for for 

Steve Gibson (01:55:15):
Spin, right. Actually, actually not source. I, I won't be putting the source up there. It it's it's so that, because the, all we really have now for vulnerability management is the news groups. Right. And it's fine if every things sort of moving forward, but like, when we get stuck on a mother board, then, then like a week ago, and I'm trying to think, cuz I'm like juggling all of this in my head, so people can, it's like, okay, wait a minute. Was it? Yes. Yeah, yeah, yeah. That's and so the idea is we'll have, we'll we'll have GitLab available for, for managing and tracking persistent problems. Right. That don't just, you know, immediately like, oh, of course then I like, you know, produce another update and then it fixes that grit gets

Leo Laporte (01:55:55):
Really great for that. I mean, GI Git is an amazing tool. I really like it a lot.

Steve Gibson (01:55:58):
Yeah. And I'm very, I may very well right now I'm, I'm using to sync my source.

Leo Laporte (01:56:08):
I know you are. And I was gonna ask when you had first found that why don't you just use Git? I might even even ask that cause

Steve Gibson (01:56:13):
Then I think you maybe did. Yeah. And I it's just cuz I never have. Right. and I would be circum. I mean it's one thing to put open source on GI. It's a different thing to put proprietary. Wouldn't

Leo Laporte (01:56:25):
Put anything proprietary on GitHub for sure. Because you don't know, they might screw up, you have private repositories, but they might screw up. But I keep, for instance, I keep my EAX dot files up there. I keep as I'm doing the advent of code, I'm putting my solutions up there actually number of yeah.

Steve Gibson (01:56:42):
Perfect for that. Where, where the, the loss is

Leo Laporte (01:56:44):
Not critical. Yeah. Perfect for that. But yeah. Proprietary code. But if you're running your own server that's as long as long for Jay's not in there. You're all right.

Steve Gibson (01:56:51):
<Laugh> well, but it is publicly exposed.

Leo Laporte (01:56:54):
Yeah, it has. Cause it has to be that's that's right. Yeah. Yeah. I really think that this is gonna Hasen the zero trust model, because this point you might as well just assume that you have an attacker inside the network. Right?

Steve Gibson (01:57:14):
Yeah. I, I would say if, if, if you're an enterprise and you have reason, like if, if, if your guys are screwing around last week and this week trying to get this resolved before Christmas you and, and given the fact that it was so easy to scan for this remotely and the bad guys jumped on this with a vengeance. I mean like over the weekend, you know, it was home on the weekend and, and they were scanning over the weekend. So it, you know, immediately too late.

Leo Laporte (01:57:50):
Yeah. Yeah. And, and there's really, I mean, somebody uses it. There's no log of them, <laugh> using it. So you just don't know unless you, unless you catch them, if you're using a Canary or something, but if they just lay low and say, look, we got access, it's gonna be tough. Yeah. What you really want

Steve Gibson (01:58:08):
Is log log for

Leo Laporte (01:58:09):
Jay log log for Jay <laugh>. What could possibly go wrong? <Laugh> Steve When you go there, there's a few things you might want to check out. Of course, this show he's got unusual versions of the show. We both have the 64 kilo audio, but Steve has the 16 kilobit audio sounds a little bit like Alexander Graham bell on his first recording. But, but Hey, it's small. Also small, the fantastic transcripts Elaine Ferris does for every episode which allow you they're searchable and allow you to find parts of the show or just to have it to read along while you listen. And he has a full full quality while you're there pick up a copy of spin, right version 6.0 is out right now, as you know, the world's best mass storage, recovery and maintenance utility. You'll get six one automatically. If you buy 6.0 now, and you can also participate in the development of six one imminent let's see there's all sorts of stuff in there. Just browse around. It's kind of a, a, a rabbit Warren of goodness, <Laugh> I'm sorry. I shouldn't have said that while you were drinking. <Laugh>

Steve Gibson (01:59:23):
I a rapid, a rapid warrant of

Leo Laporte (01:59:26):
Goodness. That's right. Of goodness. Not a bad rabbit, a good rabbit warrant. He takes messages. His DMS are open at on Twitter. He's at SG, G R C. We also have the show at our website, You could subscribe, of course, in your favorite podcast application, there's a YouTube channel. We do the show on Tuesdays. Now, next Tuesday, we will not be here because it's the best of security. Now we picked yay. A bunch of horrible exploits from the year and we strung 'em all together. It'll be fun. So next Tuesday, there will be a show, but not live. You'll just download it. And you can listen and it's fun. And then we will all be back in studio after the new year, January 4th for the next security. Now, if you wanna tune in and watch it, it's it's we do it about 1:30 PM, Pacific four 30 Eastern 21 UTC on Tuesdays, you can stream it live or audio or chat with If you're doing that or in the discord, if you're a club TWI member otherwise I hope Steve, you and Lori have a wonderful Christmas. And are you gonna do a new year's Eve part? Just the two of you, a little champagne,

Steve Gibson (02:00:46):
You know she's got asthma

Leo Laporte (02:00:50):
And you don't want to go out. I'm not suggesting that these days. Yeah.

Steve Gibson (02:00:54):
And but so, you know zoom and FaceTime we'll, we'll say hi to our family. There you go. And sort of hang out with them virtually. Yeah. And light the fire and, and you know, just enjoy

Leo Laporte (02:01:07):
Ourselves. We have down the road, my, where my daughter lives there was a holiday party, December 11th, 28, people got COVID from this little party and they think it was Alro. It just spread so easily. So it's just not worth, even if you're boosted it's really not worth taken a chance. I think so one

Steve Gibson (02:01:25):
Of the MD talking heads on Sunday was likening it to the mumps in terms of communicability. It's

Leo Laporte (02:01:32):
Just gonna spread like crazy. Yeah. Yeah. And you know, most people, especially if you're boostered, it it'll be sniffles and it'll be fine. And remember vitamin D status has turned out to be, I'm taking that vitamin D I'm drinking my vitamin C. I'm making sure I am taking zinc and all that stuff, but you it's kind, kind of like Russian roulette, you know, you don't know you might be the one that really gets sick or gets long COVID and and why take a chance? So we're gonna, we're gonna just hunker down. I think. Yeah. We don't lose any listeners. Our listeners are valuable. We can't afford to you. Every one of you matters. I hope you all have a great holiday. Take some time off, spend time with a fam, enjoy your new year's Eve. And we'll be back January 4th to continue. As we count down the last three years of security. Now you son of a good <laugh> have a great new year. Steve, we'll see you next year. Bye. Everybody happy new year.

Speaker 4 (02:02:28):
Hey, you don't have to wait till the weekend to get the tech news. You need join Jason Howell and myself, Micah Sergeant for tech news weekly, where we talk to and about the people making and breaking news security.

All Transcripts posts