DOUG. Firefox updates, another Bug With An Impressive Name, and the SEC demands disclosure. All that, and more, on the Naked Security podcast. [MUSICAL MODEM] Welcome to the podcast, everybody. I am Doug Aamoth; he is Paul Ducklin. Paul, I hope you will be proud of me… I know you are a cycling enthusiast. I rode a bicycle yesterday for 10 American miles, which I believe is roughly 16km, all while pulling a small but not unheavy child behind the bike in a two-wheeled carriage. And I’m still alive to tell the tale. Is that a long way to ride a bike, Paul?
DUCK. [LAUGHS] It depends how far you really needed to go. Like, if it was actually 1200 metres that you had to go and you got lost… [LAUGHTER] My enthusiasm for cycling is very high, but it doesn’t mean that I deliberately ride further than I need to, because it’s my primary way of getting around. But 10 miles is OK. Did you know that American miles and British miles are, in fact, identical?
DOUG. That is good to know!
DUCK. And have been since 1959, when a bunch of countries including, I think, Canada, South Africa, Australia, the United States and the UK got together and agreed to standardise on an “international inch”. I think the Imperial inch got very, very slightly smaller and the American inch got very, very slightly longer, with the result that the inch (and therefore the yard, and the foot, and the mile)… …they’re all defined in terms of the metre. One inch is exactly 25.4mm Three significant figures is all you need.
DOUG. Fascinating! Well, speaking of fascinating, it’s time for our This Week in Tech History segment. This week, on 01 August 1981, Music Television, also known as MTV, went live as part of American cable and satellite television packages, and introduced the public to music videos. The first one played [SINGS, RATHER WELL IN FACT] “Video Killed the Radio Star” by The Buggles. Fitting at the time, although ironic nowadays as MTV rarely plays music videos any more, and plays no new music videos whatsoever, Paul.
DUCK. Yes, it is ironic, isn’t it, that cable TV (in other words, where you had wires running under the ground into your house) killed the radio (or the wireless) star, and now it looks as though cable TV, MTV… that sort of died out because everyone’s got mobile networks that work wirelessly. What goes around comes around, Douglas.
DOUG. Alright, well, let’s talk about these Firefox updates. We get a double dose of Firefox updates this month, because they’re on a 28 day cycle: Firefox fixes a flurry of flaws in the first of two releases this month No zero-days in this first round out of the gate, but some teachable moments. We have listed maybe half of these in your article, and one that really stood out to me was: Potential permissions request bypass via clickjacking.
DUCK. Yes, good old clickjacking again. I like that term because it pretty much describes what it is. You click somewhere, thinking you’re clicking on a button or an innocent link, but you’re inadvertently authorising something to happen that isn’t obvious from what the screen’s showing under your mouse cursor. The problem here seems to be that under some circumstances, when a permissions dialog was about to pop up from Firefox, for example, say, “Are you really sure you want to let this website use your camera? have access to your location? use your microphone?”… …all of those things that, yes, you do want to get asked. Apparently, if you could get the browser to a performance point (again, performance versus security) where it was struggling to keep up, you could delay the appearance of the permissions pop-up. But by having a button at the place where the pop-up would appear, and luring the user into clicking it, you could attract the click, but the click would then get sent to the permissions dialog that you hadn’t quite seen yet. A sort of visual race condition, if you like.
DOUG. OK, and the other one was: Off-screen canvas could have bypassed cross-origin restrictions. You go on to say that one web page could peek at images displayed in another page from a different site.
DUCK. That’s not supposed to happen, is it?
DOUG. No!
DUCK. The jargon term for that is the “same-origin policy”. If you’re running website X and you send me a whole bunch of JavaScript that sets a whole load of cookies, then all that’s stored in the browser. But only further JavaScript from site X can read that data back. The fact that you’re browsing to site X in one tab and site Y in the other tab doesn’t let them peek at what the other is doing, and the browser is supposed to keep all of that stuff apart. That’s obviously pretty important. And it seems here that, as far as I understand it, if you were rendering a page that wasn’t being displayed yet… …an off-screen canvas, which is where you create, if you like, a virtual web page and then at some future point you say, “Right now I’m ready to display it,” and bingo, the page appears all at once. The problem comes with trying to make sure that the stuff that you’re rendering invisibly doesn’t inadvertently leak data, even though it never ultimately gets displayed to the user. They spotted that, or it was responsibly disclosed, and it was patched. And those two, I think, were included in the so called “High”-level vulnerabilities. Most of the others were “Moderate”, with the exception of Mozilla’s traditional, “We found a whole lot of bugs through fuzzing and through automated techniques; we didn’t probe them to find out if they could be exploited at all, but we are willing to assume that somebody who tried hard enough could do so.” That’s an admission that we both like so much, Doug… because potential bugs are worth quashing, even if you feel certain in your heart that nobody will ever figure out how to exploit them. Because in cybersecurity, it pays never to say never!
DOUG. Alright, you’re looking for Firefox 116, or if you’re on an extended release, 115.1. Same with Thunderbird. And let’s move on to… oh, man! Paul, this is exciting! We have a new BWAIN after a double-BWAIN last week: a Bug With An Impressive Name. This one is called Collide+Power: Performance and security clash yet again in “Collide+Power” attack
DUCK. [LAUGHS] Yes, it’s intriguing, isn’t it, that they chose a name that has a plus sign in it?
DOUG. Yes, that makes it hard to say.
DUCK. You can’t have a plus sign in your domain name, so the domain name is collidepower.com.
DOUG. Alright, let me read from the researchers themselves, and I quote: The root of the problem is that shared CPU components, like the internal memory system, combine attacker data and data from any other application, resulting in a combined leakage signal in the power consumption. Thus, knowing its own data, the attacker can determine the exact data values used in other applications.
DUCK. [LAUGHS] Yes, that makes a lot of sense if you already know what they’re talking about! To try and explain this in plain English (I hope I’ve got this correctly)… This goes down to the performance-versus-security problems that we’ve talked about before, including last week’s podcast with that Zenbleed bug (which is far more serious, by the way): Zenbleed: How the quest for CPU performance could put your passwords at risk There’s a whole load of data that gets kept inside the CPU (“cached” is the technical term for it) so that the CPU doesn’t need to go and fetch it later. So there’s a whole lot of internal stuff that you don’t really get to manage; the CPU looks after it for you. And the heart of this attack seems to go something like this… What the attacker does is to access various memory locations in such a way that the internal cache storage remembers those memory locations, so it doesn’t have to go and read them out of RAM again if they get reused quickly. So the attacker somehow gets these cache values filled with known patterns of bits, known data values. And then, if the victim has memory that *they* are using frequently (for example, the…