Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday November 29 2014, @03:22PM   Printer-friendly
from the old-school-hacking dept.

I ran across this article from last year again and it got me thinking. The article is a story about how a hardware hacker was able to hack hard drive firmware, first to upload his own firmware, but also to take advantage of the embedded controller, and even install linux on the controller. If you haven't read it it's fairly impressive. [Ed's Comment: I would go further and say that it is a amazing piece of hacking, in the traditional meaning of the word.]

It seems that lately there have been a lot of vulnerabilities targeting embedded peripherals. Those in the article come to mind, also badUSB, and some IPMI vulnerabilities.

What do you think? Are the number of attack vectors targeting embedded peripherals a consequence of more powerful controllers? Worse software? More sophisticated attackers? Or just a random occurrence?

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Interesting) by iamjacksusername on Saturday November 29 2014, @06:19PM

    by iamjacksusername (1479) on Saturday November 29 2014, @06:19PM (#121148)

    The update mechanism for firmware in general sucks. Unless you are using SCCM, OpenManage, OpenView or another large management stack, trying to do firmware updates is incredibly difficult on groups of systems. Even with the management stacks, most places just put their heads in the sand on it. I mean, if you have a 1000 of a computer model, you have the resources to test the firmware update. If you have 5 of a computer model, it often costs the same (in terms of management and opportunity costs) as just pushing the update. So the answer becomes just do not do the update and hope it never becomes a problem. Which, to be fair, has been the case for a long time.

    I blame the manufacturers for this mostly and Microsoft for this a little bit. Firmware updates should be managed through the OS like any other update and it is the manufacturers' responsibility to make sure that happens. Microsoft is a little to blame because they make too much money selling people software to manage updates and applications. Since people are, by nature, cheap and they do not understand the value of updating such things, every Joe and Jane manufacturer rolled their own broken software update system. And that is how we got here today.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   2  
  • (Score: 2) by tynin on Saturday November 29 2014, @07:04PM

    by tynin (2013) on Saturday November 29 2014, @07:04PM (#121151) Journal

    A few years back we had to get our thousands of linux servers a firmware patch and the manufacturer only provided a windows based flash tool. Thank the flying spaghetti monster for PXE booting. I created an win95 boot floppy image with the autoexec.bat calling out to the patcher then shutting down. I tested it on one, then started rebooting the rest to use the firmware patching image. It is sort of comical watching win95 boot up on servers with piles of cores and RAM. Thankfully the whole thing went off without a hitch as I was dreading that I was going to brick a rack of servers if I wasn't careful.

    • (Score: 2, Interesting) by iamjacksusername on Saturday November 29 2014, @08:01PM

      by iamjacksusername (1479) on Saturday November 29 2014, @08:01PM (#121159)

      Welcome to updates on ESXi! It is like the year 2000 all over again when we had to build floppies to boot into DOS to run BIOS updates. For example, Dell has Linux images for the firmware but ESXi cannot process them. If you have Dell servers, they provide you a boot image builder so you can PXE- or usb boot each server that needs an update and run the bin image. It is not all Dell's fault - in a sane world, ESXi would natively support linux bin firmware installers or work with the manufacturers to provide a consistent API for flashing firmware so they could produce flash images for ESXi.

      • (Score: 2) by Arik on Sunday November 30 2014, @03:13AM

        by Arik (4543) on Sunday November 30 2014, @03:13AM (#121201) Journal
        "It is not all Dell's fault - in a sane world, ESXi would natively support linux bin firmware installers or work with the manufacturers to provide a consistent API for flashing firmware so they could produce flash images for ESXi."

        In a sane world, firmware updates would be extremely unusual, and accompanied with both a hearfelt apology and an offer to simply RMA the hardware if that is more convenient for you.
        --
        If laughter is the best medicine, who are the best doctors?
  • (Score: 2) by sjames on Saturday November 29 2014, @08:52PM

    by sjames (2882) on Saturday November 29 2014, @08:52PM (#121163) Journal

    Bricking is a big part of the problem. When a brick is a potential outcome, the testing must be more rigorous and so expensive and the justification to ignore updates grows larger. It is quite possible to make sure bricks can't happen, but most manufacturers fail miserably at it.

    On servers, let the BMC flash the main BIOS and let the OS flash the BMC (when a jumper is set).