Jump to content
exile360

Screwed Drivers privilege escalation vulnerabilities

Recommended Posts

It looks like a lot of drivers from the past several years from a multitude of hardware vendors include a nasty privilege escalation vulnerability.  Being referred to as 'Screwed Drivers', the following vendors among others which haven't been disclosed yet are affected:

·         ASRock
·         ASUSTeK Computer
·         ATI Technologies (AMD)
·         Biostar
·         EVGA
·         Getac
·         GIGABYTE
·         Huawei
·         Insyde
·         Intel
·         Micro-Star International (MSI)
·         NVIDIA
·         Phoenix Technologies
·         Realtek Semiconductor
·         SuperMicro
·         Toshiba

You can learn more about this issue at the following links:

https://www.tomshardware.com/news/screwed-drivers-report-amd-intel-nvidia-vulnerabilities,40136.html

https://eclypsium.com/2019/08/10/screwed-drivers-signed-sealed-delivered/

Share this post


Link to post
Share on other sites

Myself I find that article to be quite misleading. They make a blanket statement with no documentation whatsoever of a report to the normal channels that are used for reporting bugs. No mention (that I saw, read through it very quickly) of links to the vendors discussions, rebuttals, or further information about WHAT drivers. A very vague at best article saying "The Sky is Falling".  Seems almost like Clickbait, or slander without any type of documentation.

 

 

Share this post


Link to post
Share on other sites

Near as I can tell based on the articles I've read and videos/news I've seen about this, it's a widespread/common issue that exists due to a flaw inherent in how driver signing is handled in Windows.  Basically they found a loophole in the existing framework that allows privilege escalation and I guess each hardware vendor is going to have to address it via updates.  It's not like a nasty RCE (Remote Code Execution) vulnerability that allows open access to a system from the outside, but it is the kind of vulnerability that could potentially make it much easier for the bad guys to gain full admin/system/kernel level access to the OS once they get their foot in the door, not unlike a typical UAC/privilege bypass vulnerability/attack.  The fact that the drivers are signed presents a problem since, at least in theory, the bad guys could use a known vulnerable driver as part of a malicious patch/package to get their target to load their malware onto the system, offering them instant access to full kernel level or even to load malicious firmware onto the system (i.e. BIOS malware that could persist across a full format/reinstall of Windows).

That said, it does require that the bad guys succeed in getting some kind of user mode malware onto the system to begin with, so like always, relying on things like UAC and limited user accounts is a poor substitute for real security and safe computing practices (something I've been preaching for a long time having observed early after the launch of Windows Vista that the bad guys had designed most of their threats to run in user mode anyway specifically to bypass any UAC prompts that could potentially stop their threats in their tracks).

So no, the sky isn't falling, but it does mean that yet another feature that is supposed to help keep systems secure (i.e. driver signature enforcement) isn't nearly as bullet-proof as it was once presumed (not unlike the vulnerabilities that have been found in technologies like WEP/WPA/WPA2/WPA3 and IPv6 as well as limited user accounts and UAC over the years).

Share this post


Link to post
Share on other sites

By the way, if you want more details about what this really is and how it works I'd suggest reading their DEF CON presentation which is linked at the bottom of the article in the second link I provided in my first post.  It's a PDF of a PowerPoint presentation and gives more details on the issue.

Share this post


Link to post
Share on other sites

Is this old news, a collection of old issue reports?

I haven't checked all of them; but just taking ASUS that was know about in December 2018, I remember checking it on my Asus laptop.

https://www.bleepingcomputer.com/news/security/asus-gigabyte-drivers-contain-code-execution-vulnerabilities-pocs-galore/

Share this post


Link to post
Share on other sites

It could be.  I was checking the PDF and it showed an Intel advisory from a while back connected to this issue.  It looks like it's been known about for a while but they just recently went public with their findings (though they have yet to disclose everything as they mentioned they're working with certain vendors who operate in highly sensitive areas).  Honestly I think the scariest thing about this whole issue is the fact that the bad guys could potentially use this vulnerability to overwrite hardware firmware.  That means UEFI, BIOS and device firmware (like the VBIOS on GPUs) could be at risk for infection, and if that happens I sincerely doubt any antivirus or anti-malware program would even be able to detect its presence and formatting the operating system would do nothing to eliminate such a rootkit.  BIOS/firmware based rootkits are potentially the most dangerous kind of threat due to those issues.  Hopefully Microsoft will work out some kind of mitigation for these vulnerabilities.

In the meantime I know first-hand how simple it is to make a driver or kernel mode service accessible to user-mode input/processes as I've seen this technique used in software to allow users to control a driver's functions (this is how you can change graphics settings using the driver software for your GPU for example and also how applications like MSI Afterburner are able to tweak/overclock/control graphics hardware, and this is also how Intel's own XTU application is able to modify CPU/chipset settings that affect the BIOS for the system).  With all of these hardware vulnerabilities that have been reported recently, starting with the likes of Spectre and Meltdown, I have to wonder if there is anything at all that AV/AM vendors can do to protect devices from attacks/exploits using these vulnerabilities.  I sure hope so, but I doubt it because it probably isn't possible.  It's not the same as protecting memory and processes, especially with the restrictions that Microsoft has put in place for security that keeps AVs/AMs out of the lowest levels of memory/kernel space where hardware drivers operate and function.  As I understand it, security vendors are forced to operate outside of the kernel thanks to PatchGuard/Kernel Patch Protection; a feature that has existed in all x64 versions of Windows since XP x64/Server 2003.

Of course I am not a developer so my understanding of these things is not complete and these areas may be unrelated, but if my interpretation of what I've learned is accurate, it means that through such vulnerabilities the bad guys can essentially get more privileged/deeper level access to the OS and hardware than security vendors are able to, and that is a scary thought.

Share this post


Link to post
Share on other sites

We'll have to wait and see I suppose but my take on it is that if malware has already exploited the computer and gained system rights it can already do anything it wants including adding it's owned signed drivers that can do what it wants. As for UEFI or GPU attacks that remains to be seen too. The only successful one I recall was from a 2008 chipset driver - that was 11 years ago. I don't think there are too many users running computers that old so that is just is not a valid in the wild threat.

 

Share this post


Link to post
Share on other sites

That's the problem, this vulnerability provides ring 0 access to user mode processes; that's why I'm so concerned.  Not only that, but it also potentially gives them write access to the firmware of affected devices (UEFI/BIOS from the likes of Phoenix and American Megatrends among others; two of the most prominent BIOS makers for motherboards) so they could literally write their own malicious firmware to the devices in question, so it's not a matter of finding a vulnerability within the firmware/BIOS to exploit because this vulnerability gives them everything they need, so all they have to do is compile malicious firmware for the devices they're targeting and it's game over.  This vulnerability has a lot of potential to be very bad because of the privileged access it gives them directly from user mode; levels of access not even given to AV/AM providers I might add, nor even admin/root admin users (in other words, not even the hidden administrator account logged into Safe Mode has this level of access/permissions).  Maybe we'll get lucky as we have so far with the likes of Spectre and Meltdown and no one will exploit it widely in the wild, but such a gaping hole that potentially affects so many devices makes me very nervous, especially when it could potentially mean the installation of an undetectable rootkit in firmware that can only be removed by flashing/rewriting the firmware because it survives a full system/OS format.

Share this post


Link to post
Share on other sites

So does code written by someone that knows how to do it, that has not changed. Sorry but until some other proof beyond the lab exists for other experts to review then just like very other The Sky is Falling claims that have been around since I've been working on computers.

 

Share this post


Link to post
Share on other sites

Well, so far Microsoft has acknowledged it and Intel has released a patch for it and at least one of the BIOS vendors is preparing to issue patches for it, so I'm guessing their claims are legit.  If you didn't read the PDF, I'd highly recommend doing so as it provides a lot more details about this threat and its potential impact.

Share this post


Link to post
Share on other sites
1 minute ago, AdvancedSetup said:

Does not effect Linux or Mac - you can always format and use another OS if that concerned

Right, because the same APIs don't exist in those operating systems, however if your BIOS/firmware were already infected because of it, installing an alternate OS would do nothing to secure your system as the rootkit would still be present (of course the rootkit would still have to function within the alternate OS to be of any use to the bad guys, so whether or not that's possible is pretty unlikely based on my limited knowledge on the subject).

Share this post


Link to post
Share on other sites

Sorry, just does not scare me. Way too complex to even think of attacking thousands of different UEFI firmware. If you're even on a different version in many cases an update for your own specific model will not work. The last successful one was for 1 specific UEFI and it was from 2008. There are no known publicly successful attacks on anything newer.

They have to exploit my computer as well and somehow know my exact UEFI in order to attack it. Sorry, just not currently plausible to me, but hey, maybe I'm wrong. As Steven Crowder says "Prove me Wrong" - if I'm wrong I'll be more than happy to say I was wrong.

 

Share this post


Link to post
Share on other sites

Let me be a bit more clear. This type of attack can certainly wreak havoc on your computer and endanger your data and it should be fixed or patched. I do not believe there is currently a credible threat to UEFI at this time.

 

Share this post


Link to post
Share on other sites

Yep, that's true, for firmware at least they'd need a compatible malicious version for each system so something like this would be far more likely to be used in a targeted attack (i.e. an APT) and not so much a mass-malware epidemic.  That said, if they were to exploit a fairly common driver such as an Intel chipset or Realtek HD Audio driver or something similar which is found on most modern systems (or at least a good number of them) it could be an easy means of installing a rootkit/backdoor into those systems (though obviously not nearly as dangerous as malicious firmware).

Share this post


Link to post
Share on other sites

All firmware on any computer should be write protected on the hardware level by default. Of course you should be able to disable it with a switch.

Actually they should make that a law, firmware should be write protected by a hardware switch by default, or at the very least give people the opportunity to enable such protection if they want to.

That is something useful the EU could actually do, instead of the GDPR (which has some good things) but is  a lot of bullshit.

If you want a warning every time a web site sets a cookie, you have been able to set a web browser to do that as long as i have lived. Now they are forcing every website in the EU or accessed from the EU to have that. Just contributes to warning fatigue, do anyone seriously believe anyone actually reads the privacy policy of every website they visit (without giving any information to).

I see internet privacy as a real problem, i wouldn't search on too personal/sensitive stuff in my normal browser on Google. I don't like centralized voice chat apps like Discord due to privacy reasons. Get a serious VPN combined with private browsing/separate browser and you are good. Or just use Tor. For sensitive stuff that is, what you define as sensitive is up to you.

Share this post


Link to post
Share on other sites

Also, as long as you are a single computer user using your own PC at home, local privilege escalations aren't even a real threat, unless they can be accessed from sandboxed apps like modern browsers.

99% of every user on a personal PC is running as admins anyway, and regarding UAC bypasses, they aren't even security bugs. UAC is NOT a security boundary and shouldn't be treated as one. It has some good uses, it prevents legit programs from messing up to much by accident, and all the prompt nag has resulted in programs being better at being run as a standard user without asking for admin privileges unless they need it. UAC is very good at some things, but it's not a security boundary.

That applies even in the highest setting btw, the best thing the max setting can do is postpone whatever virus you have from getting admin rights until you, yourself perform any elevation, even on a legit app. And even a breach of that, i don't believe is seen as a  breach of a security boundary.

If you wanna prevent malware from getting admin privileges when they already have infected your computer, get a standard user account and use that for daily use.

Share this post


Link to post
Share on other sites

That's not entirely true.  Other applications/processes do not inherit admin privileges by the user authorizing an unrelated UAC prompt.  In fact, that is the entire point of UAC and the secure desktop (the darkening of the screen when a UAC prompt is displayed, which prevents application control of user input devices such as scripts and the like that might otherwise try to automate a UAC authorization for prompts related to their own processes/actions).  Most malware either installs in user space locations where the user (limited or not; a limited account actually does nothing to stop modern threats specifically because most threats are now designed to work without triggering any UAC prompts because of how permissions work in modern Windows) has full write access, such as their own local profile folders, temp folders and data folders as well as the HKCU registry hive, or they do things like creating RunOnce entries, scheduled tasks or other workarounds that allow them to remain persistent and/or gain privileged/admin access to the system without triggering a UAC prompt.

Back in the days of XP pre-UAC limited user accounts were very useful for security, but now, thanks to UAC, both because of what it has done to change the permissions/access structure of the operating system/file system/registry/memory as well as the bad guys' response to UAC by making the vast majority of threats install under the local user account/profile so that they don't have to worry about being stopped by UAC/modern Windows permissions restrictions, limited user accounts aren't nearly as useful or beneficial, at least not for security unless you are attempting to protect the system from the authorized user (for example if you have children or employees that might click 'Yes' or 'Allow' to something they shouldn't, which is also why it's a good idea in such cases to set an admin password so that they cannot authorize a UAC prompt).

Share this post


Link to post
Share on other sites

As for firmware, my concern specifically with regards to this issue is that this exploit gives the bad guys access to the drivers and processes which are authorized to update the firmware of the affected devices; something a hardware switch or some other user-controlled method could provide mitigation for, however it would have to somehow cover not just the motherboard UEFI/BIOS, but also the graphics card's firmware, the CPU's microcode/firmware and the firmware of other devices like audio chips, network cards and other devices.  That's a lot of switches to keep track of, and if all of them are hardware switches, it's either too many to include, or a single point of failure if it is a master switch that controls it for everything (something that likely isn't possible anyway, at least not with current hardware; as more and more components become integrated such a goal might become more realistic).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.