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.
One of the first xBox 360 vulnerabilities was exploited to load a custom shader that then exploited further systems to take over the console.
I’m sure there are even earlier examples of shader exploits.
IMHO no information on vulnerabilities should ever be published. They only serve to help and encourage the evil forces and serve no useful purposes to the rest of us. And researchers getting paid to find these problems is just another form of extortion.
really? if the vulnerabilities are not published, there is no incentive to fix them. so they go unfixed and a black hat can make full use of them in the wild. Responsible disclosure exists for this reason. Also it promotes more secure code as hopefully people learn from mistakes.
It massively benefits the rest of us to have these disclosed and patched.
Full disclosure arms the hacker with full details of precisely how-to. This is just being idiotic. You have armed a thief with the tools to break-in. No one to blame but yourself!
In the end, we all suffer. It take resources to keep software patches up-to-date. Just because a patch is released doesn’t mean everyone has installed it.
And all these theoretical problems such as spectre are now disclosed, so where we could decide whether to install or not, now we have to. And the net result is that our pcs are running frightfully slow as a consequence. Take a look at how much just running Norton on you pc slows it down!
Better prosecution for hackers and publishing would be more useful.
How’s about I don’t tell you that this beach is infested with jelly fish at this time of year, or that if you travel to that country that you should get a malaria vaccine? Or maybe your personal data was hacked because some blackhat found the information about the exploit anyway. Full disclosure is necessary for the betterment of everybody so that more secure systems can be developed in future.
Vulnerabilities should be published and documented… But only after the vulnerability has been verified (shown to ‘work’) by a second/third party and after a patch has been released. No need to cry ‘wolf’…. Most of these ‘vulnerabilities’ pop out seem to be pretty ho-hum to most of us users and from the benchmarks the ‘fix’ just slows down execution…
https://www.schneier.com/blog/archives/2007/01/debating_full_d.html
“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.”
Said of fonts and hinting as well.
SR-IOV could also complicate things more.
What do you think Google’s self-serving angle would be for reporting vulnerabilities in their competitors’ products? Maybe they get the programmers at Apple so caught up in repairing ever so esoteric attacks that they don’t have time to work on bugs that are just annoying for 99% of the rest of the users.
Whoever came up with WebGL was an idiot. Allowing remote machines to run code directly on local cores, with minimal filtering, what could possibly go wrong. Sacrificing security for faster eye candy, it is like a magician distracting you by saying “look at the pretty shiny things, NO do not look at me keep your eyes on the pretty shiny things”.
The current best solution is to search for “how to disable webgl in firefox”, “how to disable webgl in chrome”, ….
disabling webgl in firefox is easy, just go to about:config, search for “webgl.enable-privileged-extensions” and set it to “true”.
From Wikipedia, that would be (with others) Mozilla, Opera, Apple, and Google.
The examples they give for implementing a shader that exploits the vulnerability all rely on modifying the shader bytecode after compilation (which WebGL does not expose), in ways that would not be well-formed GLSL programs in WebGL.
So while yes, it is theoretically possible to exploit this via WebGL, this would also have to be paired with a shader compiler bug (GLSL compilers ARE notoriously buggy though), or some kind of vulnerability that would let you manipulate the shader bytecode from js somehow. Either way, this could be mitigated by browsers.
so what do maliciously shaded pixels look like?
i think it looks like dikpikx69.jpeg (dont google that. no! i said no! dont do that! dont look at that! *minutes later* why are you crying?)
If the title of that jpeg is an accurate description, I have no interest in googling it.
The things we learn on the streets. 🙂
“An attacker could target the most common area codes in their area”
Area codes on a mobile device?
“Because the NVIDIA drivers are also vulnerable, this could allow a malicious program on the host to run arbitrary code on the hypervisor.”
Soooo….
A gamer could send a signal to his opponent to delay the firing of his opponent’s weapon long enough for cheater to “shoot first”.
The thing is, even without step by step instructions just saying “that beach has jelly fish by the way” is normally enough for the maliciously inclined black hats to figure out how to steer jelly fish into the beach waters.
No matter how much of it you disclose, as soon as you disclose the idea or basic principle/method/vector, you are arming the opposition with a “oh I never thought of THAT” which is generally enough.
As for extortion, sure, it is in a sense a form of closed loop whereas the weapon manufacturer is also the manufacturing defensive capabilities. The thing is, there ARE real threats out there so the extortion profiteering is just a necessary evil.
Or all of this is just security theater and the entirety of cyber security is fear mongering.