Welcome, Guest. Please login or register.

Author Topic: UEFI Palladium reborn Nightmare.  (Read 8361 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show all replies
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« on: September 27, 2011, 07:13:04 PM »
The article might be sensationalized, but if you think Microsoft aren't going to take any edge they can possibly get as long as it doesn't get them in trouble, you haven't been paying attention for the past twenty-six years.
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show all replies
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #1 on: September 27, 2011, 11:26:10 PM »
Quote from: LoadWB;661596
If the manufacturer will not provide you with what's necessary to undo that and install another OS, then you buy from someone else.  Period.
Yeah, that works as long as you assume that there's enough demand for alternative-OS booting that manufacturers don't think it's worthwhile to let themselves be bought off. After all, it's not like Microsoft has been known to strong-arm PC vendors out of providing alternative OSes before, or anything...
Quote
The benefits of the Trusted Platform far outweigh the negatives in the DRM-scare camp.  

We will see more of this UEFI/TPC stuff coming down the pipe, and it needs to.  It is virtually impossible to secure a system with software alone.  There must be cohesion between the hardware and software.  After all, trusted software is only as trust-worthy as the hardware on which it runs.
Could you please explain to me what real benefits this would offer? Because if it just down to preventing booting of unauthorized operating systems for security purposes...you can do that with existing computers. Every half-decent BIOS in every motherboard manufactured in the past five years has had the ability to disable booting from external media, and to secure the BIOS itself via password. It's not going to be any more help against theft, either; if your security model is such that theft is a realistic possibility, it's not the computer that's the problem.
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show all replies
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #2 on: September 28, 2011, 12:33:42 AM »
Quote from: LoadWB;661610
This is just a basic example, and just the tip of the iceberg.  Prevention of unauthorized changes to the processes in the system responsible for initial boot prior to hand-off to the operating system, for one.
Again, though, this is entirely possible to accomplish without mechanisms that could be co-opted to enforce software lock-in.
Quote
Two of the infection vectors used by Stuxnet would have been stopped by an operational trusted-platform system, as could the TDSS root-kit.
And how many of them couldn't have been stopped with a less problematic method of boot security?
Quote
I hope you're just trolling, because it seems like you're stuck on the alternate-boot idea, forgetting for a second that a BIOS password can be defeated.  The first maxim of security is, simply put, if they own our box they own your data.  If physical security is a problem, your issues are elsewhere.
That's entirely my point - boot security isn't a question of whether you're using signed or unsigned software from an external source, it's whether you're letting there be an option of using software from an external source. If security is a concern and yet you're leaving the possibility of booting the system from a removable drive, you're doing it wrong.

You do have a fair point about BIOS passwords not being flawless - so make it a jumper setting on the board or something. It's not that hard to come up with solutions other than "put the entire system under the control of a licensing authority that you don't know can't be bought off or themselves cracked" (say, for example, DigiNotar's recent breach.)
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show all replies
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #3 on: September 28, 2011, 03:41:52 AM »
Quote from: LoadWB;661620
Interesting.  So, what you're telling me is that a firmware based root-kit is absolutely possible to detect in software which has to implicitly trust the hardware which has been infected.
No, what I'm saying is that if it is even possible for the firmware to be infected, the system is fundamentally insecure. Making it possible to detect altered firmware isn't a bad idea, but it's skirting the real problem.
Quote
This does not rebuke in any way the efficacy of the platform.

Even so, I would not argue that I shouldn't bother to put a dead-bolt on my door because the window can be kicked in.
I never questioned the efficacy. I simply believe that this specific use (to wit: barring non-signed operating systems) has unsettling implications that (considering the much more fundamental issues raised when it would otherwise be possible to boot the computer off an external device) ought to give people pause to consider whether it's really worth pursuing this course and not similarly-effective but less easily co-opted approaches.

If you want to use a house analogy, the approach Microsoft is taking is like installing a burglar alarm so you don't have to worry about leaving the door unlocked.
Quote
A general compromise like that is always a problem.  Look at the code signing certificates for Microsoft which were used to sign trojan drivers, or the sound card manufacturer whose signing keys were pilfered.  Keeping your private keys private is absolutely a concern -- vendors are being encouraged to protect them as though lives depend upon their safety -- but not any reason to junk the entire idea.  And it can be done; AFAIK, no one has yet cracked the encryption used to apply micro-code patches to Intel processors.
The funny thing about "has not been cracked yet" is that it almost inevitably winds up as "oh hey, that's been cracked." The only reason Intel microcode encryption hasn't been cracked is because that's too low-level for people to bother with when there's much simpler security holes to shoot for. And my concern is less about crackers, anyway, and more about the possibility of an industry behemoth like Microsoft paying off PC vendors to include only Windows keys in the TPM. They have shown in the past that they're not above such tactics, as long as they think their ass is covered legally.

"Trusted computing" necessitates that you trust someone; really protected computing would require no such thing.
Quote
To summarize: password-protecting the BIOS, setting the BIOS jumper to "write protect," and disabling external boot devices is not enough anymore.
Why not? In a sane OS, the system software would not be writeable (or, indeed, accessible) by user processes, and hardware BIOS protection would prevent booting into less secure operating systems without the need for a certifying authority. Any OS that does not protect itself is fundamentally damaged and in need of repair, not workarounds that fail to address the issue and open up a whole host of possibilities for abuse.
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show all replies
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #4 on: September 28, 2011, 04:13:03 AM »
Absolutely correct, all you can ever do is approach it. But there's multiple ways to do that, and some of them don't involve going off on bunny trail like OS signage when the root causes could be addressed instead.
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show all replies
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #5 on: September 28, 2011, 06:16:30 AM »
Quote from: LoadWB;661630
I still assert that you're absolutely incorrect.  Hardware and software cannot be left perpetually immutable, and the changes necessarily inherent must be able to be validated in order to be trusted.  Allowing authorized changes also necessarily invites unauthorized modifications.
They don't have to be left immutable, there just has to be real controls on the mutability: proper filesystem permissions and permissions enforcement for software, and real write-protection for firmware. There's always going to be the need for an administrator role in which these things can be taken care of, but Microsoft apparently intends UEFI to be an administrator of the administrator. This is stupid.

In any real-world system you're going to have to trust someone, and it makes a hell of a lot more sense to have that be someone you know and whom you can directly interact with (and, if you're a business, someone who's on your payroll) rather than a faceless megacorporation that has no real incentive to pay attention to your needs when there's millions of other people who don't care as long as their vanilla setup boots.

I work in IT, I've seen how much hell my boss has to go through just to even get ahold of the vendors for our equipment, let alone get them to actually fix it. If any of us was allowed to touch the rig, though, we could probably take care of at least the basic issues. Why, in God's name, would you ever want more of these relationships at even lower levels in your computing setup?
Quote
I believe that the TPC addresses this well, in which you can have completely separate entities, in hardware and software, readily identify each other for the purpose of trust.
Again, my complaint isn't that it doesn't work. It's that there are simpler ways to achieve the same goal that don't involve the creation of licensing authorities who could very easily find themselves having a stake in which software gets to run on what hardware.
Quote
There is no "sane" OS in which you can perfectly achieve separation between user and system which cannot be breached.  I remember when BSD jails were the end-all be-all, and then they were broken.
You're right. That means they need to get fixed, not introduce another layer of the checks with an option to lock out whatever the vendor doesn't want you running.
Quote
None of this withstanding, on the whole, anti-TPM arguments reek of the disciples of Stallman, who has a rampant distrust for the Evil Corporations.  The reaction to the Trusted Platform is wholly over-blown, just as much as every new security measure which has been decried as Yet Another DRM.
You know what, though? We need paranoiacs like Stallman. The whole direction of industry thought in the past fifteen years has been this idea that control needs to be taken away from end-users, not just in specific environments like business networks where it can pose a problem, but in general, on principle. DRM, "trusted computing," the talk of "cloud computing" as The Future of Everything Computer, they're all instances of the same general trend, to bring as much as possible in the computer under the control of authorities as far from the person in front of the keyboard as possible. This is not what the personal computer was supposed to be about.

Yes, Stallman is weird, paranoid, didactic, and most probably overstating the case, and certainly many of his followers are. But as they say, "just because you're paranoid doesn't mean they're not after you." Maybe you're right and this whole business is just Microsoft abandoning every sinister megalomaniacal tendency they've ever shown and working for the good of the public without regard to OS turf wars - but what if it's not?

We need crazy, paranoid streetcorner ravers in this industry because the whole God-damn rest of it is so content to go along with whatever stupid thing is handed down on high from the almighty Conferences. If the general computing public isn't going to question anything, at least we have the crazies to question it loudly and viciously enough that J. Random User might sometimes overhear.
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup