Perpetual IT

Regular readers of Naked Security will know that one of the truisms we like to trot out about cybersecurity is the wryly self-contradictory reminder that you should “Never say never.”

Indeed, when it comes to programming, the only time that you should ever say, “This will never happen” is if you can show, in a formal way, for example with an accepted mathematical axiom or a proof, that it will quite literally never happen because it can’t.

For example, when a C compiler looks at this code…

 unsigned int i = 0; while (i >= 0) { i = the_next_value_of(i); }

…and warns you that your while loop will never terminate, it really can and should use the word never.

A variable declared unsigned can, by definition, never be negative and therefore the “conditional” expression i >= 0 isn’t conditional at all: it can be replaced by the constant 1, or TRUE, and can literally never be FALSE.

But there are many other programming cliches where coders ignore errors that might happen in theory, often for one or more of these reasons:

• This bug is so incredibly unlikely, and catering for it would so complex, that the code is more likely to be bug-free if you simply assume that the error will never happen. (What could possibly go wrong?)
• This bug is sufficiently unlikely, and simulating it correctly in testing would be sufficiently hard, that ignoring the error is a justifiable “technical debt” that is worth borrowing against now to meet a delivery deadline. (Let’s come back and fix it later if anyone notices.)
• This bug is only ever likely to happen if something else even more catastrophic has already happened, so there is no point in worrying about it now. (No point in rearranging the deckchairs on the Titanic.)

Examples include: assuming that occasional and short-lived allocations of tiny amounts of some abundant system resource will always succeed; assuming that two processes will never accidentally choose the same random filename; and assuming that 640KBytes of memory should be enough for anyone.

Another example, perhaps the one that best supports the motto simply never to say never, is assuming that two digits is enough to store the year, so that you can just write 83 instead of 1983, or 21 instead of 2021, and nothing bad will ever happen.

How much do shares cost?

So, with memories of Y2K firmly in mind (or stories of it, if you’re young enough ), let’s play a game.

What’s the largest value in US dollars that a single share, in any publicly traded company anywhere in the world, could ever reach, and then some?

In other words, if you had to pick an amount that would safely encompass the value of any share you needed to report upon, now and in the lifetime of your program, how high would you go, and then how much safety margin would you build in for the future?

After all, many hugely wealthy and successful companies have stock prices well below $10,000, because they want to avoid having share prices that are out of reach of all but the biggest investors.

They therefore deliberately reduce the price per share without changing the value of the company by using “stock splits” to convert, say, 1 share costing $1000 into 5 shares of $200 each.

The idea is much the same as asking a bank teller to give you five $20s instead of one $100 – the total amount is the same but the lower value of the bills makes them easier to use in stores.

Apple, for example, has split five times since 1987 (2-for-1 in 1987, 2000 and 2005; 7-for-1 in 2014; and 4-for-1 in 2020), so that one original Apple share has now turned into 2x2x2x7x4 = 224 contemporary shares, each worth 1/224th part of the original.

But you may be surprised just how high some individual share prices are.

UK clothing chain Next is currently worth more than $10,000 a share on the London Stock Exchange, for example, and Swiss chocolatiers Lindt are currently trading at over $100,000 a share on the SIX Swiss Exchange. (FYI, we checked at 2021-05-10T16:45Z.)

So if you wanted to record share prices with an accuracy of 1/100 of a US cent (one ten-thousandth of a dollar), you’d need to be able to represent numbers up to and beyond 1,000,000,000 (one billion) , because there are one billion ten-thousandths of a dollar in $100,000.

It’s easier to figure out if you work with exponents and notice that 100,000 = 10⁵ and 10,000 = 10⁴, i.e. 1 followed by 5 zeros and 4 zeros respectively. When you multiply them together you get 10⁵x10⁴ = 10⁵⁺⁴ = 10⁹, and a billion has 9 zeros.

DWORDs will do

You could get away with using a 32-bit unsigned binary integer, often referred to as a DWORD, short for double word, where a WORD is 16 bits, or two bytes.

DWORDS can store 2³² different values starting at zero and ending at 2³²−1 (the “minus one” comes from the fact that you need to start counting at zero, which uses up one of the possible values).

And 2³²−1 = 4,294,967,295, which assembler programmers will tell you off the top of their heads, although they cheat by using base 16 (hexadecimal), where the value just happens to come out as the easily-remembered 0xFFFFFFFF (the 0x prefix is C shorthand that denotes hexadecimal).

So if you use a 32-bit unsigned integer that takes up four bytes of memory, you can exactly represent any share price from $0 to $429,496.7295, if you count in 1/100ths of a cent.

Of course, most computers these days happily and efficiently handle 64-bit integers in calculations, but they consume eight bytes each, and given that Lindt and Next are amongst the priciest shares you can buy right now, more than half the bits in every share price you stored would in theory be wasted if you went for 64 bits instead of 32.

So, coders at Nasdaq apparently settled (probably years ago, when 2³² was still considered a huge number, and 4GByte of RAM was still a truly enormous amount) on 32-bit numbers to store their share prices in 1/100ths of a cent.

What could go wrong?

The problem, however, is that the most expensive individual share you can buy right now is not Next or Lindt, but BRK-A, the ticker abbreviation for Warren Buffett’s famous Berskshire Hathway Inc.

And those shares, when last we looked, cost an eye-watering $442,512 each, which comes out at 4,425,120,000 ten-thousandths of a dollar, or 0x107C1F900 in hexadecimal, up from just over $400,000 a month ago.

Let’s do that in binary, so you can see that in the past few days, the BRK-A value now needs a 33-bit number, and won’t fit into 32 bits any more:

 ---| |--------------------32 bits-----------------| 1 0 7 C 1 F 9 0 0 0001 0000 0111 1100 0001 1111 1001 0000 0000

If we failed to check for that integer overflow into the 33rd bit and just used the bottom 32 bits of the result without realising that our calculation was no longer valid, the BRK-A price would have turned out as 0x07C1F900 instead:

 ---| |--------------------32 bits-----------------| ? 0 7 C 1 F 9 0 0 ---- 0000 0111 1100 0001 1111 1001 0000 0000

That comes out at 130,152,704 ten-thousandths of a dollar, or just over $13,0000, and you’d need to go back to 1993 to be able to get a BRK-A share at that price.

What to do?

The New York Stock Exchange (NYSE), on which BRK-A shares are actually listed, doesn’t seem to store its prices the same way as Nasdaq, and therefore wasn’t affected by the BRK-A price climbing to $429,497 and beyond.

Nevertheless, Nasdaq provides stock price reports for lots of exchanges, and if it had suddenly started pricing BRK-A at a tiny fraction of its real value, it would have created at least some confusion and trouble, if only for Nasdaq’s PR team.

The good news, however, is that Nasdaq simply stopped reporting the BRK-A price until it had introduced a fix (or at least a workaround) for this issue, thus turning what would have been a bug causing misinformation into a problem causing an outage.

Make sure you do the same in any code you write.

When it comes to cybersecurity, a program that knows it has gone wrong and deliberately stops saying anything at all can be considered much better behaved, and therefore more correct, than software that cheerfully and confidently reports incorrect data in blissful ignorance and ends up misleading you.

Your code should carefully check for possible problems not only when errors are likely but also, perhaps especially, when those errors are unlikely.

Your code review process and testing need to take this into account, too.

Even when correct code is perfectly easy to write in theory, incorrect code often triumphs because it is not only easier but also quicker to write in real life.

Don’t do that!

Never, in a word, say never.

---

Usually, when browser updates come out, it’s obvious what to do if you’re running that browser on your laptop or desktop computer.

But we often get questions from readers (questions that we can’t always answer) wondering what to do if they’re using that browser on their mobile phone, where version numbering is often bewildering.

In the case of Firefox’s latest update we can at least partly answer that question for Android users, because the latest 88.0.1 “point release” of Mozilla’s browser lists only one security patch dubbed critical, namely CVE-2021-29953:

This issue only affected Firefox for Android. Other operating systems are unaffected. Further details are being temporarily withheld to allow users an opportunity to update.

The bug listed here is what’s known as a Universal Cross-site Scripting (UXSS) vulnerability, which means it’s a way for attackers to access private browser data from website X while you are browsing on booby-trapped website Y.

That’s definitely not supposed to happen.

Your browser is supposed to stop data such as cookies “leaking” between websites, or else site Y could peek at data such as your login details for site X, and abuse that site-specific data to masquerade as you on site X and hijack your account.

Browsers are supposed to enforce the aptly-named Same Origin Policy, or SOP, whereby locally-saved web data is locked down so it can only be read back in later on by the same website that saved it in the first place.

This helps to maintain security and privacy by preventing websites from leeching information about each other’s users.

XSS bad, UXSS worse

One trick often used by crooks to violate the SOP is plain old Cross-site Scripting (XSS), which is the name given to any JavaScript-based privacy flaw that affects a specific website.

Imagine, for example, that I can trick your website into serving up JavaScript of my choosing, for example by sneakily embedding some JavaScript in a search link in such a way that your server erroneously reproduces my unmodified JavaScript in any replies sent back to those who click on that link.

Even though it’s my script, it came back from your server, so my code passes the “same origin policy” test, giving me access to data about your users that I shouldn’t be able to see.

That’s an XSS.

But UXSS is the name given to a cross-site scripting flaw that is caused by a bug right inside your browser, not merely a bug on one specific website.

Loosely speaking, a UXSS is an XSS risk that applies wherever and whenever you browse, typically even when you visit well-maintained web servers that are themselves secure against site-specific XSS attacks.

So this is definitely an update you want if you use Firefox on Android.

If you go out in your car and one of the many drivers you encounter is careless and could get you into an accident, that’s a bit like the risk of XSS. You can always watch out for and do your best to avoid the careless ones. But if you yourself are that careless driver… that’s like the risk posed by UXSS, because it goes along with you everywhere.

What to do?

Despite knowing for sure that an updgrade to 88.0.1 is what you need, we still aren’t sure exactly how you check you are up to date.

For example, Google Play [2021-05-06T13:10Z] is currently offering us version 88.1.3, which it claims was updated on 05 May 2021.

That sounds “better” than 88.0.1, but given that there is no 88.1 version on offer for our laptops, it’s not clear whether 88.1.3 includes the 88.0.1 fix or not.

Even worse, when we clicked on the [Full Release Notes] link directly under the version number of 88.1.3, we ended up on the Firefox 88.0 page, giving a release date of 19 April 2020, which is the same day that 88.0 (definitely not 88.0.1!) came out for non-mobile platforms too.

All we can say is, “Get the update from Google Play if you can, but make sure you check back regularly just in case.”

And to all the browser makers out there, we’d like to ask, “Please will you make it easier for us and our readers to match up the browser version numbers on our mobile phones with the release notes that we rely upon for our laptops and desktops?”

By the way, 88.0.1 isn’t just for Android – you need to update if you are using other operating systems, too.

The 88.0.1 release includes a second security patch, dubbed CVE-20210-29952 and rated High, that fixes a bug that no one has figured out how to exploit yet, but that someone might yet work out how to “weaponise” to implant malware.

---

Researchers at SentinelLabs say that they found various exploitable bugs in one of Dell’s Windows kernel drivers, which they reported back in December 2020.

There were five related bugs, now collectively dubbed CVE-2021-21551.

Dell has now issued a patch for these vulnerabilities (the official update is dated 2021-05-04), noting that:

Dell dbutil_2_3.sys driver contains an insufficient access control vulnerability which may lead to escalation of privileges, denial of service, or information disclosure. Local authenticated user access is required.

Expunging the bugs

The good news, therefore, is that even though these bugs are dangerous, they don’t let cybercriminals break into your network in the first place, and they’ve now been fixed.

The bad news, however, is that the bugs seem to go all the way back to 2009, with the result that Dell’s official list of affected products stretches for pages and pages.

Dell’s documentation is split into two lists of devices that need updating:

• Table A: Supported Dell platforms. There are 381 model names here, including Dell brands such as Inspiron, Latitude, OptiPlex, Precision, Vostro. XPS and even some Dell Dock devices.
• Table B: End of Service Life Dell platforms. A further 195 model names are listed, including seven Alienware computers.

Dell has included instructions for manually removing the buggy kernel driver, which it says will be found in one of two places:

 C:\Users\%USERNAME%\AppData\Local\Temp\dbutil_2_3.sys C:\Windows\Temp\dbutil_2_3.sys

If you are nervous about removing system files by hand, the company has published a download page with an automatic driver remover with the remarkable name of Dell-Security-Advisory-Update-DSA-2021-088_7PR57_WIN_1.0.0_A00.EXE.

Unfortunately, just removing the old driver is not enough on its own, because the old firmare update utility left behind on your computer may inadvertently reinstall the buggy driver, thus reintroducing the bug.

According to Dell, you also need to download and install an updated firmware update program that knows about and includes a patched version of the flawed dbutil_2_3.sys kernel module.

Updated firmware updaters are available right now for Windows 10, but for earlier Windows versions (Dell still supports both Windows 8.1 and Windows 7, it seems), the update-to-the-updater will only be available “by 31 July 2021.”

In other words (and although this sounds tricky, it’s more a question of fuss than complexity):

1. Get rid of the old dbutil_2_3.sys driver, either by hand or using Dell’s dedicated tool-with-a-very-long-name.
2. Update the Dell firmware update utility, assuming that an update is available.
3. If you can’t yet do step 2, remember to repeat step 1 every time that you run the old firmware updater, in case the update process itself quietly reinstalls the old driver.

What harm could the buggy driver do?

The researchers who investigated the flawed driver found a number of problems with it, starting with the fact that any user, whether an administrator or not, could issue low-level configuration commands to the driver itself.

That’s not automatically a bug, as long as the scope of those configuration commands is carefully limited.

As an example, a security program with a driver that allowed unprivileged users to issue a command to opt in to increased protection would probably be considered OK, but one that allowed anyone to opt out of protection whenever they felt like it would clearly be no good at all.

However, in this case, the researchers discovered driver coding flaws that could allow unprivileged driver commands either to crash the driver and bring down the system (denial of service) or to promote the user issuing the commands to a local administrator (elevation of privilege).

Although those coding bugs would have needed fixing anyway, their impact would have been much less serious if attackers who wanted to exploit them needed to have administrator privileges already.

After all, if you already have sysadmin powers, you don’t need an elevation of privilege bug because you already have elevated privileges.

Interestingly, the researchers also noted that it might be possible to abuse one of the bugs in dbutil_2_3.sys to write to the hard disk in undocumented, low-level ways, bypassing the usual Windows system calls for disk access.

Given that a user with administrator powers could probably write pretty much anywhere on your hard disk anyway, this issue doesn’t add much extra danger over and above the elevation of privilege bug that already exists.

In theory, however, this flaw could be abused by attackers who were already administrators in order to access or manipulate data without using a conventional sequence of system commands, thus potentially bypassing various logging or security settings that might otherwise catch them out.

---

LISTEN NOW: UNDERSTANDING VULNERABILITIES

Learn more about vulnerabilities, how they work, and how to defend against them.
Recorded in 2013, this podcast is still an excellent and jargon-free explainer of this vital topic.

Click-and-drag above to skip to any point in the podcast. You can also listen directly on Soundcloud.

---

Bring Your Own Bug

Another obvious problem with this driver is that it lives either in your own or the system’s TEMP directory, where an attacker who is already in your network could easily overwrite it with an older, buggier version in order to force what’s known as a downgrade or a BYOB (bring your own bug) attack.

Remember that attackers can’t easily install their own malicious kernel drivers these days, because those drivers would need to be submitted to Microsoft first to be digitally signed.

(Not even sysadmins can load unsigned kernel drivers any more on 64-bit versions of Windows without rebooting into a special startup mode used for driver testing; on the next reboot after that, signed driver enforcement is automatically re-enabled.)

However, canny cybercrimimals sometimes try to install old-but-signed drivers quite deliberately in order to reintroduce old vulnerabilities, notably elevation of privilege or other security bypass bugs that you thought you’d patched long ago.

In other words, if you remove the vulnerable driver without also updating the firmware update utility that is coded to look for the driver in the TEMP folder, you run a risk not only that the firmware utility itself might reinstall an old version of the driver, but also that an attacker already inside your network might do so, too.

We assume that Dell’s updated firmare update tool (see step 2 above) not only includes a patched driver but also installs that driver in a safer place.

As mentioned above, however, you can’t update Dell’s firmware utility yet if you have Windows earlier than version 10.

We therefore recommend that you keep your eye out for the reappearance of a file called dbutil_2_3.sys in either of the TEMP locations listed above, in case your system gets downgraded, either by accident or by design.

What to do?

• If you are a user: visit the relevant security advisory page on Dell’s website and follow the instructions to remove the buggy driver. Also update the entire Dell firmware update utility as soon as you can, which is right now for Windows 10 and some time before 31 July 2021 for earlier versions of Windows.
• If you work in the cybersecurity operations team: check your hardware inventory against Dell’s list of affected models to make sure you don’t miss any. Make a list of computers that needed updating and keep an eye on the abovementioned TEMP directories for the unwanted reappearance of the buggy driver file, which could be an IoC (indicator of compromise).
• If you are a programmer: don’t give unprivileged users access to driver control functions they don’t need. Poor access control was not the root cause of the bugs in this case, but stricter access to the driver itself would have mitigated the risk by restricting the privilege escalation exploits to users who were already privileged anyway.
• If you work in quality assurance or in the code review team: make a regular habit of revisiting legacy driver code. Loosely speaking, the older a driver, the less likely that it was originally coded in accordance with contemporary attitudes to and guidelines for cybersecurity.

---

It’s only a week since Apple’s last product updates, but it’s already time to update again.

As you probably know, Apple, unusually amongst major operating system and application producers, doesn’t have any sort of predictable schedule for its security patches.

Unlike vendors such as Microsoft (monthly), Google Android (monthly) and Mozilla (every fourth Tuesday), security updates emerge from Cupertino HQ whenever Apple thinks the time is right.

And unlike Linux, where updates come thick and fast but you can at least track the issues that are being worked on at any moment, Apple’s updates arrive not only as-and-when, but also under an official cloak of undisclosure:

For the protection of our customers, Apple doesn’t disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are generally available.

Stony-faced silence

As we’ve said before, Apple rarely deviates from this stony-faced silence, which can be annoying when there’s a security problem in Apple’s code that is commonly known and already being discussed widely, yet the company still won’t say whether it’s working on a fix at all.

After all, if you’ve reported what you think is a bug but you don’t hear anything more about the issue, it’s hard to know where you stand.

Were you wrong, and it wasn’t a bug after all?

Are you being ignored because no one even noticed your report?

Or is the bug so deep and complex that it simply can’t or won’t be fixed and no one is ever going to tell you?

This time, the reason for the latest patches, which apply to macOS, iOS, iPadOS and watchOS, is clear, because four CVE-numbered critical bugs have been squashed, described as follows:

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.

Shortened into contemporary jargon, that means “drive-by, web-based zero-day RCE exploit.”

Drive-by attacks

Drive-by means that just visiting a website and viewing it is enough to trigger the bug, so you only need to be lured onto a booby-trapped site to take a look.

The crooks don’t need to lure you in and then also convince you to download and run a file, or to install a browser plugin, or to enter loads of personal data into an online form you didn’t expect.

Web-based means that the attack can happen right inside your browser, despite all the sandboxing and other protection that is supposed to keep browsing safe.

Zero-day means that there were zero days that you could have patched in advance, because the crooks found and started exploiting the bug first, before a patch was available.

And RCE means just what it says, namely remote code execution, where the crooks get to run remotely supplied code of their choice, decided at the time you visit their booby-trapped website.

Loosely speaking, RCE means not only that the crooks can inject and install malware onto your computer without any warnings or popups that would otherwise tip you off, but also that they can vary their attack as they choose.

Four squashed bugs

The squashed bugs are:

• CVE-2021-30665: A memory corruption issue was addressed with improved state management.
• CVE-2021-30663: An integer overflow was addressed with improved input validation.
• CVE-2021-30661: A use after free issue was addressed with improved memory management.
• CVE-2021-30666: A buffer overflow issue was addressed with improved memory handling.

Interestingly, the bug dubbed CVE-2021-30661 was already patched on 2021-04-26 (a week ago) in iOS 14.5 and macOS 11.3, but not in iOS 12, which didn’t get an update at that time.

From this, you might have inferred that the security hole was introduced to Apple’s codebase after iOS 12 came out, and therefore didn’t apply to the older iOS 12 version at all.

However, that turns out not to have been the the case, given that the CVE-2021-30661 and CVE-2021-30666 bugs fixed this time are listed as applying only to iOS 12.

As far as we can tell, no bug matching CVE-2021-30666 has yet been patched in iOS 14 or macOS 11, which once again leaves us wondering, given Apple’s notorious “no comment” attitude to the bugs it is working on, whether this bug exists in Apple’s more recent operating system versions or not.

Is this an old bug from iOS 12 that was carried forward into the current Apple codebase but has still not yet been patched there?

Or is it a bug that is unique to the older iOS 12 code that doesn’t appear in the more recent operating system releases and can therefore now be considered to have been eliminated everywhere?

Reminder. There is no iOS 13 any more. Older devices are stuck with iOS 12, which is still getting patches. But any Apple device that supported iOS 13 when it came out must now be upgraded to iOS 14.5.1 in order to be up to date with security fixes. That’s because iOS 14 replaced iOS 13, which is no longer supported at all and therefore dangerously far behind on security updates.

What to do?

Don’t delay. Get the updates today.

Even if the “in the wild” exploits for these vulnerabilities are known only to selected crooks who are keeping them carefully up their sleeves and using them only in highly targeted attacks…

… that’s no reason to be complacent about updating.

After all, security holes that one lot of crooks already know about could just as well be rediscovered, or be bought, or get stolen, by someone else.

(Don’t forget that the infamous ETERNALBLUE exploit, notoriously abused by the WannaCry virus, was apparently stolen from the US National Security Agency, even though the NSA had every reason to keep it to itself, well, eternally.)

In other words, why stay one step behind known attackers when you could move ahead?

On iDevices, go to Settings > General > Software Update.

On a Mac, it’s Apple menu > System Preferences > Software Update.

If you’re already up to date, then the updater will say so; if not, it will offer you an immediate opportunity to catch up.

---