This Week In Security: SWAPGS, Malicious Shaders, More IOS Woes, And WPA3

I’m sure you’ve heard of Spectre, which was the first of many speculative execution vulnerabilities found in modern processors. A new one just popped up this week. At Blackhat on Tuesday, CVE-2019-1125 was announced by Bitdefender as SWAPGS.

SWAPGS is an x86_64 instruction that is intended for use in context switching, that is when execution is transferred from a user-space program back into the kernel. Specifically, SWAPGS swaps the value of the GS register so that it refers to either a memory location in the running application, or a location in the kernel’s space. An unprivileged program can attempt to call this instruction and leak kernel memory contents as a result of the processor speculatively executing the instruction (this is similar to Spectre). Even though the instruction will ultimately not be executed, because a userspace program doesn’t have sufficient privilege to do so, the contents of the system cache have already been sufficiently altered, and an attack could feasibly leverage this to read arbitrary kernel memory.

While the initial reports have mentioned both AMD and Intel products, AMD has released a statement:

AMD is aware of new research claiming new speculative execution attacks that may allow access to privileged kernel data. Based on external and internal analysis, AMD believes it is not vulnerable to the SWAPGS variant attacks because AMD products are designed not to speculate on the new GS value following a speculative SWAPGS. For the attack that is not a SWAPGS variant, the mitigation is to implement our existing recommendations for Spectre variant 1.

Patches for Windows and Linux have been released, and Red Hat has an informative write-up on the vulnerability. I would have reviewed Bitdefender’s whitepaper on the vulnerability, but rather than make it freely available, they have opted to require a name and email address. While I would like to see their work, I refuse to sell my contact information in exchange for access.

A Malicious Shader?

This is the first time I can remember hearing of a malicious pixel shader. Cisco Talos announced a set of vulnerabilities targeting VMware and NVIDIA graphics drivers.

Shaders are specialized programs that run on a video card, and are generally used to apply effects like blur, lighting, bump mapping, and more. Most of the graphical improvements in the last few years of gaming is a result of shaders.

Talos researchers were specifically looking at how to compromise a VM Hyper-visor from inside a guest OS, and they discovered that when a host provides 3d acceleration to the guest, shaders are passed directly through to the system drivers without verification. Because the NVIDIA drivers are also vulnerable, this could allow a malicious program on the host to run arbitrary code on the hypervisor.

While this is troubling enough, the topper is that a malicious shader could potentially be run via WebGL. Taken together, this represents a real danger where simply loading a malicious WebGL enabled page could compromise not only a conventional machine, but could also compromise the bare-metal OS even when run on a guest instance.

Both NVIDIA and VMware have already released driver updates that fixes the flaw, so go update!

iOS Problems

Natalie Silvanovich of Google’s Project Zero released a set of 5 iOS vulnerabilities on Wednesday the 7th. These are not garden variety bugs, but so-called “zero click” problems where no user interaction is required for exploit.

The first exploit, for example, is a spoofed visual voicemail message. Visual voicemail notifications are sent as specially formatted text messages and contain information about the message and the address of an IMAP server to connect to and download the message. That information can be spoofed, leading a device to try to download a message from an IMAP server in the control of an attacker. From that point, finding a bug in the iOS IMAP handling code was relatively easy.

5 vulnerabilities have been fixed in iOS updates. There is a 6th vulnerability, CVE-2019-8641, that has yet to be fixed. While a few hints about this problem are given, the details have been withheld until an update has been released to fully fix the problem. One could be a bit cynical and point out that it’s the Google research team announcing these flaws. While there is certainly a self-serving angle to consider, it’s much better for iOS and consumers if flaws are fixed and publicized, rather than kept secret and sold to an offensive security vendor.

One more iOS story is Apple Bleee. Bluetooth Low Energy is an extremely useful communication protocol, allowing Apple devices to perform many of their seemingly magic functionality. The downside is that to make the magic happen, iOS devices are constantly sending BLE signals, probing for other devices. The researchers at Hexway realized that these signals leak lots of data about your device, potentially including your phone number.

iOS uses a SHA256 hash of the device’s phone number as an identifier when using AirDrop. A SHA256 is still a reasonably secure one-way hash, so there’s no problem, right? The clever realization is that while the hash is secure, and the output space is too large to attack, the input space is small enough to be manageable. An attacker could target the most common area codes in their area, limiting the target space further. From there, the SHA256 hashes for all valid numbers can be pre-calculated and stored in a lookup table.

More WPA3 Problems

We’ve discussed Dragonblood, a WPA3 analysis project. A new problem has been identified, a timing analysis attack that leaks information about the internal state of the encryption algorithm.

This Week In Security: VxWorks, Expensive Email Fraud, And What’s In Your Wallet?

This has been an interesting week. First off, security researchers at Armis discovered a set of serious vulnerabilities in the vxWorks Real Time Operating System (RTOS). Released under a name that sounds like the title of a western or caper movie, Urgent/11. Not familiar with vxWorks? It’s a toss-up as to whether vxWorks or Linux is more popular for embedded devices. Several printer brands, Arris modems, Sonicwall firewalls, and a whole host of other industrial and medical devices run the vxWorks RTOS.

Several of these vulnerabilities are in the network stack, rather than in applications. The worst offender is CVE-2019-12256, a vulnerability in error handling. An ICMP error response is generated from an incoming packet, and assumptions are made about that incoming packet. When data is copied from that packet into the ICMP error, the length is not first checked, allowing unconfined memory write. If this sounds familiar, it should. We covered a similar vulnerability in Apple’s XNU kernel not long ago.

This particular vulnerability can compromise a vxWorks machine even without an opened port. The saving grace of that vulnerability applies here: a maliciously crafted packet is necessarily malformed, and won’t navigate public routing. In other words, it’s LAN only, and can’t be sent over the internet.

They come in through the firewall.

A second class of vulnerability, where the name comes from, is related to the TCP urgent pointer. This rarely used TCP feature was intended to allow more up-to-date information to supersede data still being processed. Not only has TCP urgent not been widely used, the specifications were not written particularly well, with the various RFC documents describing conflicting implementations. It’s surprising that vxWorks supports it at all, but isn’t particularly surprising that their implementation is flawed. Manipulation of the data stream can cause a length integer to underflow. The nature of binary arithmetic means that underflowing an unsigned integer causes it to wrap around to maximum value, which can lead to writing packet data in the buffer in unexpected memory locations. These vulnerabilities require an established TCP connection, but the researchers describe several scenarios where that could be accomplished by an attacker.

The last RCE vulnerability they describe is in the DHCP client, ipdhcpc. This is a very simple vulnerability. One section of code allocates a buffer for DHCP options, but allocates 24 bytes fewer than the maximum size. An attacker could use this 24 byte overflow to manipulate the data structure and potentially jump execution into manipulated memory.

Update (2019-08-02 09:15 UTC-7): Hackaday received a statement from SonicWall that they made a patch for this vulnerability back on July 19th:

Ensuring the security of our customers is a responsibility we take seriously at SonicWall and we work vigilantly to always keep our customers secure. SonicWall physical firewall appliances running certain versions of SonicOS contain vulnerabilities in code utilized for remote management. At this time, there is no indication that the discovered vulnerabilities are being exploited in the wild. The patches are available now and we strongly advised our partners and end users July 19 th to apply the SonicOS patch immediately.

https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2019-0009

Capital One: What’s in Your Data

Capital One made use of Amazon AWS for storing customer data. This isn’t surprising, many companies have turned to Amazon’s seemingly inexhaustible cloud computing platform for storing large data sets. It seems, however, that Capital One failed to configure the security properly on that bucket. (As many other companies have done.) Information was leaked for over an estimated 100 million customers. A former Amazon employee has been arrested, and seems to have posted at least a portion of that data in a Github gist.

Reading between the lines, it seems that this was a very simple mistake. Perhaps credentials were leaked, or the S3 bucket was publicly available. That particular detail has not been released. There is something to be said for Capital One’s response to the incident. They were anonymously informed of the existence of the gist on July 17, using their responsible disclosure process. By the 29th, they had fixed the misconfiguration, coordinated with law enforcement, and publicly announced the breach. A twelve day turn-around is an impressive response, particularly when so many companies have tried to hide or ignore similar breaches.

Cabarrus County, NC

It seemed simple enough. The general contractor for the county’s new school building needed to update bank account information. The appropriate forms were signed and filed, and the information was updated. Nothing seemed amiss unto two months later, when the contractor notified the county that they had missed a scheduled payment of 2.5 million dollars. But the transaction went through, and the money was transferred to the account on file.

Yes, the transfer went through, but the the county had been hit with a social engineering scam. The report refers to it as an Email Account Compromise (EAC) scam, which seems to indicate that the scammer first gained access to a legitimate email account of the contractor in question. Alternatively, an attacker could simply spoof the sender’s email address, and set a different reply-to field. Unless a user was particularly watching for such a scheme, it would be easy to overlook the discrepancy. In any case, even after recovering some of the transferred money, the county seems to be out about $1.7 million. These scams are becoming more and more popular, so remember, don’t believe anything you read in an email.

The Weird and Wacky

And to round out this week’s news, yet another [Satoshi Nakamoto] candidate has been found: Linus Torvalds. While it appears to be a serious suggestion, I’ll just note that the author doesn’t have his name attached to this article. He does make one interesting observation — git is the killer blockchain app. You see, I tend to compare blockchain to the laser. Both were very clever inventions, but didn’t have any immediate uses. They were solutions in search of a problem. This article points out that core concepts of blockchain are present in git, which seems to be an accurate and clever observation. So what is blockchain good for? Git!

And the most useless security news of the week? The CAN bus on airplanes is exploitable when an attacker has unsupervised physical access. Yes, people with unsupervised physical access can do bad things to airplanes. Think about what they could do if they brought a wrench.

Fake Graphics Cards And How To Fix Them

When shopping online, there’s plenty of great deals out there on modern graphics hardware. Of course, if you’re like [Dawid] and bought a GTX1050 Ti for $48 from Wish, you probably suspect it’s too good to be true. Of course, you’d be correct.

[Dawid] notes from the outset that the packaging the card ships in is unusual. While it’s covered in NVIDIA and GeForce branding, there’s no note of the model number or even the overarching series. The card is loosely packed in bubblewrap, free to bounce around in transit. Upon installation, the card reports itself as a GTX1050 Ti, but refuses to properly work with NVIDIA drivers and routinely causes a Blue Screen of Death.

Upon disassembly, it becomes apparent that the card is merely a poorly manufactured GTS450 Revision 2, over five generations older than the card it was advertised as. Thanks to the mismatch between the actual hardware and what the card reports as, the drivers are unable to properly work with the card.

For those that have been scammed, there is some hope. [Phil] has had experience with several of these cards, which similarly misreport their actual hardware. To correct this, the cards need to have their BIOS flashed to reflect reality, but the fake cards don’t work with NVIDIA’s NVFlash tool. Instead, they must be flashed manually using an EEPROM programmer. Once the cards are flashed with an appropriate BIOS, they can be used with the proper drivers and will function properly, albeit with much less performance than was advertised.

It’s an interesting insight into the state of online shopping platforms, and the old adage remains true – if it’s too good to be true, it probably is. Plus, hacking GPUs can often have great results. Video after the break.

Continue reading “Fake Graphics Cards And How To Fix Them”

Where The Work Is Really Done – Casual Profiling

Once a program has been debugged and works properly, it might be time to start optimizing it. A common way of doing this is a method called profiling – watching a program execute and counting the amount of computing time each step in the program takes. This is all well and good for most programs, but gets complicated when processes execute on more than one core. A profiler may count time spent waiting in a program for a process in another core to finish, giving meaningless results. To solve this problem, a method called casual profiling was developed.

In casual profiling, markers are placed in the code and the profiler can measure how fast the program gets to these markers. Since multiple cores are involved, and the profiler can’t speed up the rest of the program, it actually slows everything else down and measures the markers in order to simulate an increase in speed. [Daniel Morsig] took this idea and implemented it in Go, with an example used to demonstrate its effectiveness speeding up a single process by 95%, resulting in a 22% increase in the entire program. Using a regular profiler only counted a 3% increase, which was not as informative as the casual profiler’s 22% measurement.

We got this tip from [Greg Kennedy] who notes that he hasn’t seen much use of casual profiling outside of the academic world, but we agree that there is likely some usefulness to this method of keeping track of a multi-threaded program’s efficiency. If you know of any other ways of solving this problem, or have seen causal profiling in use in the wild, let us know in the comments below.

Header image: Alan Lorenzo [CC BY-SA 3.0].

This Week In Security: Selfblow, Encryption Backdoors, Killer Apps, And The VLC Apocalypse That Wasn’t

Selfblow (Don’t google that at work, by the way) is a clever exploit by [Balázs Triszka] that affects every Nvidia Tegra device using the nvtboot bootloader — just about all of them except the Nintendo Switch. It’s CVE 2019-5680, and rated at an 8.2 according to Nvidia, but that high CVE rating isn’t entirely reflective of the reality of the situation. Taking advantage of the vulnerability means writing to the boot device, which requires root access, as well as a kernel flag set to expose the boot partitions to userspace. This vulnerability was discovered as part of an effort by [Balázs] and other LineageOS developers to build an open source bootloader for Nvidia Tegra devices.

The Tegra boot process is a bit different, having several stages and a dedicated Boot and Power Management CPU (BPMP). A zero-stage ROM loads nvtboot to memory and starts it executing on the BPMP. One of the tasks of nvtboot is to verify the signature of the next bootloader step, nvtboot-cpu. The file size and memory location are embedded in the nvtboot-cpu header. There are two problems here that together make this vulnerability possible. The first is that the bootloader binary is loaded to its final memory location before the signature verification is performed. The code is written to validate the bootloader signature before starting it executing on the primary CPU, so all is well, right? Continue reading “This Week In Security: Selfblow, Encryption Backdoors, Killer Apps, And The VLC Apocalypse That Wasn’t”

PC And Console Gaming United Courtesy Of Origin

When folk at Origin PCs realized that their company was about to celebrate its 10th anniversary of making custom (gaming) PCs, they knew that they had to do something special. Since one thing they did when the company launched in 2009 was to integrate an XBox 360 into a gaming PC, they figured that they might as well refresh and one-up that project. Thus 2019’s Project ‘Big O’ was born.

Naturally still featuring a high-end gaming PC at its core, the show piece of the system is that they also added an XBox One X, Playstation 4 Pro and Nintendo Switch console into the same full-tower GENESIS chassis. For this they had to strip the first two consoles out of their enclosures and insert them into the case each along with their own (appropriately colored) watercooling loop. Unfortunately the optical drives got ditched, presumably because this made things look cleaner.

The Switch was not modded or even cracked open. Instead a Switch dock was installed in the front of the case, allowing one to dock the Switch in the front of the case, and still use it in a mobile fashion after undocking it. Meanwhile an Ethernet and HDMI switch simplify the interfaces to this gaming system a lot, requiring one to only plug in a single HDMI and Ethernet cable to plug in all capable platforms. The result is a pretty sleek-looking system, definitely an eye-catcher.

Since Origin will never, ever, sell the Big O to customers as it’s just a promotional item, it does tickle the imagination. Case-modding and combining multiple computers (often an ATX and mini-ITX) system into a single case is nothing new, but aspects such as having a dockable Switch feature, this clean aesthetic and overall functionality makes one wonder what an enterprising hobbyist could accomplish here.

Continue reading “PC And Console Gaming United Courtesy Of Origin”

The Case Of The Vintage Computer, The Blown Fuse, And The Diode

If you are the operator of a vintage computer, probably the only one of its type remaining in service, probably the worst thing you can hear is a loud pop followed by your machine abruptly powering down. That’s what happened to the Elliott 803B in the UK’s National Museum Of Computing, and its maintainer [Peter Onion] has written an account of his getting it back online.

The Elliott is a large machine from the early 1960s, and because mains supplies in those days could be unreliable it has a rudimentary UPS to keep it going during a brownout. A hefty Ni-Cd battery is permanently hooked up to a charger that also serves as the power supply for the machine, ensuring that it can continue to operate for a short while as the voltage drops. A spate of fuses had blown in this power supply, so we’re taken through the process of fault-finding. Eventually the failure is found in a rectifier diode, the closest modern equivalent is substituted, and after testing the machine comes back to life.

We’re used to reading these stories from the other side of the Atlantic, so we welcome TNMOC saying that this is the first of a series of technical posts on their work. We visited the museum back in 2016, and also featured its famous recreated Colossus.