FFS (Score: 0) by Anonymous Coward on 2015-08-24 12:33 (#J9RT) Can we go back to the days when the only way to modify the BIOS was pre-boot?!? Who ever thought that allowing an OS to modify the BIOS was ever a good idea? Re: FFS (Score: 1) by zafiro17@pipedot.org on 2015-08-24 13:12 (#J9VS) Credit goes too, to groups like Intel, who have steadily increased the 'power' and 'utility' of the BIOS to the point where it is now a fun attack vector. All this 'management code' and such - I can't be specific because I scarecely understand it, myself - is frightening.BIOS should check the hardware, hand things off to the boot loader, and then "peace out." Make any code complicated enough and begins to become a target; I think that's exactly what we've got here. Re: FFS (Score: 1) by evilviper@pipedot.org on 2015-08-24 21:05 (#JB8Z) Credit goes too, to groups like Intel, who have steadily increased the 'power' and 'utility' of the BIOS to the point where it is now a fun attack vector.Actually, the only thing that changed to make rootkits in firmware practical, is the size of the EEPROM. Back when your CMOS was 64K, there wasn't a lot of room to hide very advanced malicious code in there. Now that there's multiple megabytes to work with, there's plenty of room to store that code. You'd have these problems whether firmware got more advanced, or not. Even the simplest firmware can be modified to boot other (malicious) code first.Requiring firmware to be cryptographically signed could solve the problem... as well as a jumper on the board that disables firmware updates. OEMs just need to be encouraged to care enough to do something... Right now, they don't.
Re: FFS (Score: 1) by zafiro17@pipedot.org on 2015-08-24 13:12 (#J9VS) Credit goes too, to groups like Intel, who have steadily increased the 'power' and 'utility' of the BIOS to the point where it is now a fun attack vector. All this 'management code' and such - I can't be specific because I scarecely understand it, myself - is frightening.BIOS should check the hardware, hand things off to the boot loader, and then "peace out." Make any code complicated enough and begins to become a target; I think that's exactly what we've got here. Re: FFS (Score: 1) by evilviper@pipedot.org on 2015-08-24 21:05 (#JB8Z) Credit goes too, to groups like Intel, who have steadily increased the 'power' and 'utility' of the BIOS to the point where it is now a fun attack vector.Actually, the only thing that changed to make rootkits in firmware practical, is the size of the EEPROM. Back when your CMOS was 64K, there wasn't a lot of room to hide very advanced malicious code in there. Now that there's multiple megabytes to work with, there's plenty of room to store that code. You'd have these problems whether firmware got more advanced, or not. Even the simplest firmware can be modified to boot other (malicious) code first.Requiring firmware to be cryptographically signed could solve the problem... as well as a jumper on the board that disables firmware updates. OEMs just need to be encouraged to care enough to do something... Right now, they don't.
Re: FFS (Score: 1) by evilviper@pipedot.org on 2015-08-24 21:05 (#JB8Z) Credit goes too, to groups like Intel, who have steadily increased the 'power' and 'utility' of the BIOS to the point where it is now a fun attack vector.Actually, the only thing that changed to make rootkits in firmware practical, is the size of the EEPROM. Back when your CMOS was 64K, there wasn't a lot of room to hide very advanced malicious code in there. Now that there's multiple megabytes to work with, there's plenty of room to store that code. You'd have these problems whether firmware got more advanced, or not. Even the simplest firmware can be modified to boot other (malicious) code first.Requiring firmware to be cryptographically signed could solve the problem... as well as a jumper on the board that disables firmware updates. OEMs just need to be encouraged to care enough to do something... Right now, they don't.