Security Bits — 11 July 2021

Feedback & Followups

The Western Digital story from last time has continued to evolve:
- More devices are affected: Another 0-Day Looms for Many Western Digital Users – Krebs on Security — krebsonsecurity.com/…
- But there have also been more responses from WD, including a data recovery service and a trade-in-upgrade program: Got a WD My Book Live device? Your data is at risk – here’s what to do — www.intego.com/…
A new variant of the iOS/macOS Wifi name bug has emerged (triggered by networks called %secretclub%power). TL;DR: don’t join any WiFi networks with % symbols in their name on Apple devices until Apple patch this — www.imore.com/…
Social Media companies continue to evolve in response to abuses of their platforms:
- Facebook tests new feature alerting users to extremist content — www.brusselstimes.com/…
It’s not just bad behavior – why social media design makes it hard to have constructive disagreements online theconversation.com…

❗ Deep Dive 1 — Print Nightmare

TL;DR — if you run Windows servers, you should probably disable the print spooler by Group Policy and leave it off, especially on your domain controllers. Home users definitely need to stay on top of Microsoft’s patches and might consider also disabling their print spoolers.

Important Caveat — this is a very rapidly developing and very confusing story. It’s probably already incomplete as you read this!

A pair of vulnerabilities have been found in the Windows print spooler process that allows for local privilege escalation, and remote code execution under some circumstances. The phrase some circumstances is doing a lot of heavy lifting here — as the story has developed those circumstances in which remote code execution was believed to be possible have shifted around a lot.

Depending on how you look at it this is one big problem or two interrelated smaller problems. It’s probably simpler to think of it as one big mess rather than two, but there are two CVE numbers assigned, so officially it is two vulnerabilities.

So far the story started with a responsibly disclosed local privilege escalation bug (LPE) that Microsoft attempted to patch in June. The original security researcher realised that Microsoft’s patch fixes his proof of concept, but didn’t actually fix the underlying problem — Microsoft had treated a symptom, but not cured the disease. Microsoft closed the case, and the security researcher wasn’t able to re-establish communication, and in frustration, went public.

Meanwhile, another group of security researchers also found a bug in the print spooler, and they assumed it was the one Microsoft just patched, so, they released their proof of concept (POC), assuming it was responsible disclosure, but, their POC still worked on supposedly patched systems, and their POC included remote code execution (RCE), not just LPE, so it exposed a much more dangerous vulnerability. As soon as it became clear the June patch wasn’t what they thought the researchers un-published their POC, but it was too late, the cat was out of the bag!

At this point we have a zero-day remote code execution bug with local privilege escalation — that’s BAD. A remote computer could run arbitrary code with SYSTEM privileges (Windows’ equivalent of root on POSIX OSes). This is when Twitter starts to fill with flow charts trying to explain exactly what configurations do and don’t lead to remote code execution. Do you have to disable the entire print spooler, or can you get away with just tweaking some registry keys? It got really confusing really quickly, and the advice seemed to change every few hours as security researchers found ever more ways of triggering the bugs.

After a while, things simplified greatly when a mechanism was discovered to trigger RCE so reliably that the only defence was to completely disable the print spooler. There were lots of jokes about the new flow chart being the simplest ever — just one decision box leading to two answers: “is print spooler enabled? Yes, then vulnerable; No, then safe”.

Microsoft were now in full crisis mode and coming under a lot of pressure so they rushed out an emergency (‘out of band’) patch they said fixed the problem. Cue more joke flow charts — again, one decision box leading to two answers: “have you patched? Yes, then safe; No, then vulnerable”. Great!

By the next morning, Irish time confusion reigned again — security researchers had found combinations of settings that were vulnerable to RCE even on systems with the emergency patches! The flow charts started to become so complicated again that the security community just threw up their collective hands and gave up — the advice everywhere was “patch as quickly as you can, but assume that’s not enough and disable the print spooler too”. In fact, most went even further, advising that on servers, you make the group policy disabling print spooler on servers permanent. Clearly, this is a dangerous attack surface, and since most servers have no need for a print spooler, just get rid of it and reduce the attack surface going forward.

As I type this, that’s where the story stands. Goodness knows what else has happened between then and when you read this 🙂

Deep Dive 2 — Audacity’s Fall 🙁

This week Audacity broke into the more main-stream tech news because of a change in their privacy policy which allows them to collect and store users activities on the popular open source audio editor and store and share that data, including IP address, with others, including law enforcement agencies and potential buyers. For the first 24 hours the data would be stored as-is, and then after that, it would be pseudonymised. Basically, each time a user would open the audio editor to edit a podcast or what ever the app would phone home and the activity would be logged, and for a day, tied to the user’s IP.

The data would be primarily stored in the EAA (EU plus some affiliated countries like Switzerland), which is something at least, it brings GDPR obligations, the policy also states some data will be transferred to the company’s HQ in Russia, and to their attorneys in the US.

Because tracking the personally identifiable information of kids is a problem under the GDPR (it comes with a lot of responsibilities), the terms of use have also been updated to state that users must be over 13 to use the app. This is a problem for an app used in many schools, and, probably violates the GPL license the code was created under.

Needless to say, there was an immediate backlash, and some security tools even started listing the app as spyware! The company have responded, saying it’s just poor language choice, and they’ll have another go at drafting a clearer, more restrained policy. They also said the actual data collected would be quite limited, just OS & version, processor type, IP address, and optionally, error reports.

The company didn’t address the age restriction at all.

What happened this week is not the start of a new controversy, it’s actually the third, and so far most egregious, chapter of a longer-running story that’s been bubbling within the open source community for a few months.

Once upon a time … err … no, back in May, a company named Muse bought Audacity (the code is open source, but it still has a copyright, so owning it means you can release it under other licenses too, and open source licenses don’t cover things like service marks and trademarks. This is why open source software can be, and often is, owned by for-profit companies. E.g. RedHat own RHEL & CentOS, and Canonical own Ubuntu).

The original blog post announcing the acquisition could probably be best described as tone-deaf, and it piqued the interest of some in the open source community in all the wrong ways. There was a lot of concern, but nothing bad had actually happened yet … Yet!

The first minor controversy was an update to a more restrictive contributor agreement for anyone contributing code to the open source project in the future. The actual changes were not that bad, but the tone was off again, and more people started to get more worried. Would Muse be a good steward for this important open source project?

The second controversy can a few weeks later when a commit showed up in the official Git repo adding telemetry to the upcoming release — the app would phone home with supposedly anonymous user activity data. Not the end of the world, but it seemed to validate people’s growing concerns.

And then came this week’s new privacy policy!

Thankfully, as an open source project the code can be forked, so a new audio editor with a new name can emerge from this. But, someone will need to take on that work, and a big enough team will need to self-assemble to make the new project sustainable.

The possibility of a fork is one of the best features of an open source license, but, it’s by no means a foregone conclusion that a fork will work out well in reality. The fork can’t be called Audacity, that name belongs to Muse, and it’s that name that has all the reputation, so will regular people know they need to change to a new app? Will they find the new app?

Years after MariaDB forked from MySQL, how many people have switched? Worse still, how many people are still using the effectively abandoned Open Office instead of the actively maintained and developed fork, Libre Office?

This could still turn out well in one of two ways — Muse could see the light, change their attitude, and earn back the respect and trust of the open source community, or, a well organised and managed fork could emerge and gain wide-spread adoption, replacing the official Audacity out in the world.

❗ Action Alerts

New LinkedIn Data Leak Leaves 700 Million Users Exposed — restoreprivacy.com/…

Worthy Warnings

A cautionary tale illustrating the importance of using parental controls: Parent forced to sell car after child racks up $1,800 App Store bill — www.imore.com/…
The password generator included in Kaspersky Password Manager was generating guessable passwords. It’s been fixed now, but users who use it to generate their password should re-set them where ever they used them — donjon.ledger.com/…
🇧🇷 Reporting has emerged that criminal gangs in Brazil are managing to steal money from iPhone owners via stolen iPhones without needing complex cracking technology. The details are still hazy, but it the technique seems to depend on three things: (9to5mac.com/… & www.imore.com/…)
1. Users not having a PIN on their SIM cards (and not having eSIMs)
2. Users Apple ID email addresses being discoverable online via social media profiles and posting
3. Users storing passwords in unprotected places on their phones like the Notes app.

Notable News

Excellent Explainers

Interesting Insights

Palate Cleansers

🎧 A riveting podcasting mini-series that weaves together so many of the big security news stories we’ve covered in this segment over the years: Introducing The Lazarus Heist — overcast.fm/…

Legend

When the textual description of a link is part of the link it is the title of the page being linked to, when the text describing a link is not part of the link it is a description written by Bart.

Emoji	Meaning
🎧	A link to audio content, probably a podcast.
❗	A call to action.
flag	The story is particularly relevant to people living in a specific country, or, the organisation the story is about is affiliated with the government of a specific country.
📊	A link to graphical content, probably a chart, graph, or diagram.
🧯	A story that has been over-hyped in the media, or, “no need to light your hair on fire” 🙂
💵	A link to an article behind a paywall.
📌	A pinned story, i.e. one to keep an eye on that’s likely to develop into something significant in the future.
🎩	A *tip of the hat* to thank a member of the community for bringing the story to our attention.