SoylentNews is people
SoylentNews
Yesterday, at the BlackHat Asia 2017 security conference, researchers from cyber-security firm Cylance disclosed two vulnerabilities in the firmware of Gigabyte BRIX small computing devices, which allow an attacker to write malicious content to the UEFI firmware.
During their presentation, researchers installed a proof-of-concept UEFI ransomware, preventing the BRIX devices from booting, but researchers say the same flaws can be used to plant rootkits that allow attackers to persist malware for years.
Cylance researchers said they've identified these flaws at the start of the year, and have worked with Gigabyte, American Megatrends Inc. (AMI), and CERT/CC to fix the flaws in time.
Affected Gigabyte devices include GB-BSi7H-6500 (firmware version vF6), and GB-BXi7-5775 (firmware version vF2).
Gigabyte is expected to release firmware vF7 for GB-BSi7H-6500 devices in the upcoming days. The GB-BXi7-5775 line is not being produced anymore and has reached EOL (End Of Life), so Gigabyte won't be releasing a new firmware for this series.
Source: BleepingComputer
(Score: 0) by Anonymous Coward on Thursday April 06 2017, @03:16AM (6 children)
Hardware makers have had the hare-brained idea of having the BIOS flashable since the 1990s, and this ability has snowballed over the years. It's gotten so far that now the BIOS/UEFI contains a mountable file system (which is automounted read-write by systemd in Linux [ycombinator.com], which makes it possible to delete the PC firmware with a badly timed or badly placed rm -rf command). The only thing that's shocking about this is that it took anywhere near this long for this to come up.
(Score: 0) by Anonymous Coward on Thursday April 06 2017, @07:22AM
That rm did not delete the firmware. It deleted some settings that were supposed to be user writable, the problem was that certain manufacturers forgot to include default values for those settings, and because of that, after removing the settings, UEFI was unable to get to a point where you could set those to a sane value.
Now that I think about it, does UEFI still store settings in battery-backed NVRAM? If so, removing the battery for a couple of minutes might lead to the same result.
(Score: 3, Insightful) by stormwyrm on Thursday April 06 2017, @07:41AM (4 children)
Numquam ponenda est pluralitas sine necessitate.
(Score: 2) by RamiK on Thursday April 06 2017, @09:12AM
Or, print a SOIC8-to-SOIC8 adapter PCB (like DIP8-to-SOIC8 [ebay.com] as used for SPI writers) that reroutes the WC* pin of the EEPROM to the ground pin thus preventing write operations.
Kinda like this [cimarrontechnology.com] but without the extra 8 pins and with different routing so you'll only print a PCB and people would stick the pins themselves so no extra soldering steps are take by either party.
*Write Control. See page 6 http://www.st.com/content/ccc/resource/technical/document/datasheet/b7/de/9b/f6/03/28/4e/8e/CD00290537.pdf/files/CD00290537.pdf/jcr:content/translations/en.CD00290537.pdf [st.com]
compiling...
(Score: 2) by Hyper on Thursday April 06 2017, @01:26PM (2 children)
Brilliant . Why don't they do this??
(Score: 0) by Anonymous Coward on Thursday April 06 2017, @04:19PM (1 child)
They used to do exactly that, back in the day, or they would have a button on the inside of the machine to accomplish the same thing. The problem is that people today like the fancy interfaces and don't like jumping through hoops if they don't see the benefit. Interestingly enough, I think we are getting to the point where they might make a comeback, as the gulf between "magic box" users and people who insist they know what they are doing seems to be widening. See Chromebooks for an example.
(Score: 2) by Hyper on Sunday April 09 2017, @01:41PM
I fail to see the benefit of allowing the OS write access at all. Isn't it just opening another attack vector?