This Week In Security: Spectre In The Browser, Be Careful What You Clone, And Hackintosh

Google has been working on mitigations for the Spectre attack, and has made available a Proof of Concept that you can run in your browser right now. Spectre is one of the issues that kicked off the entire series of speculative execution vulnerabilities and fixes. What Google has demonstrated is that the Spectre attack can actually be pulled off in Javascript, right in the browser. Spectre is limited to reading memory allocated to the same process, and modern browsers have implemented measures like site isolation, which puts each site in a separate, sandboxed process.

These security features don’t mean that there is no practical dangers from Spectre. There are a handful of ways an attacker can run Javascript on another site, from something as simple as an interactive advertisement, to a cross-site scripting injection. Google has produced features and guidance to mitigate those dangers.

Via Bleeping Computer.

Git Vulnerability Retreaded

CVE-2021-21300 is an issue where a malicious git repository can execute a script during the cloning proceedure. The limitations are that the clone must be located on a case-insensitive filesystem, Git must allow symlinks, and clean/smudge filters have to be enabled. That combination just happens to default in the case of Git for Windows. Sound familiar? Git for Windows had a nearly identical vulnerability a few months back, CVE-2020-27955. This is probably an instance where the first vulnerability inspired more research into the attack type, uncovering more problems. In any case, don’t do a Git clone from an untrusted repository.

DuckDuckGo Extension Insecurity

DuckDuckGo makes a browser extension, “DuckDuckGo Privacy Essentials”. It’s fairly straightforward, blocking some tracking approaches, and automatically redirecting to the HTTPS version of sites. [Wladimir Palant] did a brief audit of the extension, and found a couple ironic problems. The first is that like many other anti-fingerprinting solutions, the extension is a fingerprint in itself. Those extensions usually depend on a series of hacks to work at all, and it’s often possible to figure out the real data anyway. Example: an anti-fingerprinting extension might set screen.width = 1280;. A simple fingerprinting script might simply accept that value, but a more clever script would take the set value, then call delete screen.width; and check the value again. The failure of the anti-fingerprinting extension made the user even more distinctly identifiable. Note that this example is not specifically from the DuckDuckGo extension, but part of [Wladimir]’s explanation of how these extensions can go wrong.

Specific to DDG’s Privacy Essentials, there are a couple of more serious issues. First off, one of the extension’s scripts used window.postMessage() to communicate between different instances. That function is a bit dangerous, particularly in an extension, as it doesn’t segregate messages between the extension and loaded page. If the scripts on a page determined that the visitor was using the vulnerable version of the DDG extension, it could send some commands directly, using that function.

The other problem is a snippet of code that uses tabs.executeScript(). That call uses data pulled from the DuckDuckGo servers, without proper sanitization. If malicious code was ever hosted where the extension was pulling this data from, the browser extension would have happily executed it on every site you visited. [Wladimir] notified DDG privately about the issues he found, and they’ve been fixed. He does note that at least part of the blame for insecure extensions falls on the extension API itself. In many cases, writing secure extension code is far more difficult that it should be.

Hackintosh for Researchers

Doing either research or app development for the Apple ecosystem is something of a pain. If you’re like me, then you have no interest in running a Mac as your daily driver. The cost of a Mac just for research and development is a bit steep, too. The standard solution for many is the Hackintosh — installing the MacOS on generic hardware or in a VM. Our old friend, [Sick Codes], has a project that makes the Apple system much more approachable: Docker-OSX. Need a MacOS system to run Xcode on? Deploy the docker image and start Xcode, hosted right on your Linux or Windows machine. Want to do security research on an Apple binary? Yep, run it right there and dive in.

Now, one might wonder about these solutions: are they legal? Doesn’t Apple’s Terms of Service make it clear that we’re not licensed to run MacOS on any hardware not produced by Apple? Well, [Sick Codes] took a look at that question, too. As far as I know, he is not a lawyer, so take this with that grain of salt. The Apple Security Bounty has terms that override the normal terms of service, so long as you are doing good-faith security research.

This and That

Ever wanted to get into Linux kernel hacking and exploitation, but didn’t know where to start? [Jordy Zomer] just published part one of a series of articles about that very subject. It’s a quick intro to writing kernel drivers, pointing out the security flaw in that driver, and then a step-by-step guide to exploiting that flaw. This looks like a space to pay attention to, particularly if more installments follow.

Your Netgear smart switch just might be very hackable. Ncc Group released their set of vulnerabilities from a Prosafe Plus switch. The worst appears to be the accessibility of a debug interface by an unauthenticated user. You might not have either of the exact switches from the report, but it’s safe to assume that some of these vulnerabilities are present in other devices, with minor variations.

Ever wonder what happens when you click on the obviously fake sponsored search results from a Google search? The guys at SUID wanted to know, and they wrote up a very detailed report on their results. The short answer is that Malvertising campaigns will try to snarf saved credentials and other private data from your machine, if you’re unfortunate enough to let them install their payload.

And finally, Nettitude Labs is doing a walkthrough of techniques an attacker might use to determine if the target is a virtual machine, and what platform it is. Part one is all about the memory layout of the virtual hardware, and part two discusses fingerprinting the driver behavior of each VM platform. We sometimes use VMs to run dangerous binaries and visit suspicious websites, so it’s useful to be familiar with some of the detection and escape tactics.

12 thoughts on “This Week In Security: Spectre In The Browser, Be Careful What You Clone, And Hackintosh

  1. Just tried the Spectre attack on this netbook (Samsung N150)…

    OS: Debian Linux 10 (Buster) AMD64
    Browser: Mozilla Firefox 78 ESR
    CPU: Intel(R) Atom(TM) CPU N450 @ 1.66GHz

    Exploit status: fail

    I guess this machine is just too slow for JavaScript to exploit Spectre properly.

      1. Not quite, if I recall correctly almost all atom processors were not vulnerable. But a few of them are. Basically based on release date. Not sure if the N450 above is though, but I think its not.

        1. Right, I’m thinking original atom architecture, not what they’ve been playing musical badges on later, this week it’s a Celeron, next week it’s an atom, last week it was a Pentium…

    1. Two things:
      1. It doesn’t work on Firefox, only Chrome.
      2. As below, many Atom CPUs are not vulnerable (including yours). This is because the older ones don’t have speculative execution.

Leave a Reply to ArchCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.