I am currently evaluating the impact that the recent NUC Firmware Advisory has on our machines.

What confuses me is that fact that those vulerabilities are scored with

  • a high risk score, but
  • require(!) administrative privileges to exploit (CVSS: PR:H).

Do I need to worry about this kind of vulnerability? The high risk score implies yes, but I have a hard time imagining what additional relevant damage an attacker who already(!) has administrative privileges (and, thus, already has complete control of the data stored on the device) can do by exploiting a security vulnerability on that system.

  • You ask two different questions: "Do I need to worry about this specific thing?" and "What additional damage can an attacker do?". Please edit your question to clarify what you are asking about.
    – user163495
    Jun 14, 2019 at 8:13
  • Are you sure that it needs "admin" privileges or just elevated privileges? The wording says "privileged user" not "admin".
    – schroeder
    Jun 14, 2019 at 8:15
  • Read about the difference between root (or admin) and kernel mode.
    – forest
    Jun 14, 2019 at 8:15
  • @schroeder: The tooltip of the CVSS option says "significant (e.g. administrative) control over the vulnerable component".
    – Heinzi
    Jun 14, 2019 at 8:16
  • 1
    @forest: Interesting, thanks for the pointer. That only makes a difference if root/admin cannot "inject" kernel code, e.g., by installing unsigned drivers, right? If you could expand on that (from a risk-assessment point of view), I think this would make the basis for a great answer.
    – Heinzi
    Jun 14, 2019 at 8:52

3 Answers 3


Your question does not distinguish between administrative privileges, and "highest privileges possible".

Where to go when you have elevated privileges?

"Elevated privileges" are not the highest you can go. Even though you might be administrator, the operating system kernel can still deny you access to some resources or to perform some actions. Furthermore, reinstalling the operating system will wipe your access (as long as the new system is not vulnerable again).

So in short, when you have elevated privileges, you can still get kernel privileges.

Where to go when you have kernel privileges?

When you have kernel privileges, you act as the operating system. Nobody can deny you access to resources, unless they were designed not to be accessible by anyone, because there is nobody to deny you.

This might seem like the ultimate privilege escalation, but you can still go further and become the Hypervisor.

Where to go when you have hypervisor privileges?

Have a look at this chart:

Type-1 Hypervisor Image

On a system set up with a Type-1 Hypervisor, several operating systems can run in parallel. Even the kernel of one operating system has no access to, or is aware of, the other operating system.

However, an exploit in the hypervisor could allow you to take over the hypervisor and give you complete access to all operating systems on the machine.

So where would you go from here? If you imagine the operating system bubbles in the chart to contain a "user space" and a "kernel space", then we gradually moved down from the privileges of a normal user, to the privileges of an elevated user, to those of the kernel and now to those of the hypervisor. It would only make sense to keep moving down, which would lead to the firmware, the abstraction layer between hardware and software.

Taking over the firmware would allow you to persist your malware, even when the operating system or the hypervisor are wiped clean. The only way to go even further is to exploit the hardware directly, as is the case with some hardware bugs.


The short answer is Yes. The reason is simple, while some vulnerabilities requires Administrative privileges, other vulnerabilities bypass the UAC mechanism that prevents unattended elevation to Administrator privileges so combining the two creates the risk.


To answer your first question: Yes you have to worry about this and you should fix this because it is still a vulnerability. And Admin can perform tasks which he is not supposed to do.

If you are worried about damage that this vulnerability can cause then you can think from ROI perspective. If it is going to cost too much money / resource / effort to fix this, you can accept the risk and mitigate it in a different way.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .