Microsoft assigns CVE to Snipping Tool bug, pushes patch to Store

by Paul Ducklin | Mar 27, 2023 | Cybersecurity

Last week was aCropalypse week, where a bug in the Google Pixel image cropping app made headlines, and not just because it had a funky name.

(We formed the opinion that the name was a little bit OTT, but we admit that if we’d thought of it ourselves, we’d have wanted to use it for its word-play value alone, even though it turns out to be harder to say out loud than you might think.)

The bug was the kind of programming blunder that any coder could have made, but that many testers might have missed:

Image cropping tools are very handy when you’re on the road and you want to share an impulse photo, perhaps involving a cat, or an amusing screenshot, perhaps including a wacky posting on social media or a bizarre ad that popped up on a website.

But quickly-snapped pics or hastily-grabbed screenshots often end up including bits that you don’t want other people to see.

Sometimes, you want to crop an image because it simply looks better when you chop off any extraneous content, such as the graffiti-smeared bus stop on the left hand side.

Sometimes, however, you want to edit it out of decency, such as cutting out details that could hurt your own (or somone else’s) privacy by revealing your location or situation unnecessarily.

The same is true for screenshots, where the extraneous content might include the content of your next-door browser tab, or the private email directly below the amusing one, which you need to cut out in order to stay on the right side of privacy regulations.

Be aware before you share

Simply put, one of the primary reasons for cropping photos and screenshots before you send them out is to get rid of content that you don’t want to share.

So, like us, you probably assumed that if you chopped bits out of a photo or screenshot and hit [Save], then even if the app kept a record of your edits so you could revert them later and recover the exact original…

…those chopped-off bits would not be included in any copies of the edited file that you chose to post online, email to your chums, or send to a friend.

The Google Pixel Markup app, however, didn’t quite do that, leading to a bug denoted CVE-2023-20136.

When you saved a modified image over the old one, and then opened it back up to check your changes, the new image would appear in its cropped form, because the cropped data would be correctly written over the start of the previous version.

Anyone testing the app itself, or opening the image to verify it “looked right now” would see its new content, and nothing more.

But the data written at the start of the old file would be followed by a special internal marker to say, “You can stop now; ignore any data hereafter”, followed entirely incorrectly by all the data that used to appear thereafter in the old version of the file.

As long as the new file was smaller than the old one (and when you chop the edges off an image, you expect the new version to be smaller), at least some chunks of the old image would escape at the end of the new file.

Traditional, well-behaved image viewers, including the very tool you just used to crop the file, would ignore the extra data, but deliberately-coded data recovery or snooping apps might not.

Pixel problems repeated elsewhere

Google’s buggy Pixel phones were apparently patched in the March 2023 Android update, and although some Pixel devices received this month’s updates two weeks later than usual, all Pixels should now be up-to-date, or can be force-updated if you perform a manual update check.

But this class of bug, namely leaving data behind in an old file that you overwrite by mistake, instead of truncating its old content first, could in theory appear in almost any app with a [Save] feature, notably including other image-cropping and screenshot-trimming apps.

And it wasn’t long before both the Windows 11 Snipping Tool and the Windows 10 Snip & Sketch app were found to have the same flaw:

You could crop a file quickly and easily, but if you did a [Save] over the old file and not a [Save As] to a new file, where there would be no previous content to leave behind, a similar fate would await you.

The low-level causes of the bugs are different, not least because Google’s software is a Java-style app and uses Java libraries, while Microsoft’s apps are written in C++ and use Windows libraries, but the leaky side-effects are identical.

As our friend and colleague Chester Wisniewski quipped in last week’s podcast, “I suspect there may be a lot of talks in August in Las Vegas discussing this in other applications.” (August is the season of the Black Hat and DEF CON events.)

What to do?

The good news for Windows users is that Microsoft has now assigned the identifier CVE-2023-28303 to its own flavour of the aCropalypse bug, and has uploaded patched versions of the affected apps to the Microsoft Store.

In our own Windows 11 Enterprise Edition install, Windows Update showed nothing new or patched that we needed since last week, but manually updating the Snipping Tool app via the Microsoft Store updated us from 11.2302.4.0 to 11.2302.20.0.

We’re not sure what version number you’ll see if you open the buggy Windows 10 Snip & Sketch app, but after updating from the Microsoft Store, you should be looking for 10.2008.3001.0 or later.

Microsoft considers this a low-severity bug, on the grounds that “successful exploitation requires uncommon user interaction and several factors outside of an attacker’s control.”

We’re not sure we quite agree with that assessment, because the problem is not that an attacker might trick you into cropping an image in order to steal parts of it. (Surely they’d just talk you into sending them the whole file without the hassle of cropping it first?)

The problem is that you might follow exactly the workflow that Microsoft considers “uncommon” as a security precaution before sharing a photo or screenshot, only to find that you unintentionally leaked into a public space the very data you thought you had chopped out.

After all, the Microsoft Store’s own pitch for the Snipping Tool describes it as a quick way to “save, paste or share with other apps.”

In other words: Don’t delay, patch it today.

It only takes a moment.

Dangerous Android phone 0-day bugs revealed – patch or work around them now!

by Paul Ducklin | Mar 17, 2023 | Cybersecurity

Google has just revealed a fourfecta of critical zero-day bugs affecting a wide range of Android phones, including some of its own Pixel models.

These bugs are a bit different from your usual Android vulnerabilities, which typically affect the Android operating system (which is Linux-based) or the applications that come along with it, such as Google Play, Messages or the Chrome browser.

The four bugs we’re talking about here are known as baseband vulnerabilities, meaning that they exist in the special mobile phone networking firmware that runs on the phone’s so-called baseband chip.

Strictly speaking, baseband is a term used to describe the primary, or lowest-frequency parts of an individual radio signal, in contrast to a broadband signal, which (very loosely) consists of multiple baseband signals adjusted into numerous adjacent frequency ranges and transmitted at the same time in order to increase data rates, reduce interference, share frequency spectrum more widely, complicate surveillance, or all of the above. The word baseband is also used metaphorically to describe the hardware chip and the associated firmware that is used to handle the actual sending and receving of radio signals in devices that can communicate wirelessly. (Somewhat confusingly, the word baseband typically refers to the subsystem in a phone that handles conecting to the mobile telephone network, but not to the chips and software that handle Wi-Fi or Bluetooth connections.)

Your mobile phone’s modem

Baseband chips typically operate independently of the “non-telephone” parts of your mobile phone.

They essentially run a miniature operating system of their own, on a processor of their own, and work alongside your device’s main operating system to provide mobile network connectivity for making and answering calls, sending and receiving data, roaming on the network, and so on.

If you’re old enough to have used dialup internet, you’ll remember that you had to buy a modem (short for modulator-and-demodulator), which you plugged either into a serial port on the back of your PC or into an expansion slot inside it; the modem would connect to the phone network, and your PC would connect to the modem.

Well, your mobile phone’s baseband hardware and software is, very simply, a built-in modem, usually implemented as a sub-component of what’s known as the phone’s SoC, short for system-on-chip.

(You can think of an SoC as a sort of “integrated integrated circuit”, where separate electronic components that used to be interconnected by mounting them in close proximity on a motherboard have been integrated still further by combining them into a single chip package.)

In fact, you’ll still see baseband processors referred to as baseband modems, because they still handle the business of modulating and demodulating the sending and receiving of data to and from the network.

As you can imagine, this means that your mobile device isn’t just at risk from cybercriminals via bugs in the main operating system or one of the apps you use…

…but also at risk from security vulnerabilities in the baseband subsystem.

Sometimes, baseband flaws allow an attacker not only to break into the modem itself from the internet or the phone network, but also to break into the main operating system (moving laterally, or pivoting, as the jargon calls it) from the modem.

But even if the crooks can’t get past the modem and onwards into your apps, they can almost certainly do you an enormous amount of cyberharm just by implanting malware in the baseband, such as sniffing out or diverting your network data, snooping on your text messages, tracking your phone calls, and more.

Worse still, you can’t just look at your Android version number or the version numbers of your apps to check whether you’re vulnerable or patched, because the baseband hardware you’ve got, and the firmware and patches you need for it, depend on your physical device, not on the operating system you’re running on it.

Even devices that are in all obvious respects “the same” – sold under the same brand, using the same product name, with the same model number and outward appearance – might turn out to have different baseband chips, depending on which factory assembled them or which market they were sold into.

The new zero-days

Google’s recently discovered bugs are described as follows:

[Bug number] CVE-2023-24033 (and three other vulnerabilities that have yet to be assigned CVE identities) allowed for internet-to-baseband remote code execution. Tests conducted by [Google] Project Zero confirm that those four vulnerabilities allow an attacker to remotely compromise a phone at the baseband level with no user interaction, and require only that the attacker know the victim’s phone number.

With limited additional research and development, we believe that skilled attackers would be able to quickly create an operational exploit to compromise affected devices silently and remotely.

In plain English, an internet-to-baseband remote code execution hole means that criminals could inject malware or spyware over the internet into the part of your phone that sends and receives network data…

…without getting their hands on your actual device, luring you to a rogue website, persuading you to install a dubious app, waiting for you to click the wrong button in a pop-up warning, giving themselves away with a suspicious notification, or tricking you in any other way.

18 bugs, four kept semi-secret

There were 18 bugs in this latest batch, reported by Google in late 2022 and early 2023.

Google says that it is disclosing their existence now because the agreed time has passed since they were disclosed (Google’s timeframe is usually 90 days, or close to it), but for the four bugs above, the company is not disclosing any details, noting that:

Due to a very rare combination of level of access these vulnerabilities provide and the speed with which we believe a reliable operational exploit could be crafted, we have decided to make a policy exception to delay disclosure for the four vulnerabilities that allow for internet-to-baseband remote code execution

In plain English: if we were to tell you how these bugs worked, we’d make it far too easy for cybercriminals to start doing really bad things to lots of people by sneakily implanting malware on their phones.

In other words, even Google, which has attracted controversy in the past for refusing to extend its disclosure deadlines and for openly publishing proof-of-concept code for still-unpatched zero-days, has decided to follow the spirit of its Project Zero responsible disclosure process, rather than sticking to the letter of it.

Google’s argument for generally sticking to the letter and not the spirit of its disclosure rules isn’t entirely unreasonable. By using an inflexible algorithm to decide when to reveal details of unpatched bugs, even if those details could be used for evil, the company argues that complaints of favouritism and subjectivity can be avoided, such as, “Why did company X get an extra three weeks to fix their bug, while company Y did not?”

What to do?

The problem with bugs that are announced but not fully disclosed is that it’s difficult to answer the questions, “Am I affected? And if so, what should I do?”

Apparently, Google’s research focused on devices that used a Samsung Exynos-branded baseband modem component, but that doesn’t necessarily mean that the system-on-chip would identify or brand itself as an Exynos.

For example, Google’s recent Pixel devices use Google’s own system-on-chip, branded Tensor, but both the Pixel 6 and Pixel 7 are vulnerable to these still-semi-secret baseband bugs.

As a result, we can’t give you a definitive list of potentially affected devices, but Google reports (our emphasis):

Based on information from public websites that map chipsets to devices, affected products likely include:

• Mobile devices from Samsung, including those in the S22, M33, M13, M12, A71, A53, A33, A21s, A13, A12 and A04 series;
• Mobile devices from Vivo, including those in the S16, S15, S6, X70, X60 and X30 series;
• The Pixel 6 and Pixel 7 series of devices from Google; and
• any vehicles that use the Exynos Auto T5123 chipset.

Google says that the baseband firmware in both the Pixel 6 and Pixel 7 was patched as part of the March 2023 Android security updates, so Pixel users should ensure they have the latest patches for their devices.

For other devices, different vendors may take different lengths of time to ship their updates, so check with your vendor or mobile provider for details.

In the meantime, these bugs can apparently be sidestepped in your device settings, if you:

• Turn off Wi-Fi calling.
• Turn off Voice-over-LTE (VoLTE).

In Google’s words, “turning off these settings will remove the exploitation risk of these vulnerabilities.”

If you don’t need or use these features, you may as well turn them off anyway until you know for sure what modem chip is in your phone and if it needs an update.

After all, even if your device turns out to be invulnerable or already patched, there’s no downside to not having things you don’t need.

Featured image from Wikipedia, by user Köf3, under a CC BY-SA 3.0 licence.

Firefox 111 patches 11 holes, but not 1 zero-day among them…

by Paul Ducklin | Mar 14, 2023 | Cybersecurity

Heard of cricket (the sport, not the insect)?

It’s much like baseball, except that batters can hit the ball wherever they like, including backwards or sideways; bowlers can hit the batter with the ball on purpose (within certain safety limits, of course – it just wouldn’t be cricket otherwise) without kicking off a 20-minute all-in brawl; there’s almost always a break in the middle of the afternoon for tea and cake; and you can score six runs at a time as long as you hit the ball high and far enough (seven if the bowler makes a mistake as well).

Well, as cricket enthusiasts know, 111 runs is a superstitious score, considered inauspicious by many – the cricketer’s equivalent of Macbeth to an actor.

It’s known as a Nelson, though nobody actually seems to know why.

Today therefore sees Firefox’s Nelson release, with version 111.0 coming out, but there doesn’t seem to be anything inauspicious about this one.

Eleven individual patches, and two batches-of-patches

As usual, there are numerous security patches in the update, including Mozilla’s usual combo-CVE vulnerability numbers for potentially exploitable bugs that were found automatically and patched without waiting to see if a proof-of-concept (PoC) exploit was possible:

• CVE-2023-28176: Memory safety bugs fixed in Firefox 111 and Firefox ESR 102.9. These bugs were shared between the current version (which includes new features) and the ESR version, short for extended support release (security fixes applied, but with new features frozen since version 102, nine releases ago).
• CVE-2023-28177: Memory safety bugs fixed in Firefox 111 only. These bugs almost certainly only exist in new code that brought in new features, given that they didn’t show up in the older ESR codebase.

These bags-of-bugs have been rated High rather than Critical.

Mozilla admits that “we presume that with enough effort some of these could have been exploited to run arbitrary code”, but no one has yet figured out how to do so, or even if such exploits are feasible.

None of the other eleven CVE-numbered bugs this month were worse thah High; three of them apply to Firefox for Android only; and no one has yet (so far as we yet know) come up with a PoC exploit that shows how to abuse them in real life.

Two notably interesting vulnerabilities appear amongst the 11, namely:

• CVE-2023-28161: One-time permissions granted to a local file were extended to other local files loaded in the same tab. With this bug, if you opened a local file (such as downloaded HTML content) that wanted access, say, to your webcam, then any other local file you opened afterwards would magically inherit that access permission without asking you. As Mozilla noted, this could lead to trouble if you were looking through a collection of items in your download directory – the access permission warnings you’d see would depend on the order in which you opened the files.
• CVE-2023-28163: Windows Save As dialog resolved environment variables. This is another keen reminder to sanitise thine inputs, as we like to say. In Windows commands, some character sequences are treated specially, such as %USERNAME%, which gets converted to the name of the currently logged-on user, or %PUBLIC%, which denotes a shared directory, usually in C:Users. A sneaky website could use this as a way to trick you into seeing and approving the download of a filename that looks harmless but lands in a directory you wouldn’t expect (and where you might not later realise it had ended up).

What to do?

Most Firefox users will get the update automatically, typically after a random delay to stop everyone’s computer downloading at the same moment…

…but you can avoid the wait by manually using Help > About (or Firefox > About Firefox on a Mac) on a laptop, or by forcing an App Store or Google Play update on a mobile device.

(If you’re a Linux user and Firefox is supplied by the maker of your distro, do a system update to check for the availability of the new version.)

S3 Ep123: Crypto company compromise kerfuffle [Audio + Text]

by Paul Ducklin | Feb 23, 2023 | Cybersecurity

LEARNING FROM OTHERS

The first search warrant for computer storage. GoDaddy breach. Twitter surprise. Coinbase kerfuffle. The hidden cost of success.

With Doug Aamoth and Paul Ducklin

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

  Using texts is insecure 
    for doing 2FA. 
  So if you want to keep it up, 
    you're going to have to pay.