Perpetual IT

Google’s latest Chrome browser, version 105, is out, though the full version number is annoyingly different depending on whether you are on Windows, Mac or Linux.

On Unix-like systems (Mac and Linux), you want 105.0.5195.52, but on Windows, you’re looking for 105.0.5195.54.

According to Google, this new version includes 24 security fixes, though none of them are reported as “in-the-wild”, which means that there weren’t any zero-days patched this time.

Nevertheless, there’s one vulnerability dubbed Critical, and a further eight rated High.

Of the flaws that were fixed, just over half of them are down to memory mismanagement, with nine listed as use-after-free bugs, and four as heap buffer overflows.

Memory bug types explained

A use-after-free is exactly what it says: you hand back memory to free it up for another part of the program, but carry on using it anyway, thus potentially interfering with the correct operation of your app.

Imagine, for instance, that the part of the program that thinks it has now sole access to the offending block of memory receives some untrusted input, and carefully verifies that the new data is safe to use…

…but then, in the instant before it starts using that validated input, your buggy “use-after-free” code interferes, and injects stale, unsafe data into the very same part of memory.

Suddenly, bug-free code elsewhere in the program behaves as if it were buggy itself, thanks to the flaw in your code that just invalidated what was in memory.

Attackers who can figure out a way to manipulate the timing of your code’s unexpected intervention may be able not only to crash the program at will, but also to wrest control from it, thus causing what’s known as remote code execution.

And a heap buffer overflow refers to a bug where you write more data to memory than will fit in the space that was originally allocated to you. (Heap is the jargon term for the collection of memory blocks that are currently being managed by the system.)

If some other part of the program has a memory block just happens to be near to or next to yours in the heap, then the superfluous data that you just wrote out won’t overflow harmlessly into unused space.

Instead, it will corrupt data that’s in active use somewhere else, which similar consequences to what we just described for a use-after-free bug.

The “Sanitizer” system

Happily, as well as fixing misfeatures that weren’t supposed to be there at all, Google has announced the arrival of a new feature that adds protection against a class of browser flaws known as cross-site scripting (XSS).

XSS bugs are caused by the browser inserting untrusted data, say from a web form submitted by a remote user, directly into the current web page, without checking for (and removing) risky content first.

Imagine, for instance, that you have a web page that offers to show me what a text string of my choice looks like in your funky new font.

If I type in the sample text Cwm fjord bank glyphs vext quiz (a contrived but vaguely meaningful mashup of English and Welsh that contains all 26 letters of the alphabet in just 26 letters, in case you were wondering), then it’s safe for you to put that exact text into the web page you create.

In JavaScript, for example, you could rewrite the body of the web page like this, inserting the text that I supplied without any modification:

document.body.innerHTML = "<p style='font-family:funky;'>Cwm fjord bank glyphs vext quiz"

But if I cheated, and asked you to “display” the text string Cwm fjord<script>alert(42)</script> instead, then it would be reckless for you to do this…

document.body.innerHTML = "<p style='font-family:funky;'>Cwm fjord<script>alert(42)</script>"

…because you would be allowing me to inject untrusted JavaScript code of my choosing directly into your web page, where my code could read your cookies and access data that would otherwise be off-limits.

So, to make what’s known as sanitising thine inputs easier, Chrome has now officially enabled support for a new browser function called setHTML().

This can be used to push new HTML content through a feature called the Sanitizer first, so that if you use this code instead…

document.body.setHTML("<p style='font-family:funky;'>Cwm fjord<script>alert(42)</script>")

…then Chrome will scan the proposed new HTML string for security problems first, and automatically remove any text that could pose a risk.

You can see this in action via the Developer tools by running the above setHTML() code at the Console prompt, and then retrieving the actual HTML that was injected into the document.body variable, as we did here:

Even though we explicitly put a <script> tag in the input that we passed to the setHTML() function, the script code was automatically purged from the output that was created.

If you genuinely need to add potentially dangerous text into an HTML element, you can add a second argument to the setHTML() function that specifies various types of risky content to block or allow.

By default, if this second argument is omitted as above, then the Sanitizer operates at its maximum security level and automatically purges all dangerous content that it knows about.

What to do?

• If you’re a Chrome user. Check that you’re up to date by clicking Three dots > Help > About Google Chrome, or by browsing to the special URL chrome://settings/help.
• If you’re a web programmer. Learn about the new Sanitizer and setHTML() functionality by reading advice from Google and the MDN Web Docs.

By the way, if you’re on Firefox, Sanitizer is available, but isn’t yet turned on by default. You can turn it on to learn more about it by going to about:config and toggling the dom.security.sanitizer.enabled option to true.

Here’s an interesting paper from the recent 2022 USENIX conference: Mining Node.js Vulnerabilities via Object Dependence Graph and Query.

We’re going to cheat a little bit here by not digging into and explaining the core research presented by the authors of the paper (some mathematics, and knowledge of operational semantics notation is desirable when reading it), which is a method for the static analysis of source code that they call ODGEN, short for Object Dependence Graph Generator.

Instead, we want to focus on the implications of what they were able to discover in the Node Package Manager (NPM) JavaScript ecosystem, largely automatically, by using their ODGEN tools in real life.

One important fact here is, as we mentioned above, that their tools are intended for what’s known as static analysis.

That’s where you aim to review source code for likely (or actual) coding blunders and security holes without actually running it at all.

Testing-it-by-running-it is a much more time-consuming process that generally takes longer to set up, and longer to do.

As you can imagine, however, so-called dynamic analysis – actually building the software so you can run it and expose it to real data in controlled ways – generally gives much more thorough results, and is much more likely to expose arcane and dangerous bugs than simply “looking at it carefully and intuiting how it works”.

But dynamic analysis is not only time consuming, but also difficult to do well.

By this, we really mean to say that dynamic software testing is very easy to do badly, even if you spend ages on the task, because it’s easy to end up with an impressive number of tests that are nevertheless not quite as varied as you thought, and that your software is almost certain to pass, no matter what. Dynamic software testing sometimes ends up like a teacher who sets the same exam questions year after year, so that students who have concentrated entirely on practising “past papers” end up doing as well as students who have genuinely mastered the subject.

A straggly web of supply chain dependencies

In today’s huge software source code ecosystems, of which global open source repositories such as NPM, PyPI, PHP Packagist and RubyGems are well-known examples, many software products rely on extensive collections of other people’s packages, forming a complex, straggly web of supply chain dependencies.

Implicit in those dependencies, as you can imagine, is a dependency on each dynamic test suite provided by each underlying package – and those individual tests generally don’t (indeed, can’t) take into account how all the packages will interact when they’re combined to form your own, unique application.

So, although static analysis on its own isn’t really adequate, it’s still an excellent starting point for scanning software repositories for glaring holes, not least because static analysis can be done “offline”.

In particular, you can regularly and routinely scan all the source code packages you use, without needing to construct them into running programs, and without needing to come up with believable test scripts that force those programs to run in a realistic variety of ways.

You can even scan entire software repositories, including packages you might never need to use, in order to shake out code (or to identify authors) whose software you’re disinclined to trust before even trying it.

Better yet, some types of static analysis can be used to look through all your software for bugs caused by similar programming blunders that you just found via dynamic analysis (or that were reported through a bug bounty system) in one single part of one single software product.

For example, imagine a real-world bug report that came in from the wild based on one specific place in your code where you had used a coding style that caused a use-after-free memory error.

A use-after-free is where you are certain that you are finished with a certain block of memory, and hand it back so it can be used elsewhere, but then forget it’s not yours any more and keep using it anyway. Like accidentally driving home from work to your old address months after you moved out, just out of habit, and wondering why there’s a weird car in the driveway.

If someone has copied-and-pasted that buggy code into other software components in your company repository, you might be able to find them with a text search, assuming that the overall structure of the code was retained, and that comments and variable names weren’t changed too much.

But if other programmers merely followed the same coding idiom, perhaps even rewriting the flawed code in a different programming language (in the jargon, so that it was lexically different)…

…then text search would be close to useless.

Wouldn’t it be handy?

Wouldn’t it be handy if you could statically search your entire codebase for existing programming blunders, based not on text strings but instead on functional features such as code flow and data dependencies?

Well, in the USENIX paper we’re discussing here, the authors have attempted to build a static analysis tool that combines a number of different code characteristics into a compact representation denoting “how the code turns its inputs into its outputs, and which other parts of the code get to influence the results”.

The process is based on the aforementioned object dependency graphs.

Hugely simplified, the idea is to label source code statically so that you can tell which combinations of code-and-data (objects) in use at one point can affect objects that are used later on.

Then, it should be possible to search for known-bad code behaviours – smells, in the jargon – without actually needing to test the software in a live run, and without needing to rely only on text matching in the source.

In other words, you may be able to detect if coder A has produced a similar bug to the one you just found from coder B, regardless of whether A literally copied B’s code, followed B’s flawed advice, or simply picked the same bad workplace habits as B.

Loosely speaking, good static analysis of code, despite the fact that it never watches the software running in real life, can help to identify poor programming right at the start, before you inject your own project with bugs that might be subtle (or rare) enough in real life that they never show up, even under extensive and rigorous live testing.

And that’s the story we set out to tell you at the start.

300,000 packages processed

The authors of the paper applied their ODGEN system to 300,000 JavaScript packages from the NPM repository to filter those that their system suggested might contain vulnerabilities.

Of those, they kept packages with more than 1000 weekly downloads (it seems they didn’t have time to process all the results), and determined by further examination those packages in which they thought they’d uncovered an exploitable bug.

In those, they discovered 180 harmful security bugs, including 80 command injection vulnerabilities (that’s where untrusted data can be passed into system commands to achieve unwanted results, typically including remote code execution), and 14 further code execution bugs.

Of these, 27 were ultimately given CVE numbers, recognising them as “official” security holes.

Unfortunately, all those CVEs are dated 2019 and 2020, because the practical part of the work in this paper was done more than two years ago, but it’s only been written up now.

Nevertheless, even if you work in less rarified air than academics seem to (for most active cybersecurity responders, fighting today’s cybercriminals means finishing any research you’ve done as soon as you can so you can use it right away)…

…if you’re looking for research topics to help against supply chain attacks in today’s giant-scale software repositories, don’t overlook static code analysis.

Life in the old dog yet

Static analysis has fallen into some disfavour in recent years, not least because popular dynamic languages like JavaScript make static processing frustratingly hard.

For example, a JavaScript variable might be an integer at one moment, then have a text string “added” to it perfectly legally albeit incorrectly, thus turning it into a text string, and might later end up as yet another object type altogether.

And a dynamically generated text string can magically turn into a new JavaScript program, compiled and executed at runtime, thus introducing behaviour (and bugs) that didn’t even exist when the static analysis was done.

But this paper suggests that, even for dynamic languages, regular static analysis of the repositories you rely upon can still help you enormously.

Static tools can not only find latent bugs in code you’re already using, even in JavaScript, but also help you to judge the underlying quality of the code in any packages you’re thinking of adopting.

LEARN MORE ABOUT PREVENTING SUPPLY-CHAIN ATTACKS

This podcast features Sophos expert Chester Wisniewski, Principal Research Scientist at Sophos, and it’s full of useful and actionable advice on dealing with supply chain attacks, based on the lessons we can learn from giant attacks in the past, such as Kaseya and SolarWinds.

If no audio player appears above, listen directly on Soundcloud.
You can also read the entire podcast as a full transcript.

As you no doubt already know, because the story has been all over the news and social media recently, the widely-known and widely-used password manager LastPass last week reported a security breach.

The breach itself actually happened two weeks before that, the company said, and involved attackers getting into the system where LastPass keeps the source code of its software.

From there, LastPass reported, the attackers “took portions of source code and some proprietary LastPass technical information.”

We didn’t write this incident up last week, because there didn’t seem to be a lot that we could add to the LastPass incident report – the crooks rifled through their proprietary source code and intellectual property, but apparently didn’t get at any customer or employee data.

In other words, we saw this as a deeply embarrassing PR issue for LastPass itself, given that the whole purpose of the company’s own product is to help customers keep their online accounts to themselves, but not as an incident that directly put customers’ online accounts at risk.

However, over the past weekend we’ve had several worried enquiries from readers (and we’ve seen some misleading advice on social media), so we thought we’d look at the main questions that we’ve received so far.

After all, we regularly recommend our readers and podcast listeners to consider using a password manager, even though we’ve also written up numerous security blunders in password manager tools over the years.

So, we’ve put together six questions-and-answers below, to help you make an informed decision about the future of password managers in your own digital life.

Q1. What if my password manager gets hacked?

A1. That’s a perfectly reasonable question: if you put all your password eggs in one basket, doesn’t that basket become a single point of failure?

In fact, that’s a question we’ve been asked so often that we have a video specifically to answer it (click on the cog while playing to turn on subtitles or to speed up playback):

[embedded content]

Q2. If I use LastPass, should I change all my passwords?

A2. If you want to change some or all of your passwords, we’re not going to talk you out of it.

(One handy thing about a password manager, as we explain in the video above, is that it’s much quicker, easier and safer to change passwords, because you’re not stuck with trying to concoct and remember dozens of new and complicated text strings in a hurry.)

By all accounts, however, this security incident has nothing to do with the crooks getting at any of your personal data, least of all your passwords, which aren’t stored on LastPass’s servers in a usable form anyway. (See Q5.)

This attack doesn’t appear to involve a vulnerability in or an exploit against the LastPass software by which crooks could attack the encrypted passwords in your password vault, or to involve malware that knows how to insinuate itself into the password decryption process on your own computers.

Furthermore, it doesn’t involve the theft of any personally identifiable “real life” customer information such as phone numbers, postcodes or individual ID numbers that might help attackers to persuade online services into resetting your passwords using social engineering tricks.

Therefore, we don’t think you need to change your passwords. (For what it’s worth, neither does LastPass.)

Q3. Should I give up on LastPass and switch to a competitor?

A3. That’s a question you will have to answer for yourself.

As we said above, as embarrassing as this incident is for LastPass, it seems that no personal data was breached and no password-related data (encrypted or otherwise) was stolen, only the company’s own source code and proprietary information.

Did you ditch Chrome when Google’s recent in-the-wild zero day exploit was announced? Or Apple products after the latest zero-day double play? Or Windows after any Patch Tuesday update in which zero-day bugs were fixed?

If not, then we’re assuming that you are willing to judge a company’s likely future cybersecurity trustworthiness by how it reacted last time a bug or a breach occured, especially if the company’s blunder didn’t directly and immediately put you at risk.

We suggest that you read the LastPass incident report and FAQ for yourself, and decide on that basis whether you are still inclined to trust the company.

Q4. Doesn’t stolen source code mean that hacks and exploits are bound to follow?

A4. That’s a reasonable question, and the answer isn’t straightforward.

Generally speaking, source code is much easier to read and understand that its compiled, “binary” equivalent, especially if it is well-commented and uses meaningful names for things like variables and functions inside the software.

As a somewhat synthetic but easy-to-follow example, compare the Lua source code on the left below with the compiled bytecode (like Java, Lua runs in a virtual machine) on the right:

In theory, therefore, source code means it ought to be quicker and easier to determine exactly how the software works, including spotting any programming blunders or cybersecurity mistakes, and therefore vulnerabilities ought to be easier to find, and exploits quicker to devise.

In practice, it’s true that acquiring source code to go along with the compiled binaries you are trying to reverse engineer will rarely, if ever, make the job more difficult, and will often make it easier.

Having said that, you need to remember that Microsoft Windows is a closed-source operating system, and yet many, if not most, of the security holes fixed each month on Patch Tuesday were reverse engineered directly from precompiled binaries.

In other words, keeping your source code secret should never be considered to be a vital part of any cybersecurity process.

You also need to remember that many projects rely explicitly on making their source code public, not merely so that anyone can scrutinise it, but also so that anyone who wants can use it, modifiy it and contribute for the greater good of all.

Yet even mainstream open-source projects with liberal usage licences, and with potentially many eyes on that source code over many years, have required critical security patches for bugs that could have been spotted many times over, but weren’t.

Lastly, many proprietary software projects these days (examples include Google’s Chrome browser; Apple’s iOS operating system; the Sophos XG firewall; and thousands more widely-used hardware and software tools) nevertheless make extensive use of numerous open-source components.

Simply put, most contemporary closed-source projects include significant parts for which source code can be downloaded anyway (because licensing demands it), or can be inferred (because licensing requires its use to be documented, even if some modifications to the code were subsequently been made).

In other words, this source code leak may help potential attackers slightly, but almost certainly [a] not as much as you might at first think and [b] not to the point that new exploits will become possible that could never have been figured out without the source code.

Q5. Should I give up on password managers altogether?

A5. The argument here is that if even a company that prides itself on providing tools to lock up your personal and corporate secrets more securely can’t lock up its own intellectual property safely, surely that’s a warning that password managers are a “fool’s errand”?

After all, what if the crooks break in again, and next time it’s not the source code they get hold of, but every individual password stored by every individual user?

That’s a worry – you might almost call it a meme – that’s regularly seen on social media, especially after a breach of this sort: “What if the crooks had download all my passwords? What was I thinking, sharing all my passwords anyway?”

Those would be a genuine concerns if password managers worked by keeping exact copies of all your passwords on their own servers, where they could be extracted by attackers or demanded by law enforcement.

But no decent cloud-based password managers work that way.

Instead, what’s stored on their servers is an encrypted database, or “blob” (short for binary large object) that is only ever decrypted after being transferred to your device, and after you’ve provided your master password locally, perhaps with some sort of two-factor authentication involved to reduce the risk of local compromise.

No passwords in your password vault are ever stored in a directly usable form on the password manager’s servers, and your master password is ideally never stored at all, not even as a salted-and-stretched password hash.

In other words, a reliable password manager company doesn’t have to be trusted not to leak your passwords in the event of a hack of its databases, or to refuse to reveal them in the event of a warrant from law enforcement…

…because it couldn’t reveal them, even if wanted to, given that it doesn’t keep a record of your master password, or any other passwords, in any database from which it could extract them without your agreement and collaboration.

(The LastPass website has a description and a diagram – admittedly a rather basic one – of how your passwords are protected from server-side compromise by not being decrypted except on your own device, under your direct control.)

Q6. Remind me again – why use a password manager?

A6. Let’s summarise the benefits while we’re about it:

• A good password manager simplifies good password use for you. It turns the problem of choosing and remembering dozens, or perhaps even hundreds, of passwords into the problem of choosing one really strong password, optionally reinforced with 2FA. There’s no longer any need to cut corners by using “easy” or guessable passwords on any of your accounts, even ones that feel unimportant.
• A good password manager won’t let you use the same password twice. Remember that if crooks recover one of your passwords, perhaps due to a compromise at a single website you use, they will immediately try the same (or similar) passwords on all the other accounts they can think of. This can greatly magnify the damage done by what might otherwise have been a contained password compromise.
• A good password manager can choose and remember hundreds, even thousands, of long, pseudo-random, complex, completely different passwords. Indeed, it can do this just as easily as you can remember your own name. Even when you try really hard, it’s difficult to choose a truly random and unguessable password yourself, especially if you’re in a hurry, because there’s always a temptation to follow some sort of predictable pattern, e.g. left hand then right hand, consonant then vowel, top-middle-bottom row, or name of cat with -99 on the end.
• A good password manager won’t let you put the right password in the wrong site. Password managers don’t “recognise” websites just becasuse they “look right” and have the correct-looking logos and background images on them. This helps to protect you from phishing, where you fail to notice that the URL isn’t quite right, and put your password (and even your 2FA code) into a bogus site instead.

Don’t jump to conclusions

So, there’s our advice on the issue.

We’re staying neutral about LastPass itself, and we’re not specifically recommending any password manager product or service out there, including LastPass, above or below any other.

But whatever decision you make about whether you’ll be better off or worse off by adopting a password manager…

…we’d like to ensure that you make it for well-informed reasons.

If you have any more questions, please ask in the comments below – we’ll do our best to answer promptly.

Recent updates to Apple Safari and Google Chrome made big headlines because they fixed mysterious zero-day exploits that were already being used in the wild.

But this week also saw the latest four-weekly Firefox update, which dropped as usual on Tuesday, four weeks after the last scheduled full-version-number-increment release.

We haven’t written about this update until now because, well, because the good news is…

…that although there were a couple of intriguing and important fixes with a level of High, there weren’t any zero-days, or even any Critical bugs this month.

Memory safety bugs

As usual, the Mozilla team assigned two overarching CVE numbers to bugs that they found-and-fixed using proactive techniques such as fuzzing, where buggy code is automatically probed for flaws, documented, and patched without waiting for someone to figure out just how exploitable those bugs might be:

• CVE-2022-38477 covers bugs that affect only Firefox builds based on the code of version 102 and later, which is the codebase used by the main version, now updated to 104.0, and the primary Extended Support Release version, which is now ESR 102.2.
• CVE-2022-38478 covers additional bugs that exist in the Firefox code going back to version 91, because that’s the basis of the secondary Extended Support Release, which now stands at ESR 91.13.

As usual, Mozilla is plain-speaking enough to make the simple pronouncement that:

Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.

ESR demystified

As we’ve explained before, Firefox Extended Support Release is aimed at conservative home users and at corporate sysadmins who prefer to delay feature updates and functionality changes, as long as they don’t miss out on security updates by doing so.

The ESR version numbers combine to tell you what feature set you have, plus how many security updates there have been since that version came out.

So, for ESR 102.2, we have 102+2 = 104 (the current leading-edge version).

Similarly, for ESR 91.13, we have 91+13 = 104, to make it clear that although version 91 is still back at the feature set from about a year ago, it’s up-to-the-moment as far as security patches are concerned.

The reason there are two ESRs at any time is to provide a substantial double-up period between versions, so you are never stuck with taking on new features just to get security fixes – there’s always an overlap during which you can keep using the old ESR while trying out the new ESR to get ready for the necessary switchover in the future.

Trust-spoofing bugs

The two specific and apparently-related vulnerabilities that made the High category this month were:

• CVE-2022-38472: Address bar spoofing via XSLT error handling.
• CVE-2022-38473: Cross-origin XSLT Documents would have inherited the parent’s permissions.

As you can imagine, these bugs mean that rogue content fetched from an otherwise innocent-looking site could end up with Firefox tricking you into trusting web pages that you shouldn’t.

In the first bug, Firefox could be lured into presenting content served up from an unknown and untrusted site as if it had come from a URL hosted on a server that you already knew and trusted.

In the second bug, web content from an untrusted site X shown in a sub-window (an IFRAME, short for inline frame) within a trusted site Y…

…could end up with security permissions “borrowed” from parent window Y that you would not expect to be passed on (and that you would not knowingly grant) to X, including access to your webcam and microphone.

What to do?

On desktops or laptops, go to Help > About Firefox to check if you’re up-to-date.

If not, the About window will prompt you to download and activate the needed update – you are looking for 104.0, or ESR 102.2, or ESR 91.13, depending on which release series you are on.

On your mobile phone, check with Google Play or the Apple App Store to ensure you’ve got the latest version.

On Linux and the BSDs, if you are relying on the version of Firefox packaged by your distribution, check with your distro maker for the latest version they’ve published.

Happy patching!

LISTEN NOW

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