Securing grub

[jiml8]

I ran across this:

http://www.welivesecurity.com/2017/01/0 ... ter-060117

A bit of digging (which was not provided in the article, sadly) reveals that the attack vector is spearphishing. This suggests that a careful person on a properly configured workstation won't be vulnerable. Also, nothing I have seen suggests that there is a privilege elevation exploit in use here, so a normally secured Linux workstation or server should not be vulnerable, unless it exposes a root-enabled interface to the internet.

Nonetheless, it would seem that one of the attacks this malware executes are against grub directly.

So, I did an ls -al on /dev/sd* in my workstation, and here is the result:

Code: Select all

brw-rw-rw- 1 root root 8,  0 Jan  6 12:46 /dev/sda
brw-rw-rw- 1 root root 8,  1 Jan  6 12:46 /dev/sda1
brw-rw-rw- 1 root root 8, 16 Jan  6 12:46 /dev/sdb
brw-rw-rw- 1 root root 8, 17 Jan  6 12:46 /dev/sdb1
brw-rw-rw- 1 root root 8, 32 Jan  6 12:46 /dev/sdc
brw-rw-rw- 1 root root 8, 33 Jan  6 12:46 /dev/sdc1
brw-rw-rw- 1 root root 8, 34 Jan  6 12:46 /dev/sdc2
brw-rw-rw- 1 root root 8, 37 Jan  6 12:46 /dev/sdc5
brw-rw-rw- 1 root root 8, 48 Jan  6 12:46 /dev/sdd
brw-rw-rw- 1 root root 8, 49 Jan  6 12:46 /dev/sdd1
brw-rw-rw- 1 root root 8, 50 Jan  6 12:46 /dev/sdd2
brw-rw-rw- 1 root root 8, 53 Jan  6 12:46 /dev/sdd5
brw-rw-rw- 1 root root 8, 64 Jan  5 16:56 /dev/sde
brw-rw-rw- 1 root root 8, 80 Jan  6 12:46 /dev/sdf
brw-rw-rw- 1 root root 8, 81 Jan  6 12:46 /dev/sdf1


Thus, it seems that such an attack would be able to write to the MBR (or UEFI blocks) of any volume, working as any user.

So. My question is this: What happens if the volume permissions are changed to 644 rather than 666? I hesitate to try it on my workstation, and don't have anything else handy right now. Would this impact writes to drives by non-root users?

[Lebarhon]

Strange, here is what I get on my workstation

Code: Select all

brw-rw---- 1 root disk 8,  0 janv.  7 09:31 /dev/sda
brw-rw---- 1 root disk 8,  1 janv.  7 09:31 /dev/sda1
brw-rw---- 1 root disk 8, 16 janv.  7 09:31 /dev/sdb
brw-rw---- 1 root disk 8, 17 janv.  7 09:31 /dev/sdb1
brw-rw---- 1 root disk 8, 18 janv.  7 09:31 /dev/sdb2
brw-rw---- 1 root disk 8, 21 janv.  7 09:31 /dev/sdb5


[jiml8]

Well, based upon your response, I did a chmod 660 /dev/sd* and I have noticed no ill effects. Predictably, dd as an ordinary user no longer works, and this is desirable.

I have no idea at all why my system is reporting them as 666 and, if fewer permissions work, I want to change the system to apply fewer permissions at startup. If possible, 640 or 440 would be great.

Does anyone here know how to change that startup setting? I think I will look in udev...

[Lebarhon]

Did you have a look at msec?
http://docteam.mageia.nl/en/MCC/content/msecgui.html

[doktor5000]

Does anyone here know how to change that startup setting? I think I will look in udev...

Should be in the core udev rulesets, yes. The sysem rules are in /usr/lib/udev/rules.d from what I remember, can't look currently.

[petedan10]

I think that the most secure way to secure grub is to maybe take it onto hardware using coreboot. There are even more advanced projects like https://trmm.net/Installing_Heads

Hope someone more knowledgeable than me will chime in and give more details.

[jiml8]

It seems that when I change the permissions to 660 on /dev/sd*, something in the system changes them back to 666 within a minute or two.

I have looked at the udev rules, but I don't think anything there could be doing this. Seems to me some daemon must be doing it, but I don't know who.

I have added an msec rule to set the rules to 660, as part of the daily check, and it works...I tested it. But within a minute or two...back to 666.

This does strike me as a security hole, and I really would like to fix it.

[jiml8]

Ok, I figured out that the change was being made by udisks-daemon. After reading a bit, I learned that this daemon does use udev rules.

So, I copied the file /usr/share/udev/rules.d/60-persistent-storage.rules to /etc/udev/rules.d/60-persistent-storage.rules. The file in /etc/udev/rules.d will override the one in /usr/share/udev/rules.d.

I then edited this file, and this is the result:

Code: Select all

# persistent storage links: /dev/disk/{by-id,by-uuid,by-label,by-path}
# scheme based on "Linux persistent device names", 2004, Hannes Reinecke <hare@suse.de>

# forward scsi device event to corresponding block device
ACTION=="change", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST=="block", ATTR{block/*/uevent}="change", MODE="660"

ACTION=="remove", GOTO="persistent_storage_end"

# enable in-kernel media-presence polling
ACTION=="add", SUBSYSTEM=="module", KERNEL=="block", ATTR{parameters/events_dfl_poll_msecs}=="0",
ATTR{parameters/events_dfl_poll_msecs}="2000", MODE="660"

SUBSYSTEM!="block", GOTO="persistent_storage_end"

# skip rules for inappropriate block devices
KERNEL=="fd*|mtd*|nbd*|gnbd*|btibm*|dm-*|md*|zram*", GOTO="persistent_storage_end"

# ignore partitions that span the entire disk
TEST=="whole_disk", GOTO="persistent_storage_end"

# for partitions import parent information
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*"

# virtio-blk
KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"

# ATA devices using the "scsi" subsystem
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", ATTRS{vendor}=="ATA", MODE="660", IMPORT{program}="ata_id --export $devnode"
# ATA/ATAPI devices (SPC-3 or later) using the "scsi" subsystem
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", ATTRS{type}=="5", ATTRS{scsi_level}=="[6-9]*", MODE="660", IMPORT{program}="ata_id --export $devnode"

# Run ata_id on non-removable USB Mass Storage (SATA/PATA disks in enclosures)
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", ATTR{removable}=="0", SUBSYSTEMS=="usb", IMPORT{program}="ata_id --export $devnode"
# Otherwise, fall back to using usb_id for USB devices
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"

# scsi devices
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $devnode", ENV{ID_BUS}="scsi"
KERNEL=="cciss*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id --export --whitelisted -d $devnode", ENV{ID_BUS}="cciss"
KERNEL=="sd*|sr*|cciss*", ENV{DEVTYPE}=="disk", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}"
KERNEL=="sd*|cciss*", ENV{DEVTYPE}=="partition", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n"

# firewire
KERNEL=="sd*[!0-9]|sr*", ATTRS{ieee1394_id}=="?*", SYMLINK+="disk/by-id/ieee1394-$attr{ieee1394_id}"
KERNEL=="sd*[0-9]", ATTRS{ieee1394_id}=="?*", SYMLINK+="disk/by-id/ieee1394-$attr{ieee1394_id}-part%n"

KERNEL=="mmcblk[0-9]", SUBSYSTEMS=="mmc", ATTRS{name}=="?*", ATTRS{serial}=="?*", ENV{ID_NAME}="$attr{name}", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/mmc-$env{ID_NAME}_$env{ID_SERIAL}"
KERNEL=="mmcblk[0-9]p[0-9]", ENV{ID_NAME}=="?*", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/mmc-$env{ID_NAME}_$env{ID_SERIAL}-part%n"
KERNEL=="mspblk[0-9]", SUBSYSTEMS=="memstick", ATTRS{name}=="?*", ATTRS{serial}=="?*", ENV{ID_NAME}="$attr{name}", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/memstick-$env{ID_NAME}_$env{ID_SERIAL}"
KERNEL=="mspblk[0-9]p[0-9]", ENV{ID_NAME}=="?*", ENV{ID_SERIAL}=="?*", SYMLINK+="disk/by-id/memstick-$env{ID_NAME}_$env{ID_SERIAL}-part%n"

# by-path (parent device path)
ENV{DEVTYPE}=="disk", DEVPATH!="*/virtual/*", IMPORT{builtin}="path_id"
ENV{DEVTYPE}=="disk", ENV{ID_PATH}=="?*", SYMLINK+="disk/by-path/$env{ID_PATH}"
ENV{DEVTYPE}=="partition", ENV{ID_PATH}=="?*", SYMLINK+="disk/by-path/$env{ID_PATH}-part%n"

# skip unpartitioned removable media devices from drivers which do not send "change" events
ENV{DEVTYPE}=="disk", KERNEL!="sd*|sr*|hd*", ATTR{removable}=="1", GOTO="persistent_storage_end"

# probe filesystem metadata of optical drives which have a media inserted
KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
  IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
# single-session CDs do not have ID_CDROM_MEDIA_SESSION_LAST_OFFSET
KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
  IMPORT{builtin}="blkid --noraid"

# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{builtin}="blkid"

# watch metadata changes by tools closing the device after writing
KERNEL!="sr*", OPTIONS+="watch"

# by-label/by-uuid links (filesystem metadata)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"

# by-id (World Wide Name)
ENV{DEVTYPE}=="disk", ENV{ID_WWN_WITH_EXTENSION}=="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}"
ENV{DEVTYPE}=="partition", ENV{ID_WWN_WITH_EXTENSION}=="?*", SYMLINK+="disk/by-id/wwn-$env{ID_WWN_WITH_EXTENSION}-part%n"

# by-partlabel/by-partuuid links (partition metadata)
ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_UUID}=="?*", SYMLINK+="disk/by-partuuid/$env{ID_PART_ENTRY_UUID}"
ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_ENTRY_NAME}=="?*", SYMLINK+="disk/by-partlabel/$env{ID_PART_ENTRY_NAME}"

# add symlink to GPT root disk
ENV{ID_PART_ENTRY_SCHEME}=="gpt", ENV{ID_PART_GPT_AUTO_ROOT}=="1", SYMLINK+="gpt-auto-root"

LABEL="persistent_storage_end"


Essentially, my edits consist of removing the first line of the file, which said "do not edit this file...it will be overwritten" and in adding the string: MODE="660" at 4 spots that looked right to me in the file.

Since I made this change, I have not seen udisks-daemon changing the mode of the /dev/sd* entries again. Not enough time has elapsed yet for me to be sure I have solved my problem, but it does look promising.

[jiml8]

And right after I made my previous post, udisks-daemon made another poll, and reported changes to all the /dev/sd* (which seems to be normal behavior for it every few minutes). I checked, and my permissions on the /dev/sd* remain at 660. So I have solved the problem.