Perpetual IT

Popular package management site RubyGems.org, which stores and supplies hundreds of thousands of modules for the widely-used programming language Ruby, just patched a dangerous server-side vulnerability.

The bug, dubbed CVE-2022-29176, could have allowed attackers to remove a package that wasn’t theirs (yanking it, in RubyGems jargon), and then to replace it with modified version of their own.

Fortunately, the RubyGems team has looked through its logs for the past 18 months, and says that it “did not find any examples of this vulnerability being used in a malicious way.”

We assume that the vast majority of package updates on record would involve a change in version number (given that when legitimate software changes, you need some obvious way of telling the new version from the old one), which would make the yank-and-republish process rather rare.

If, indeed, there were only a few cases to review, we also assume that it would be feasible to compare any changes between the now-defunct “yanked” code and the newly republished code, even in a repository as large as RubyGems.

This suggests that any unusual rip-and-replace operations would indeed have been found during the security review that followed the report of the bug.

Additionally, the RubyGems security bulletin notes that package owners receive an automatic email notification whenever a package of theirs is yanked or published, yet no support tickets were ever received to report peculiar and unexpected changes of this sort.

Ironically, however, this rip-and-replace bug only works on packages created within the last 30 days, or on packages that haven’t been updated for more than 100 days. (No, we don’t know why these curiously specific limitations apply, but apparently they do.)

In other words, one class of vulnerable package includes all those that aren’t being actively developed any more, thus making it more likely that the email address for the package would be out-of-date or no longer monitored.

What happened?

The bug, it seems, involved a slip ‘twixt the authentication cup and the activation lip.

An attacker with an active account who created a package called, say, slithy, would be authorised to manipulate packages with that name.

However, when submitting a yank request for a package owned by someone else called, say, slithy-tove (the dash in the name is critical to this bug), the authentication process would apparently be handled something like this, according to Ruby coder Greg Molnar:

1. Are you authenticated? You supply your authentication token to prove you’re a registered and logged-in user.
2. What package are you working on? You supply the left-hand end of the package name: slithy.
3. Are you the authorised owner of that package? At this point, you only need to own the name slithy, not any apparent sub-packages that start with that string.
4. What package would you like to yank? You supply the rest of package name, known at the “slug”, namely: tove.
5. Approved! Success! You’re authenticated on the basis of owning of slithy and therefore assumed also to be the owner of slithy-tove.

In other words, the package manager perhaps naively expected that anyone creating a hierarchy of packages would set out to own all the partial package names in that tree.

In real life, that is indeed what many programmers or projects teams would do, either by design, or simply as a consequence of how the project had evolved.

For example, if you intended to produce a collection of packages under the top-level name acme, you might make yourself the owner of all package names and prefixes in the tree, so that you also controlled all possible partial names for any of your code modules:

 acme acme-formatter acme-formatter-HTML acme-formatter-text acme-formatter-PDF acme-deformatter acme-statscounter

As you can imagine, if you used the name of your organisation as the leftmost text, you’d almost certainly ensure that you “owned” that name outright, if only to stop imposters creating new projects that looked as though you’d endorsed them yourself.

But there is no RubyGems requirement to do things that way.

If you didn’t want or need to take ownership of the leftmost part of your package name (perhaps because your code was a general-purpose toolkit such as generic-formatter), your package could have been at risk of takeover by someone sneakily creating a package called generic.

Clearly, that means anyone else in the supply chain who relied on your package would have been at risk of compromise, too.

Specifically, as the security bulletin reports:

To be vulnerable, a gem needed: one or more dashes in its name; an attacker-controlled gem with the name before the dash; creation within 30 days OR no updates for over 100 days.

What to do?

• As a Ruby or RubyGems user, you don’t need to update any package manager code on your end.

The vulnerability existed on the server side, and has been fixed by the RubyGems team.

Apparently, the server no longer assumes, if you authenticate as the owner of slithy, that you can be assumed also to own slithy-tove.

As the RubyGems team advises, you can check for rogue changes in your own packages by checking your Gemfile.lock history for changes that kept the same name and version number.

Also, any packages that have a single-word name (no dash), and any packages where you own the “name prefixes” as well as the package itself (e.g. if you own slithy for a package called slithy-tove), are immune to this bug.

Likewise, any package that you’ve never left alone for more than 100 days without pushing out an update can apparently be assumed safe, along with any new package created less than 30 days before bug was fixed [2022-05-05].

• As a programmer, make sure, whenever you’re testing that user X is allowed to perform action Y, that you aren’t accidentally testing for a less restrictive permission instead.

As as example, if you want to answer the question, “Is user X allowed to list the filenames in directory Y?”, it’s not enough to check that they’re allowed to enumerate files in some higher-level directory Z, and from there to assume the permission percolates downwards automatically.

If that were a necessary and sufficient test, you could verify every user’s access to any file on the system simply by checking if they were allowed to read filenames in the root directory. Loosely speaking, however, all users can do that, or else the programs they ran wouldn’t be able to navigate to files in vital public-but-write-protected system directories, such as /lib64/libc-2.35.so or C:\Windows\System32\gdi32.dll. But their right to enumerate the root directory doesn’t mean they’re allowed to list all the files under your home directory as well.

• As a programmer, don’t be afraid to re-verify user permissions before every important change.

Don’t assume that the permissions that authenticated user X to perform task A at point B in your code are inevitably still valid later on, especially when it comes to performing a similar-but-nevertheless-different task C at some other point D in your code.

As the principle of zero trust has is: assume nothing; verify everything.

Remember the jokes (OK, they were sold as “jokes” when you were at school to add a touch of excitement to Eng. Lang. lessons) about creating valid and allegedly meaningful sentences with a single word repeated many times?

There’s an very dubious one with the word BUFFALO seven times in a row, which relies on the various meanings Buffalo-the-placename, referring to the riverside city in New York State; buffalo-the-bovine-beast, also known as a bison; and buffalo-the-metaphorical-verb meaning “to bully or intimidate.”

There’s a slightly less bizarre sentence with HAD repeated a whopping 11 times, which imagines a Latin grammar lesson in which pupils are asked to compare the ancient Roman perfect tense, often translated with “had”, and the pluperfect, commonly translated as “had had”.

But the best known, and perhaps the most believable, is five ANDs in a row, a sentence helped by the fact that AND is a conjuction, so with a suitable comma you can insert it between almost any two English sentences and produce a legal compound clause.

Thus the famous complaint by the innkeeper who’s just had their pub sign repainted badly, and disappointedly tells the signwriter, “You didn’t leave enough space between ROSE and AND, and AND and CROWN.”

Well, in an amusing start to the weekend, Google Docs has apparently just fixed a five-ANDs-in-a-row crisis in its online, real-time grammar checker.

Apparently, until Google quickly fixed the problem earlier today, entering five ANDs in a row was considered a sufficiently grievous conjunctional blunder that entering such a sequence into your browser…

…would instantly crash Google Docs.

Recursion: see Recursion

To be slightly more precise, it seems that the bug only appeared if you had grammar checking turned on.

If you never had it on, or if you had had it on (we couldn’t resist trying out a pluperfect there) but later turned it off, you’d be OK.

Also, the ROSE AND CROWN sentence above wouldn’t do it, because you had to commit the solecism of using AND in a sentence all of its own five times in a row, with a leading capital letter each time, like this:

 And. And. And. And. And.

What happened?

The original reporter uncovered a curious but inconclusive error message in the background that said, TypeError: Cannot read properties of null (reading 'C'). (No, we don’t know what sort of ‘C’ that refers to.)

We’re guessing that some of recursive grammatical parsing function hit some untested internal limit, such as unexpectedly running out of input data, not having enough storage space left over to carry on its anlysis, or blundering into a dead-end street in some convoluted grammatical state machine.

The internet (especially the weekend-is-coming-soon-internet) being what it is, keen Google Docs users promptly set out to find other grammatical constructs that might also trigger the bug, quickly finding that other conjunctions, if used unexpectedly in five consecutive solo sentences, would do the trick.

The words ANYWAY, BESIDES, BUT, HOWEVER, THEREFORE, WHO and WHY were quickly added to the trigger-list, but human-based guessing wasn’t enough for one Ycombinator user, who decided that a problem this obscure deserved more extensive and automated research.

Hacker News contributor JoshuaDavid wrote that they “started running through the entire dictionary in batches of 500 words to see if each batch of 500 triggered the behaviour, then binary search[ed] within the batch to find the problem word(s). Got bored partway through D.”

Bored. Unbored.

Fortunately, JoshuaD reports that they soon became “unbored”, and decided to start where they left off, resuming their dictionary divide-and-conquer project at the letter E.

Intriguingly, they found that the numerical adverbs FIRSTLY, SECONDLY, THIRDLY and FOURTHLY all caused the document crashing problem, but not the adverbs of any higher numbers, such as FIFTHLY or FOURTEENTHLY, which is admittedly not a word you need to use very often.

What to do?

Google hasn’t yet said what caused the bizarre bug, but it did quickly say it was “working on a fix”, and reports suggest that the fix is already in.

We’re don’t use Google Docs ourselves, and we tend to turn grammar checkers off because we find that today’s “writing assistants” seem happiest when everyone writes in the same, predictable way, which feels dull to us…

…so we don’t know whether you need to take any special measures if you have any genuine documents that were victims of this crash before it was patched.

Internet commenters proposed various workarounds while the bug was still in play, including opening buggy documents on your mobile phone (where the problem didn’t show up) in order to edit out the crashtastic text, thus making the file safe again to open in your browser.

Other “fixes” were to turn off grammar checking, create at least one new document, then open the ones that you couldn’t open before without re-crashing the document.

We’re assuming, now that the bug is fixed or at least suppressed in Google’s cloud code, that you can simply re-open crashy documents and carry on where you left off.

Oh, and if you hear what actually happened, please let us know in the comments… we suspect that the backstory will be a fascinating tale!

LISTEN NOW

• [00’23”] Fun Fact. What comes after “123”?
• [01’57”] World Password Day. (We still need it!)
• [04’20”] GitHub authentication troubles.
• [11’55”] This Week in Tech History. Sasser, the sassy Windows worm.
• [15’55”] Firefox hits a ton.
• [20’03”] Ransomware stats – how much do attacks cost?

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

Listen on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found.
Or simply drop the URL of our RSS feed into your podcatcher.

Back in the late 1960s and the start of the 1970s (or so we’ve heard), primary school children in the UK got a special treat.

Unlike their parents and grandparents before them, they were exempted from learning how to do calculations involving money.

Their teachers were no longer expected to show them how to do the confusing and needlessly complex sums required when working with the UK’s “old money”, even though it was still the official currency.

Widely referred to as LSD, short for the old Latin words librum, solidus and denarius, the units of Pounds, Shillings and Pence (itself an archaic alternative form of the word pennies) made up the strange monetary system of the day.

There were twelve pence in a shilling, and 20 shillings in a pound, so even simple shopping tasks in Britain used to require familiarity with decimal, duodecimal and vigesimal numbers, or base 10, base 12 and base 20 respectively.

Also, the coins not only had a mishmash of historical names, including florins, half-crowns and thr’p’ny bits, but also a curious array of values: 0.5d, 1d, 3d, 6d, 1 shilling, 2 shillings, 2.5 shillings and 5 shillings.

The reason for this late 1960s pedagogical exemption from learning about LSD was obvious: the “old money” was scheduled for blanket replacement in 1971.

A much simpler decimal currency of 100 pence to the pound was on the way, with a more predicable progression of coins going 0.5p, 1p, 2p, 5p, 10p, 50p. (For some reason, the 20p coin was omitted at first and didn’t come out for a further 11 years; the minuscule 0.5p coin vanished forever in 1984.)

Why bother?

Why bother learning the intricacies of a counting system that had next to no life left in it, and that would ultimately not be missed for a moment even by people who thought it would be a wrench to leave behind?

Well, that’s where some people seem to think we are with passwords right now.

No one likes passwords; everyone is gasping to leave them behind; and the technology marketplace is promising a perfectly passwordless future any time now.

So why bother with World Password Day when we’re soon going to have a great big World Password Bonfire…

… and replace passwords with something else that’s easier and better?

Real soon now

In fairness, it’s OK to assume that passwords are ultimately going to to be replaced, but only if you also remember to ask the important question, “When?”

We suspect, though we’d love to be wrong, that we’ll take delivery of our Permanent Password Replacement Device at the same time that we get the personal jetpacks, the flying cars and the self-ironing shirts that everyone was promised back in the day…

…way back in the day, in fact, when that previous generation in Britain was being promised “new money”.

Britons, of course, did get their decimal currency as planned, but the other technological marvels that were “expected soon” have turned out to be “a few years away yet” ever since.

And that’s why we still support the idea of World Password Day here on Naked Security, because our passwordless future is still largely in the future.

We think that we’re likely to be stuck with passwords on at least some of our accounts, if not most of them, for several years yet.

So we might as well do the best job we can with the “old money” password technology that we still rely upon today.

The problem with passwords

The problem with passwords is that if they’re hard for criminals to guess, they’re also hard for you to remember.

So, if you’ve fallen into the bad habit of choosing easy passwords, or if you repeat the same password over and over again, switch to using a password manager instead.

Password managers can make up weird and complex passwords automatically, mixing up All S0rts! OF Ch*r@cters, and can remember those passwords securely so you don’t have to.

Also, password managers don’t remember websites by what they look like (something criminals can easily copy), but by matching the exact website name.

Fake web pages, known as “phishing sites” because they try to reel you in like an angler and capture your password, won’t fool your password manager, even if the crooks come up with a website that looks very similar to the real thing.

You might be tricked by a website name containing the digit one (1) instead of the letter I, or the digit four (4) instead of A, but a password manager won’t, so you’re much less likely to put your real password into a fake website by mistake.

Of course, you will need a really strong password for the password manager itself, but you can use a series of words or a passphrase instead of just a single word, as explained in our popular How To Pick A Proper Password video:

[embedded content]

If in doubt

As we said above, even though lots of companies claim to be working on technologies to replace passwords completely, we think that passwords will be an unavoidable and necessary part of our everyday digital life for many years yet.

So it’s still worth learning how to pick proper passwords, and how to avoid getting tricked by bogus phishing messages that lure you onto fake login sites to steal your login details.

Remember, not just on World Password Day, but every day: If in doubt, don’t give it out!

Google’s May 2022 updates for Android are out.

As usual, the core of Android received two different patch versions.

The first is dubbed 2022-05-01, and contains fixes for 13 CVE-numbered vulnerabilities.

Fortunately, none of these are currently being exploited, meaning that there are no zero-day holes known this month; none of them directly lead to remote code execution (RCE); and none of them are flagged as Critical.

Nevertheless, at least one of these vulnerabilties could allow an entirely innocent-looking app (one that needs no special privileges at all when you install it) to attain what amounts to root level access.

If you’re wondering why we aren’t giving you specific CVE numbers for the most serious vulnerabilities, that’s because Google itself doesn’t detail which vulnerabilities present what risks, but instead merely states the potential side-effects of “the most severe vulnerability” in each group of bugs.

The second tranche of updates is dubbed 2022-05-05, an official identifier that covers all the patches provided by 2022-05-01, plus 23 more CVE-numbered bugs in numerous parts of the operating system.

Components affected by these bugs include the Android kernel itself, along with various closed-source software modules that are provided to Google by hardware makers MediaTek and Qualcomm.

Non-unified patches

Ideally, Google wouldn’t split the monthly updates apart in this fashion, but would provide a single, unified set of patches and expect all vendors of Android devices to get up-to-date as soon as possible.

However, as the company admits in its bulletins, there are “two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly.”

We can understand Google’s approach, which presumably reflects the assumption that it’s better if everybody fixes at least something and some vendors fix everything…

…than if some vendors fix everything but others fix nothing at all.

Nevertheless, Google publicly notes that “Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.”

In the modern vernacular, our opinion on this issue is simple and clear: +1.

The sting in the hardware

Although there’s an open-source distribution of Android known a AOSP (short for Android Open Source Project), the Android distribution you’re running on your phone or tablet right now almost certainly includes numerous closed-source components.

Google Android, for example, is a bit like Apple’s iOS inasmuch as it’s based on an open-source kernel and a plethora of low-level open source tools, but with various proprietary modules, application programming interfaces and apps layered on top of that.

But even third-party Android versions usually include numerous closed-source software modules, for example to operate the low-level hardware in the device, such as the mobile phone radio (code for which is strictly and variously regulated in most countries), Wi-Fi, Bluetooth and so on.

Unfortunately, this month’s 2022-05-05 patches include a fix dubbed CVE-2021-35090 that is denoted Critical, but about which no public information is available.

Google says no more that that this bug, plus a further ten 2021-era CVE bugs, are “vulnerabilities [that] affect Qualcomm closed-source components.”

Not even Google, it seems, knows what was fixed in Qualcomm’s binary “blobs”, or if it does, it’s not saying.

We’re therefore assuming that any bug deemed Critical involves some sort of remote code execution (RCE), and could therefore result in a remote attacker sneaking spyware or other malware onto your device without needing any sort of tap-or-click assistance on your part.

Blob, if you’re wondering, is a jargon word from BLOB, a comedy acronym for Binary Large Object, a name that’s meant to remind you that even though you need it and use it, you will probably never be quite sure how it works, how it’s structured, or even what it’s actually for.

Additional details for Pixel users

Owners who not only have Google Android but also use Google hardware (Pixel 3a and later) already have Pixel-specific updates available, including patches for 11 addditional CVE-numbered bugs, two of which are deemed Critical.

Ironically, the two critical Pixel bugs are in critical low-level components, as follows:

• CVE-2022-20120. Remote code execution (RCE) in the bootloader. The bootloader is a vital part of Android system integrity, and is locked by default against any sort of modification. You can unlock the bootloader on Pixel devices to install an alternative, non-Google operating system, but every time you unlock (or re-lock) the bootloader, all user data is forcibly wiped from the device in a so-called factory reset. This prevents someone who steals your phone from swapping out the underlying operating system for a Trojanised version and then returning the device to you apparently unmodified with all your original apps and data in place. A bootloader RCE bug suggests that a determined attacker might quietly and invisibly be able to compromise an unpatched device, given a few minutes of physical access and a USB cable.
• CVE-2022-20117. Information disclosure in the Titan-M component. The Titan-M chip is Google’s hardware security module, which is supposed to provide tamper-proof secure storage of cryptographic keys and other secret data. Attempting to extract the chip from a device and then to extract raw data from the chip itself is supposed to be impossible, because the chip destroys or blanks itself out if accessed in unofficial ways. An information disclosure bug in a hardware security module is therefore always a critical matter, because the module is specifically designed to keep secrets.

What to do?

A bootloader bug, a data leakage hole in a dedicated security chip, a flaw that could allow the most innocent-looking app to go rogue, and a critical vulnerability in an undisclosed component used in an unknown range of Android devices means…

…patch early, patch often. (And yes, we always say that, which is why we said it here!)

On most Google devices, including many if not most non-Google Android variants (we’re using GrapheneOS), you can check for updates and fetch them on demand by going to System > System update > Check for updates.

To find the exact details of your current Android kernel, version number and security patch level, go to System > About phone > Android version.

Ideally, you’re looking for the 5 May 2022 security update (this corresponds to the all-encompassing 2022-05-05 patch level above), and a kernel showing a build date of early May 2022, as seen below.