[bug #58516] GRUB Local Privileges Escalation

[Daniel Kiper]

Update of bug #58516 (project grub):

 Privacy:  Public => Private


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58516] GRUB Local Privileges Escalation

[Noam Rathaus]

Follow-up Comment #3, bug #58516 (project grub):

Can you please share with me his email?

I am unable to locate it


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58516] GRUB Local Privileges Escalation

[Vladimir Serbinenko]

Follow-up Comment #2, bug #58516 (project grub):

This is public forum. Please send it to me and Daniel Kiper instead. Trying to
delete this

___

Reply to this item at:

  

___
  Сообщение отправлено по Savannah
  https://savannah.gnu.org/

[bug #58516] GRUB Local Privileges Escalation

[Noam Rathais]

Follow-up Comment #1, bug #58516 (project grub):

I can post the full PoC, can you just confirm that this is not visible to
everyone?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58516] GRUB Local Privileges Escalation

[Noam Rathais]

URL:
  

 Summary: GRUB Local Privileges Escalation
 Project: GNU GRUB
Submitted by: nrathaus
Submitted on: Sun 07 Jun 2020 05:30:56 AM UTC
Category: Security
Severity: Major
Priority: 5 - Normal
  Item Group: Software Error
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Noam Rathaus
Originator Email: no...@ssd-disclosure.com
 Open/Closed: Open
 Release: 
 Release: other
 Discussion Lock: Any
 Reproducibility: Every Time
 Planned Release: None

___

Details:

There is a vulnerability that allows for local privilege escalation in GRUB, a
bootloader widely used together with the Linux kernel.

Exploitation scenario #1:

1. The attacker tricks the victim into inserting a removable media device into
the target computer. USB drives, SSD cards, SATA drives, all of them work.

2. The attacker waits until the victim updates the system, namely its kernel
or drivers, and reboots.

3. The system is now fully compromised. If the target uses full-disk
encryption, the attacker gains access **after** the victim has entered the
password.

Exploitation scenario #2:

1. A disk (let's say /dev/sda2) is mounted somewhere (let's say (/mnt/sda2),
and the attacker has write access to that directory (i.e., he can put files
inside /mnt/sda2). If the attacker can only put files inside /mnt/sda2/subdir,
it won't work.

2. The attacker puts certain files there.

3. The rest is as in steps 2 and 3 from exploitation scenario #1.

We have an exploit for this vulnerability. The default payload connects to
localhost on a certain port and executes any commands sent to it. The payload
can be easily changed to connect to a remote host and port, of course.

We have tested it on Ubuntu (Ubuntu 18.04 LTS) , Debian (stretch and testing)
and CentOS. Ubuntu and Debian were vulnerable, while CentOS was not. CentOS
doesn't use the vulnerable part of GRUB by default, even though it ships the
vulnerable part anyway. I want to emphasize that the vulnerability is present
in the upstream GRUB project and is not something added by distro maintainers.
Other distros may be vulnerable as well.

Let me know if you have any questions.

I will attach additional details in a followup comment.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/