Seagate
Strict permissions checking sudo handling not working in openSeaChest_firmware
Following up on #158
Running the same set of testing commands, using the "testing" fixed permissions release.
- wget
- untar
- download firmware file
- unzip
sudo ./openSeaChest_Firmware -d /dev/sg0 --downloadFW firmware/MU-SAS-0008.LOD
==========================================================================================
openSeaChest_Firmware - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2024 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Firmware Version: 4.2.0-8_0_1 X86_64
Build Date: Oct 15 2024
Today: 20241015T235253 User: root
==========================================================================================
/dev/sg0 - ST32000444SS - <REDACTED> - 0006 - SCSI
Couldn't open file firmware/MU-SAS-0008.LOD
@gdevenyi,
Can you try this build from our CI? It enables some additional error messages about the directory security to help debug this issue further. I would like to see what error it reports in your case to figure out what I need to try doing next.
linux-x86_64-portable_error_msgs.zip
much improved feedback:
Insecure path detected: Directory (/home/gdevenyi/Downloads/openSeaChest-feature-Secure_File_Error_Improvements-linux-x86_64-portable/firmware) writable by others. Disable write permissions for groups
Couldn't open file firmware/MU-SAS-0008.LOD
How interesting, unzip running as my regular user vs root acts differently, I ran the same command unzip ConstellationES1-Muskie-SAS-StdOEM-0008.zip and the permissions of the firmware subdir are different.
$ ls -ld /root/openSeaChest-feature-Secure_File_Error_Improvements-linux-x86_64-portable/firmware/
drwxr-xr-x 2 root root 4096 Feb 5 2013 /root/openSeaChest-feature-Secure_File_Error_Improvements-linux-x86_64-portable/firmware/
$ ls -ld ~gdevenyi/Downloads/openSeaChest-feature-Secure_File_Error_Improvements-linux-x86_64-portable/firmware/
drwxrwxr-x 2 gdevenyi gdevenyi 4096 Feb 5 2013 /home/gdevenyi/Downloads/openSeaChest-feature-Secure_File_Error_Improvements-linux-x86_64-portable/firmware/
Looks to me like the umask is different between root (0002) and gdevenyi (0022), which I guess is a general feature you see in many systems.
I have a similar problem. I compiled the latest version of OpenSeaChest from git, but the problem persists.
$ sudo ./openSeaChest_Firmware -d /dev/sg1 --downloadFW EvansBPExosX18SATA-STD-512E-SN06.LOD
==========================================================================================
openSeaChest_Firmware - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2024 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Firmware Version: 4.2.0-8_0_1 X86_64
Build Date: Dec 4 2024
Today: 20241204T192839 User: root
==========================================================================================
/dev/sg1 - ST18000NM000J-2TV103 - <HIDE> - SN01 - ATA
Couldn't open file EvansBPExosX18SATA-STD-512E-SN06.LOD
I also get this issue as well with the latest beta version of seatools that was tweaked to add more verbose output. Trying to run this on an Unraid server to update some Exo X18 drives.
==========================================================================================
openSeaChest_Firmware - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Firmware Version: 4.2.0-9_0_0 X86_64
Build Date: May 6 2025
Today: 20250507T091850 User: root
==========================================================================================
/dev/sg2 - ST18000NM000J-2TV103 - <Removed> - SN04 - ATA
Insecure path detected: Error: Directory (/mnt/disks) owned by someone other than user or root. Owner: 99 Current User: 0. Recommended action: "chown 0:0 /mnt/disks"
Couldn't open file ../ExosX18-EvansBP-STD-SATA-512E-SN06/firmware/EvansBPExosX18SATA-STD-512E-SN06.LOD
Why is this even a thing openSeaChest does?!
What's possible security benefit is there to requiring a directory being not writable by the user's own group? The user owns the directory, they can access it anyways. Any other users within the group are likely there for a reason (such as backup access) and it's not for OSC to say it should be unreadable.
We implemented the Cert-C coding standard recommendation for checking for secure directories and some other Cert-C coding standard rules around use of files.
Our wiki also describes more about this and the common weaknesses this addresses.
These describe the reasons for checking this before trusting the file to be read or written from a directory as this was a risk identified in a third party security audit.
We have tools that reuse SeaChest, openSeaChest, and other internal tools that may output a file to a directory for another tool to process it. Following the security training I took from the openssf and others I have taken on secure C and C++ coding (and other general security) we implemented using this by default to be secure by default.
@vonericsen The explanation is reasonable and the intention is great, but enforcing group r/o does not provide any meaningful security benefit. (What possible attack is mitigated if the attacker already belongs to the same group? Is it reasonable to break valid use-cases due to that?) Enforcing it for just other-s would make more sense.
@Avamander,
Sorry for the delay getting back to you one this...sick child then wanted to run this by some other people in Seagate's various security teams first to make sure I am not missing anything.
The Cert-C link goes over why in the beginning of the description of the recommendation: to prevent tampering with a file. Anyone with write access can modify the file or subdirectories.
If a malicious actor has been given access to the same group as the user and has write permissions to the same directory, they could replace the file (in this case firmware file) with a file with known vulnerabilities that they want the user to flash to the drive. If the malicious actor only has read access to these directories, then they will not be able to tamper with the firmware file before it gets loaded to the drive.
One example could be that the user is tasked with updating the firmware on the system's (or multiple different systems) drives. Before flashing, they need to schedule a time to perform the update. The file is saved to a shared directory until this scheduled time. Meanwhile, a malicious actor has targeted someone else who has access to the same shared drive and is part of the same group as the user. The malicious actor has already been able to gather information to know the system(s) have a scheduled down time and was able to search the shared directories and find the firmware file, so they replace it with a file with known vulnerabilities. Now, when the original user goes to do the scheduled update, they don't know the file has been tampered with and flashes a firmware image with vulnerable code in it. If the shared directory that both of these users in the group had access to was not group writable, but only readable by the members of the group, the firmware file would not have been tampered with since only the owner (first mentioned user) can modify it.
Seagate and other vendors all have things within their firmware to prevent this type of attack as well at the firmware level by verifying the firmware image, but there are people trying to hack storage device firmware. There was even a report of successfully modifying HDD firmware with a persistent virus back between 2014-2016 as I recall (very old drives in this case, but I have come across websites of others trying this with modern drives too). This adds another layer of security by having the software check that the firmware was loaded from a secured directory to minimize the chance of being modified by someone else.
The Cert-C link goes over why in the beginning of the description of the recommendation: to prevent tampering with a file. Anyone with write access can modify the file or subdirectories.
Yes, but in openSeaChest's case this restriction is enforced on a group that the owner already belongs to. If they'd want to tamper, they could. Which is the overwhelming majority of systems. In any other case, any other members in such groups with write access (that do not own the file) are intentionally there. Even OpenSSH doesn't do these checks to this extent, because it's a valid use-case.
You are welcome to go argue your point with the Cert-C authors, but since I am not a security researcher, I use publicly documented security recommendations such as Cert-C to make security improvements to our software. As for OpenSSH, they can make their own security evaluations to choose which security rules they wish to implement. When Seagate evaluated this recommendation, it made sense to protect both Seagate products and software using this check.