Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Running a single delete command in Linux can permanently brick some laptops


  • Please log in to reply
20 replies to this topic

#1 JohnC_21

JohnC_21

  • Members
  • 23,608 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:04:29 PM

Posted 01 February 2016 - 10:20 AM

A user posted on the Arch Linux forums in early January wondering why their laptop wouldn’t boot at all after running a simple ‘rm -rf –no-preserve-root /’ command.

It’s fairly stupid to run such a command, but usually not destructive to anything but the Linux installation. However, as it turns out, on MSI laptops it’s possible to completely wipe the EFI boot partition from inside Linux.

 

Article

 

I can't understand how wiping the EFI partition on a hard drive would brick a computer. Isn't UEFI embedded in firmware? What did MSI do? Put UEFI on a hidden part of the disk instead of in firmware? What happens if you need to replace the hard drive. I must be missing something.



BC AdBot (Login to Remove)

 


#2 mremski

mremski

  • Members
  • 493 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:NH
  • Local time:04:29 PM

Posted 01 February 2016 - 11:51 AM

Without reading the link, the user would also have to add a "sudo", be logged in as root or "su"-d for that to really muck up a system.  EFI partition is just a partition on the disk, specially tagged as regards to the type.  UEFI BIOS is on the motherboard, it understands how to poke at the hardware to find the partition it is looking for so it can boot. 

 

A big takeaway from this should be:

Do not blindly run commands that you find on the internet.  Yes, even if it's something I recommend in this forum.  Just ask us:  what exactly does this command do?  Or ask Professor Google (entering "linux man somecommandname" is a good start).

 

Ok, the second takeaway should be:

Don't run as root unless you need to.


Edited by mremski, 01 February 2016 - 11:54 AM.

FreeBSD since 3.3, only time I touch Windows is to fix my wife's computer


#3 DeimosChaos

DeimosChaos

  • BC Advisor
  • 1,420 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:United States, Delaware
  • Local time:04:29 PM

Posted 01 February 2016 - 12:03 PM

That was an extremely interesting read through the forum posts. To what mremski said, I don't think they did "sudo" before the command, at least they didn't specifically say that they did.

 

Apparently systemd auto mounts the efivars. I think what happens is when you run the command it goes and erases that efivars file which then corrupts the EFI (UEFI?) chip making the machine not bootable. Take a look at this. It was posted in the ARCH forum on page 3. Look at pages 43 and 44. They talk about the potential of malware clobbering the contents of the UEFI setup variable and making a system not bootable. It proably has something to do with what the user in the ARCH  forum was experiencing.

 

Good advice mremski.


OS - Ubuntu 14.04/16.04 & Windows 10
Custom Desktop PC / Lenovo Y580 / Sager NP8258 / Dell XPS 13 (9350)
_____________________________________________________
Bachelor of Science in Computing Security from Drexel University
Security +


#4 JohnC_21

JohnC_21
  • Topic Starter

  • Members
  • 23,608 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:04:29 PM

Posted 01 February 2016 - 01:23 PM

That was an extremely interesting read through the forum posts. To what mremski said, I don't think they did "sudo" before the command, at least they didn't specifically say that they did.

 

Apparently systemd auto mounts the efivars. I think what happens is when you run the command it goes and erases that efivars file which then corrupts the EFI (UEFI?) chip making the machine not bootable. Take a look at this. It was posted in the ARCH forum on page 3. Look at pages 43 and 44. They talk about the potential of malware clobbering the contents of the UEFI setup variable and making a system not bootable. It proably has something to do with what the user in the ARCH  forum was experiencing.

 

Good advice mremski.

Thanks for that link. 

 

Kind of an old article but check this link. Seems UEFI can be more vulnerable than the old BIOS because UEFI works much more closely with the OS.

 

http://techrights.org/2013/06/24/nsa-and-uefi/



#5 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 01 February 2016 - 04:48 PM

Very interesting.

It’s fairly stupid to run such a command
-REF:http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/
It's pointless, highly dangerous if misused, but there is nothing stupid about it.

as it turns out, on MSI laptops it’s possible to completely wipe the EFI boot partition
-REF:http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/
True, but highly misleading. You can delete the ESP on any computer (unless it's read-only storage), using any OS. It's actually one of reasons why I prefer UEFI to BIOS, because I dislike using the MBR, or a BIOS boot partition. I find this actually makes it easier to back things up.

The directory that destroyed the system, which is at /sys/firmware/efi/efivars/ stores information and scripts that the computer uses to boot
-REF:http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/
My understanding is that "/sys/firmware/efi/efivars" is used to mount UEFI's non-volatile storage area, which is used for variables like additional boot-manager entries, and UEFI preferences. However, this is the first I've heard of it.

To confirm my understanding, and help distinguish the difference between what it does versus what the ESP does, I did a test using a UEFI virtual machine running Arch Linux. I'm not silly enough to try this on my host computer :P.

Test Results:
1. As you can see here, I have custom UEFI settings, and a custom entry to boot Arch Linux.
2. As you can see here, Arch Linux has automatically mounted my UEFI's efivars storage, and several variables are present.
3. As you can see here, Arch Linux hasn't mounted my ESP, and when I do, you can see Grub is installed for use with Arch Linux.
4. As you can see here, I've zeroed my ESP. Arch Linux is no longer bootable.
5. As you can see here, despite no longer having an ESP, there is still an entry for Arch Linux in my UEFI. My understanding is that this is because that info is stored in efivars, a non-volatile section of UEFI storage.
6. To prepare for this test I restored the VM from a backup so that it does have an ESP again, otherwise I'd have no way to boot Arch Linux to do this next step. As you can see here, I've attempted to delete my efivars, and most were. Some however, are not deletable, despite having appropriate privildges. My presumption is that this is because the UEFI doesn't allow these default entries to be deleted; makes sense. I take it this is where the system I'm using differs from the one the poster on the Arch forums was using. Though it doesn't explain why they cannot get into the UEFI at all.
7. As you can see here, with my efivars deleted, my UEFI preferences are gone, as is my custom boot entry for Arch Linux.
8. As you can see here, the system still works I had no trouble booting up a Debian installation disc.
 

As far as I can see there is no valid reason for an operating system to mount the efivars storage, unless the user wants to edit something. That's how the ESP is handled on most operating systems. Just one more reason for me not to use Arch Linux. I checked my Debian 8.0 UEFI VM, and it didn't automatically mount efivars. I'll have to look into how to manually mount it, just out of curiosity.

The way I read the article, and the Arch Linux thread, poor default OS settings, and a poor implementation of UEFI left the user's system exposed in a way he/she didn't know was possible. However, I'm still unclear on how the UEFI itself was wiped out. Shouldn't a UEFI screen with no boot entries have been presented?


 



#6 DeimosChaos

DeimosChaos

  • BC Advisor
  • 1,420 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:United States, Delaware

Posted 01 February 2016 - 05:08 PM

 

The way I read the article, and the Arch Linux thread, poor default OS settings, and a poor implementation of UEFI left the user's system exposed in a way he/she didn't know was possible. However, I'm still unclear on how the UEFI itself was wiped out. Shouldn't a UEFI screen with no boot entries have been presented?
 

 

I think that is kind of the whole point. No one seems to clear on how it does it... non the less, still extremely fascinating! I think this needs to be a talk at the next Black Hat. "How to nuke a system using UEFI". Of course one would need a decent amount of throw away computers to try it on....

 

By the way Hollowface, great work in trying it out in VMs.


OS - Ubuntu 14.04/16.04 & Windows 10
Custom Desktop PC / Lenovo Y580 / Sager NP8258 / Dell XPS 13 (9350)
_____________________________________________________
Bachelor of Science in Computing Security from Drexel University
Security +


#7 Guest_GNULINUX_*

Guest_GNULINUX_*

  • Guests
  • OFFLINE
  •  

Posted 02 February 2016 - 05:17 AM

Very interesting.
... 
As far as I can see there is no valid reason for an operating system to mount the efivars storage, unless the user wants to edit something.
...

How about (semi-automatic) updating the firmware or (boot)partitions after changes?

If anything this just goes to show how yet again Linux has uncovered an issue that absolutely WOULD have eventually been found and exploited by someone with malicious intent on Windows systems .. don't think it applies to Windows ?, how do you think something like EasyBSD/BCD manipulates the EFI variables if they're not exposed there too .. if they're exposed, THEY'RE EXPOSED, irrespective of the OS .. as I said, they NEED to be exposed so if they can be damaged/changed irrecoverably it's not an OS or software issue but a UEFI firmware/hardware one.

(In red my own additions...)

I also think that this is NOT a Linux thing!
 
Greets!



#8 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 02 February 2016 - 11:45 PM

How about (semi-automatic) updating the firmware or (boot)partitions after changes?

To me that doesn't justify having efivars mounted all the time. If a change needs to be made, to me that would be the appropriate time to mount it, just like the ESP is handled, and when finished, unmount again.

don't think it applies to Windows ?, how do you think something like EasyBSD/BCD manipulates the EFI variables if they're not exposed there too .. if they're exposed, THEY'RE EXPOSED, irrespective of the OS

I'm not sure where this was from, so perhaps I'm missing part of the context. I looked to see if it was from the Arch Linux thread, but the link is dead. Efivars being accessible is definitely not a Linux thing, as part of the point is for UEFI compatible operating systems to use it to add boot entries. The difference between different operating systems would be when and how they expose efivars. I do not know how Windows enables access to efivars, but I would love to know. Perhaps it mounts it to some folder somewhere too? It would very interesting to see a list of how different operating systems are dealing with efivars, but I suspect no such list exists. :(

Edited by hollowface, 02 February 2016 - 11:46 PM.


#9 raw

raw

    Bleeping Hacker


  • Members
  • 2,577 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Texas
  • Local time:04:29 PM

Posted 03 February 2016 - 12:52 AM

 

I'll have to look into how to manually mount it, just out of curiosity.

 

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

 

UEFI runtime variables:

 

efivar -l

 

 

To me that doesn't justify having efivars mounted all the time. If a change needs to be made, to me that would be the appropriate time to mount it, just like the ESP is handled, and when finished, unmount again.

 

Welcome to systemd, friend. Designed for lazy system administrators who can't

mount partitions... Firmware was never meant to be updated 'on the fly'. (IMHO)

 

 

fixed typo


Edited by raw, 03 February 2016 - 01:28 AM.

rawsig.png

 rawcreations.net          @raw_creations


Current systems: WHAT OS, BackTrack-raw, PCLinuxOS, Peppermint OS 6, Kali Linux

and a custom Linux From Scratch server hosting a bunch of top secret stuff.


#10 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 03 February 2016 - 01:05 AM

@raw

mount -t efivarfs efivarfs /sys/firmware/efi/efivarsb

 

Awesome. Just tried it on Ubuntu 14.04. This will come in handy. "efivars" though, not "efivarsb".



#11 raw

raw

    Bleeping Hacker


  • Members
  • 2,577 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Texas

Posted 03 February 2016 - 01:26 AM

No refunds due to typos... :hysterical:


rawsig.png

 rawcreations.net          @raw_creations


Current systems: WHAT OS, BackTrack-raw, PCLinuxOS, Peppermint OS 6, Kali Linux

and a custom Linux From Scratch server hosting a bunch of top secret stuff.


#12 Guest_hollowface_*

Guest_hollowface_*

  • Guests
  • OFFLINE
  •  

Posted 03 February 2016 - 02:23 AM

No refunds due to typos... :hysterical:

 

:P

 

I usually just say "I was testing you, and you passed.".



#13 cat1092

cat1092

    Bleeping Cat


  • BC Advisor
  • 7,010 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:North Carolina, USA

Posted 03 February 2016 - 03:55 AM

Heck, just installing (or booting in Live Mode) any Linux version on my Samsung Series 7 (Chronos) notebook will brick the MB, though oddly, when sent to Samsung for the $300 repair to 'unbrick' it, a Linux tool is used for the job. 

 

http://www.amazon.com/Samsung-Series-NP700Z5C-S02UB-15-6-Inch-Laptop/dp/B00A8ONW26/ref=cm_cr_pr_product_top?ie=UTF8

 

Since I have other computers, and the notebook was a gift to me for work done & only 2.5 years old when received (cost was over $1,300 new), I can skip Linux on this one. Oddly, it also doesn't support a Windows 10 upgrade, which may or may not brick the PC, yet surely will remove all Samsung software, as it did for me. 

 

The only way possible to run Linux on it is to disable Secure Boot, GPT & resort everything to Legacy settings, then it may be OK. Yet with a SSD & all, who'd want to revert everything to what one would do to install XP to run Linux? Meaning no TRIM, GC & the other functions that a SSD needs. I'll run it until 8.1 expires, at which point it'll be 11 years old & obsolete, and then go with the Legacy deal. If the computer is bricked then, so be it. :P

 

Cat


Performing full disc images weekly and keeping important data off of the 'C' drive as generated can be the best defence against Malware/Ransomware attacks, as well as a wide range of other issues. 


#14 Guest_GNULINUX_*

Guest_GNULINUX_*

  • Guests
  • OFFLINE
  •  

Posted 03 February 2016 - 04:52 AM

 

To me that doesn't justify having efivars mounted all the time. If a change needs to be made, to me that would be the appropriate time to mount it, just like the ESP is handled, and when finished, unmount again.

 

 ... Firmware was never meant to be updated 'on the fly'. (IMHO)

You are both right but...

The fact that it is mounted or not doesn't make it any safer if it can be mounted via software or a simple command (manual or even automatic). It just makes it less prone to user error... I find it to be a security flaw anyway, it's the ideal way to backdoor or brick hardware!

M$ article about the subject. It's a disaster waiting to happen if you ask me...  :whistle:

 

So it is the intention that M$ Windows 10 can update your motherboard via automatic (mandatory) updates without user interaction to anything they want? Example: no more legacy and secure boot as only option...

 

Does that make any sense or is my reasoning flawed?
 
Greets!



#15 mremski

mremski

  • Members
  • 493 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:NH
  • Local time:03:29 PM

Posted 03 February 2016 - 07:18 AM

cat:

Legacy mode simply means how the BIOS will find/boot a device.  Basically the old MBR stuff which limits you on the number of partitions. You should not be giving up TRIM or anything since that is a function of how the OS treats the underlying device of a filesystem.

 

Firmware is sometimes updated on the fly.  Anyone remember the old x86 F00F bug?  Bad microcode in the CPU.  There have been others (AMD and Intel probably about equal portions).  The kernel as it boots, very early on detects the type of CPU.  That info is used to configure different features of the kernel (page table size, fpu instructions, all kinds of goodies).  One thing that can be done is "Oh, I see I'm running on a CPU that contains bug XYZ in the micrcode.  Let me put a patch in place to work around that".  Firmware on a device is typically not rewritten on the fly without some kind of user interaction (think updating the firmware on a Linksys WRT54), but there is no reason that it could not be done without user interaction.  Some of the fancy video cards have a binary blob that is pushed by the OS driver down to FPGAs and such on the card itself (common in the embedded world).  Binary blob == firmware, different blob, different device behaviour.

 

GNULinux:  your points about the Win10 stuff are thought provoking.  Reading the link indicates that MS is providing/defining an interface, a means of updating something.  If it stopped there, nothing is overtly nefarious.  But coupled with the way Win 10 does updates (virtually no control by the user), it sure does provide a backdoor means to modify hardware the user owns without their knowledge.

But hey, we can trust MS to not do that, can't we?

 

:devil:


FreeBSD since 3.3, only time I touch Windows is to fix my wife's computer





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users