2

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.

Heinzi
  • 2,914
  • 2
  • 21
  • 25
  • 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. –  Jun 14 '19 at 08:13
  • Are you sure that it needs "admin" privileges or just elevated privileges? The wording says "privileged user" not "admin". – schroeder Jun 14 '19 at 08:15
  • Read about the difference between root (or admin) and kernel mode. – forest Jun 14 '19 at 08:15
  • @schroeder: The tooltip of the CVSS option says *"significant (e.g. administrative) control over the vulnerable component"*. – Heinzi Jun 14 '19 at 08:16
  • @MechMK1: I see the latter as a (longer) clarification about what I am looking for in an answer. I tried to clarify it in the question. Is it better now? – Heinzi Jun 14 '19 at 08:19
  • @Heinzi ... right ... so that can include a privileged user getting admin rights. – schroeder Jun 14 '19 at 08:24
  • @schroeder: True, but since "regular admin" and "regular user" are the two most common user types (especially for the use cases of a NUC), that would mean that this issue only affects rare corner cases where you have a "restricted admin" or a "user with specific additional privileges". Call it a gut feeling, but I somehow doubt that this is the case. – Heinzi Jun 14 '19 at 08:31
  • @Heinzi and I agree with you in this case. But I guess I'm asking to confirm this else your entire question kind of falls down – schroeder Jun 14 '19 at 08:33
  • 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 '19 at 08:52
  • @Heinzi this is basically what I'm saying. Admin does not necessarily mean "all access". If your question is "what damage can be done when you already have the highest privs?" then that's one thing. If you are asking what extra privs you can get from this particular vulnerability, that's a completely different thing. – schroeder Jun 14 '19 at 08:57
  • @schroeder: I see. Well, the answer to the first is probably "none" (right?) and the second might be too specific (or, with the information available at the moment, unanswerable). I guess what I was looking for was an answer to the question in the title that starts with "Yes, if..." and explains under which *specific circumstances* I should be worried about privilege escalation "above" a standard Windows Administrator or Linux root account. – Heinzi Jun 14 '19 at 09:10

3 Answers3

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.

1

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
DentistOfDetroit
  • 13
  • 4
1

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.

Michael Haephrati
  • 172
  • 11