4 ms·
The question about that (at about 19:30 in the video) was asked by one of the Ironic developers on my team :) The answer is basically "we don't do it, we'd lik
by cmsj 12y ago
The question about that (at about 19:30 in the video) was asked by one of the Ironic developers on my team :)
The answer is basically "we don't do it, we'd like to see it happen". I wasn't at that session, but I was at the Atlanta Summit and so far I haven't managed to get a good answer from Rackspace people about how they're actually tackling this in production today.
- cmsj 12y agoI'd also add that firmware folk tend to be pretty conservative about updates and it's an area of machines that's not used to being hardened. you only need to own it once and you can lie forever about the attempts to reflash it with a legit firmware.
- contingencies 12y agoIt's even worse with IPMI. AFAIK you can own either the IPMI BMC or the BIOS, then if one is flashed, the other can replace it to stay resident in denial of your attempts to remove it. You have to coordinate flashing both at 'the same time' (which is possibly impossible) in order to get any peace of mind. That includes situations in which the IPMI BMC isn't even plugged in to a network, because it still has constantly running firmware and backdoor access to the main system. Of course, you can do half-way mitigations like dumping firmware contents and comparing checksums over time, but no single savior probably exists. A potentially strong tool here is a hardware jumper on the mainboards that says "disallow flashing at all, full stop" and another one that says "disallow reconfiguration at all, full stop" that is honored at a level of circuitry unenslaved to software. Both the BIOS and the IPMI BMC need protections on this level.
- cmsj 12y agoEverything is worse with IPMI :) (as for half-way mitigations like dumping firmware, I would suggest that that is a fairly worthless option, malicious firmware would likely be able to return clean data to the dumper, unless it was a hardware dumper)