Selfblow (Don’t google that at work, by the way) is a clever exploit by [Balázs Triszka] that effects 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?
The second problem with this bootloader code is that the memory load location is embedded in the firmware header, and that location is not verified prior to loading the next bootloader stage to memory. At this point, we should all know what happens once unrestricted memory writes are allowed. How exactly the exploit takes advantage of unrestricted writes is particularly fun. The header instructs nvtboot to write the next bootloader binary on top of it’s own signature verification routine, blowing a whole in its self, hence the name. When nvtboot tries to call the function to verify that this file is properly signed by Nvidia, it instead jumps execution into this unsigned code. It’s elegant, effective, and blows the doors open for developing an open source bootloader for Tegra devices.
Encryption Backdoors
On Tuesday, Attorney General William Barr gave a speech at Fordham University. One of the topics he talked about is back doors in encryption, specifically in consumer platforms. [Bruce Schneier] takes a look at the relevant sections from the speech, and breaks it down. His take is optimistic, as he sees the conversation shifting from a stubborn insistence that encryption backdoors are harmless. Now we can at least have the discussion about whether the societal damage from weakened encryption is worth the transparency it would provide to law enforcement.
Schneier’s position on this hasn’t changed, however. He maintains that the technology is neutral, and if you allow spying on the phones of consumers, you also allow spying on the phones of nuclear plant operators, CEOs, and elected officials. Security is security.
Code That Kills
What do you do when a medical company refuses to address vulnerabilities in medical equipment? You write a proof-of-concept exploit that can kill. In their defense, the researchers at QED Secure Solutions disclosed their killer app to the FDA and coordinated the public release after a voluntary recall.
The device in question is an insulin pump that has wireless control. The built-in authentication is limited to the device’s serial number, so the attack simply spams commands at all the possible serial numbers. Their work takes advantage of Software Defined Radio and, as tested, only works from a few feet away. But it was good enough to finally get insecure devices (voluntarily) recalled.
VLC is Vulnerable?
The VLC news this week has been all over the place. First, VLC had an undisclosed vulnerability, and then more details came out about CVE-2019-13615, first classified as a Remote Code Execution vulnerability, with a score of 9.8 out of 10. VLC has been downloaded literally billions of times, so many were claiming that billions of computers were vulnerable.
The only problem with this sensational story is that the VLC devs were publicly claiming they couldn’t replicate the crash. As more and more information has leaked out, a clearer picture has emerged. Apparently the vulnerability that was found was actually in libebml, and had been found and patched over a year prior. The researcher that re-discovered the problem was working on a Linux machine that hadn’t been updated recently.
It’s not often that we get to see such a clear breakdown between the hype and reality of a vulnerability. As the VLC developers explained on Twitter, quite a few in the security community really jumped the gun in making such a big deal out of this bug. A big share of the blame needs to go to MITRE, the organization that manages the CVE process. They seemed to have entirely failed to validate the vulnerability claim before assigning a CVE number with a ridiculously high rating.
Contrary to what you might have read; no, you don’t need to uninstall VLC right away; no, there aren’t billions of suddenly vulnerable computers; and no, the current release of VLC isn’t vulnerable to this particular bug. If you have the old libs, however, you’re long overdue for an update.
No comments:
Post a Comment