somebody got around to it. http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_plac...
The world, sooner or later, is going to get the message :-)
ron
On Sun, May 11, 2008 at 08:14:11PM -0700, ron minnich wrote:
somebody got around to it. http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_plac...
Argh. I have this allergy to IDG writers. :\ Must resist linkclickurge next time.
Oh well. As you say, we've always known this was possible.
See page 4 of ftp://stuge.se/lb/linuxbios_c3_2006.pdf - the crowd liked that. I guess they saw the possibility already then.
Oh, and I guess you could say National (or was it Cyrix already?) invented this wheel first.
//Peter
Hi,
On Mon, May 12, 2008 at 12:44 PM, ron minnich rminnich@gmail.com wrote:
somebody got around to it. http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_plac...
The world, sooner or later, is going to get the message :-)
This is old news - I remember an article from a year or so ago explaining a vulnerability that allows a video "driver" in user-space on Linux to install it's own SMM code.
SMRAM is meant to be locked by the firmware so that software can't enable SMRAM accesses. Some firmware doesn't lock SMRAM which creates the problem. Under most sane OSs you need to be running at CPL=0 to access I/O ports (and enable access to SMM space if it's not locked) so it doesn't matter as much (because if you're running at CPL=0 anyway you don't need SMM to bypass security), but some OSs aren't so good at protecting I/O ports.
Of course if everyone was using coreboot things would be much easier (for hackers)...
AFAIK coreboot doesn't lock SMM space on *any* chipset, and also leaves "SMRAM base" set to the default address 0x00030000 so that the SMRAM area isn't underneath the legacy video display memory area (from 0x000A0000 to 0x000BFFFF) and can be accessed/modified regardless of whether SMRAM is locked or not, or whether or not access to SMRAM is enabled or not.
Of course there's always the added bonus that a hacker can download the source code for coreboot, add their own malicious code, compile, flash it and then sell the system on eBay to any unsuspecting sucker. Coreboot really is the "rootkit friendly" way to go... :-)
Cheers,
Brendan
Brendan Trotter wrote:
AFAIK coreboot doesn't lock SMM space on *any* chipset
It does on K8, since years.
Stefan
On Sun, May 11, 2008 at 11:49 PM, Brendan Trotter btrotter@gmail.com wrote:
Of course there's always the added bonus that a hacker can download the source code for coreboot, add their own malicious code, compile, flash it and then sell the system on eBay to any unsuspecting sucker. Coreboot really is the "rootkit friendly" way to go... :-)
Actually, you have just recapitulated the same mythology that OS vendors used for so many years to justify proprietary, closed-source OSes: binary-only OSes were somehow "safer" because *only* the vendor could change them; open source OSes were dangerous because any bad guy could modify them. The fact is, to a sufficiently determined and resourceful hacker, binary vs. source based OS is not really an impediment. In fact, binary is better: there is no chance of checking or verification, and people foolishly trust it more.
Or do you believe all those windows rootkits do not exist?
If I have a system with BIOS source code available, I can always verify what's in BIOS. That's not the case for binary BIOS; all kinds of stuff can hide in there, esp. if it is an EFI system, which is a complete operating system and has huge amounts of room for nasty bits of code.
So, to say the least, I don't accept your argument that open source BIOS is somehow more "hacker" friendly, unless you mean in the 1980s sense of the word: the lonely guy in the basement. That model is long dead. Hackers now are well financed and rich in tools and experience. Binary is not an impediment to them. Binary is an impediment to those of us who want security.
thanks ron
Hi,
On Tue, May 13, 2008 at 12:47 AM, ron minnich rminnich@gmail.com wrote:
On Sun, May 11, 2008 at 11:49 PM, Brendan Trotter btrotter@gmail.com wrote: So, to say the least, I don't accept your argument that open source BIOS is somehow more "hacker" friendly, unless you mean in the 1980s sense of the word: the lonely guy in the basement. That model is long dead. Hackers now are well financed and rich in tools and experience. Binary is not an impediment to them. Binary is an impediment to those of us who want security.
How long would it take you to add some code to coreboot that displays the string "Hello world"? How long would it take you to add some code to a proprietary BIOS that displays the string "Hello world"?
After you've measured how long it takes, give both modified binaries and both original binaries to your Grandparents (who I assume are normal people, without programming experience), and find out how long it takes them to figure out which binaries are the unmodified originals (without your help).
Of course this is just a silly side issue. The main reason for my post was to highlight your hypocrisy - "Everyone look! Some propretory BIOS has an SMM related vulnerability! The world, sooner or later, is going to get the message :-)". It's like a morbidly obese person laughing at how large a slightly chubby person is, or a heroin dealer complaining that alcohol should be banned because it's bad for your health. Not that SMM vulnerabilities are the only security holes in coreboot (you might want to do a web search for "blue pill" and consider implementing an "enable/disable VMX" option somewhere).
Cheers,
Brendan
On Tue, May 13, 2008 at 08:41:03PM +0930, Brendan Trotter wrote:
Not that SMM vulnerabilities are the only security holes in coreboot (you might want to do a web search for "blue pill" and consider implementing an "enable/disable VMX" option somewhere).
Discussion or even patches are both most welcome!
Security has not been a great focus in coreboot so far, but that is not because we like to make it unsecure, rather that we have enough to do to get it working at all.
It would be great to have some help! Everyone is invited.
//Peter
On 13.05.2008 13:11, Brendan Trotter wrote:
Of course this is just a silly side issue. The main reason for my post was to highlight your hypocrisy - "Everyone look! Some propretory BIOS has an SMM related vulnerability! The world, sooner or later, is going to get the message :-)". It's like a morbidly obese person laughing at how large a slightly chubby person is, or a heroin dealer complaining that alcohol should be banned because it's bad for your health. Not that SMM vulnerabilities are the only security holes in coreboot (you might want to do a web search for "blue pill" and consider implementing an "enable/disable VMX" option somewhere).
Well, then let's be glad that the SMM based vulnerabilities in coreboot have been fixed literally years ago.
Regards, Carl-Daniel
On Tue, May 13, 2008 at 4:11 AM, Brendan Trotter btrotter@gmail.com wrote:
Of course this is just a silly side issue. The main reason for my post was to highlight your hypocrisy - "Everyone look! Some propretory BIOS has an SMM related vulnerability! The world, sooner or later, is going to get the message :-)".
gosh, you've missed my point twice now and called me a hypocrite in the bargain?
I'll try again. Then I'll give up.
An end-user can, if they need to, have a far better chance of verifying a coreboot-based system than they can have of verifying a binary-only system, in the same sense that they can have more confidence in a system based on open source than on binaries. In the limit, they can build, burn, and flash their own firmware, replacing that which came from the factory. That's simply not possible with a binary-only BIOS.
That's not to say that either is perfect. I'll let you consider the relative difficulty of verifying coreboot source vs. binary firmware for end-users who probably won't get the source.
Your idea that one would corrupt a single system and sell it on ebay is just naive, and as you pointed out, it's sily.
Finally, the idea that it is somehow harder to corrupt a binary-only based firmware system to which one has no source, vs. a binary only coreboot for which one has source, given the kind of resources that the bad guys have nowadays, is also quite naive (you should take it as a given that they *already have* the source to all the BIOSes out there anyway).
Which leaves me wondering what point you were trying to make in the first place.
ron
The main point to bring home is that these whiz-bang features in modern firmware such as SMM not only over-complicate the design but they also have unintentional consequences such as creating gaping holes in security.
A lot of control is being handed off to obscure parts in firmware and executed in privileged mode these days, and there be dragons along the way.
On Sun, May 11, 2008 at 11:49 PM, Brendan Trotter btrotter@gmail.com wrote:
Hi,
On Mon, May 12, 2008 at 12:44 PM, ron minnich rminnich@gmail.com wrote:
somebody got around to it.
http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_plac...
The world, sooner or later, is going to get the message :-)
This is old news - I remember an article from a year or so ago explaining a vulnerability that allows a video "driver" in user-space on Linux to install it's own SMM code.
SMRAM is meant to be locked by the firmware so that software can't enable SMRAM accesses. Some firmware doesn't lock SMRAM which creates the problem. Under most sane OSs you need to be running at CPL=0 to access I/O ports (and enable access to SMM space if it's not locked) so it doesn't matter as much (because if you're running at CPL=0 anyway you don't need SMM to bypass security), but some OSs aren't so good at protecting I/O ports.
Of course if everyone was using coreboot things would be much easier (for hackers)...
AFAIK coreboot doesn't lock SMM space on *any* chipset, and also leaves "SMRAM base" set to the default address 0x00030000 so that the SMRAM area isn't underneath the legacy video display memory area (from 0x000A0000 to 0x000BFFFF) and can be accessed/modified regardless of whether SMRAM is locked or not, or whether or not access to SMRAM is enabled or not.
Of course there's always the added bonus that a hacker can download the source code for coreboot, add their own malicious code, compile, flash it and then sell the system on eBay to any unsuspecting sucker. Coreboot really is the "rootkit friendly" way to go... :-)
Cheers,
Brendan
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Brendan Trotter -
Carl-Daniel Hailfinger -
David Hendricks -
Peter Stuge -
ron minnich -
Stefan Reinauer