Welcome, Guest. Please login or register.

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

Description:

0 Members and 1 Guest are viewing this topic.

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show only replies by commodorejohn
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #14 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 LoadWB

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show only replies by LoadWB
Re: UEFI Palladium reborn Nightmare.
« Reply #15 on: September 28, 2011, 12:12:59 AM »
Quote from: commodorejohn;661606
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...


History shows that, at this point, there has been no major push by manufacturers to eliminate "alternate" operating systems.  And given AMD's recent push into open source drivers for Linux, I doubt there ever will be.

Quote
Could you please explain to me what real benefits this would offer?


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.  And in the event an unauthorized change occurs, stopping the boot process cold to prevent further compromise.

Two of the infection vectors used by Stuxnet would have been stopped by an operational trusted-platform system, as could the TDSS root-kit.

Quote
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.


:rolleyes: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.
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show only replies by commodorejohn
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #16 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 LoadWB

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show only replies by LoadWB
Re: UEFI Palladium reborn Nightmare.
« Reply #17 on: September 28, 2011, 02:58:14 AM »
Quote from: commodorejohn;661613
Again, though, this is entirely possible to accomplish without mechanisms that could be co-opted to enforce software lock-in.


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.  The TPM can work directly with the CPU to look at code to be executed and halt the CPU if the code doesn't pass muster, with no software interaction what-so-ever.  This virtually eliminates the capability of the hardware to lie to the operating system, as the TPM store is hardened against being manipulated without the proper key.

I'm beginning to build TC-based systems and I expect to use a private key which I generate for each customer.

Quote
And how many of them couldn't have been stopped with a less problematic method of boot security?


This does not rebuke in any way the efficacy of the platform.  Although, in a well-locked down system it is possible that it simply would never have worked.  I don't have enough information on it to speak at that level of certainty.  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.

Quote
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.


I would say it's a matter of both.  If the signature in the BIOS, option ROMs, boot block, etc. does not match what the TPM knows they should be, then it all stops.  And in this scenario you could still use external boot devices under the purview of the platform, so long as the external source has been identified to the TPM.

Simply preventing booting from external devices is not sufficient.

Quote
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.)


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.

I asked the engineers present at the conference from AMD and Intel about the BIOS jumpers.  It's a good idea, I think, but still not the magic bullet.

To summarize: password-protecting the BIOS, setting the BIOS jumper to "write protect," and disabling external boot devices is not enough anymore.
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show only replies by commodorejohn
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #18 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 LoadWB

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show only replies by LoadWB
Re: UEFI Palladium reborn Nightmare.
« Reply #19 on: September 28, 2011, 04:07:17 AM »
Quote from: commodorejohn;661622
...

The long and short of it is, no operating system nor hardware can meet perfect security, because perfect security is impossible.
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show only replies by commodorejohn
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #20 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 LoadWB

  • Hero Member
  • *****
  • Join Date: Jul 2006
  • Posts: 2901
  • Country: 00
    • Show only replies by LoadWB
Re: UEFI Palladium reborn Nightmare.
« Reply #21 on: September 28, 2011, 04:57:58 AM »
Quote from: commodorejohn;661625
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.


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.

This is, as you say, fundamentally insecure, but it is not flawed -- again, it is necessary.

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.

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.  Hell, I watched a demonstration in which a VM was able to steal information from another VM by compromising their shared hyper-visor.  There are plenty of white papers out there, information from N.I.S.T., I.E.E.E., and so on which speak very openly on this.  I just spent a week listening to and watching how exactly what you propose is simply not viable from experts who actually build the components, not simple academics with theories.  I spent my own hard-earned money on my learning experience and as much as it may sound like a dodge, I challenge you to do some real research on the matter.  (I'll have access to the presentations once I complete my 29 page survey :madashell: and will make some of them available, if you're interested.)

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.  (DRM is real, but it's not everywhere like the bogeyman.)  Palladium never came to be the disaster the prophets said it would be.  No motherboard manufacturer which wants to keep a presence in a free market will bow to only including Microsoft keys in their TPMs -- aside from the TPG expressly forbiding such a practice.  That doesn't stop OEMs from doing it, but the TPG is working closely with the industry to ensure that things remain open.

I refuse to subscribe to the tin-foil hat brigade on this one.
« Last Edit: September 28, 2011, 05:29:12 AM by LoadWB »
 

Offline orange

  • Hero Member
  • *****
  • Join Date: Dec 2003
  • Posts: 2794
    • Show only replies by orange
Re: UEFI Palladium reborn Nightmare.
« Reply #22 on: September 28, 2011, 05:48:54 AM »
if the hardware doesn't 'trust' me as owner, then I don't trust it either.
Better sorry than worry.
 

Offline slaapliedje

  • Lifetime Member
  • Hero Member
  • *****
  • Join Date: Oct 2010
  • Posts: 843
  • Country: 00
  • Thanked: 1 times
    • Show only replies by slaapliedje
Re: UEFI Palladium reborn Nightmare.
« Reply #23 on: September 28, 2011, 05:54:16 AM »
You know what this whole thing reeks of more than anything?  Microsoft admitting their inability to create an operating system that doesn't absolutely stink in the security area.

"Oh crap, we really can't get our OS secured.  I know, let's force it through hardware!"

I've been trying to make it a point at where I work (I'm the Linux system administrator) that minimalistic server installs is the ONLY way to go.  One of the managers there is a Mac fan, and since the Apple XServe has been cancelled, was forced to get an HP machine and so I installed Debian on it, with nothing, put a few things that he needed like Tomcat, etc.  He claimed things weren't installed (after I told him I'd install anything he needed) so he just wiped them and put full fledged Ubuntu on there.  Eh?  Idiot doesn't realize that with more services on by default, it makes your system that much less secure.

It's the exact same reason why Windows has been and forever will be insecure.  We all know the vulnerabilities in RPC.  It's a shame that Ubuntu goes down the same route, but it does it for ease of use on the desktop (which is why it's retarded to use it for servers.)  But I digress...

slaapliedje
A4000D: Mediator 4000Di; Voodoo 3, ZorRAM 128MB, 10/100mb Ethernet, Spider 2. Cyberstorm PPC 060/50 604e/420.
 

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show only replies by commodorejohn
    • http://www.commodorejohn.com
Re: UEFI Palladium reborn Nightmare.
« Reply #24 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
 

Offline orange

  • Hero Member
  • *****
  • Join Date: Dec 2003
  • Posts: 2794
    • Show only replies by orange
Re: UEFI Palladium reborn Nightmare.
« Reply #25 on: September 28, 2011, 06:54:37 AM »
To me, DRM and TPM is the same cr@p that treats us all as criminals. If I really need uber security, I'll go back to ZX Spectrum or something.

Obviously, its all about control. Problem is, bad guys who write viruses will probably (eventually) find a way to crack TPM, it will get worse than today.

The only good solution to security is educating users, and making simple software/hardware. In this race to speed and functionality, systems have become bloated, needlessly complex  thus vulnerable.  

Once the average user understands how his OS works and stuff like that, security will be much better.
Better sorry than worry.
 

Offline runequester

  • It\'s Amiga time!
  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 3695
    • Show only replies by runequester
Re: UEFI Palladium reborn Nightmare.
« Reply #26 on: September 28, 2011, 07:16:49 AM »
What would people's reaction be, if Windows happened to be published by a chinese company?
 

Offline orange

  • Hero Member
  • *****
  • Join Date: Dec 2003
  • Posts: 2794
    • Show only replies by orange
Re: UEFI Palladium reborn Nightmare.
« Reply #27 on: September 28, 2011, 07:23:13 AM »
@LoadWB

would you be willing to spend rest of life in sanatorium-like facility, wearing that 'protective shirt' if someone promised you'd never ever get shot, robbed, etc..?
Better sorry than worry.
 

Offline koaftder

  • Hero Member
  • *****
  • Join Date: Apr 2004
  • Posts: 2116
    • Show only replies by koaftder
    • http://koft.net
Re: UEFI Palladium reborn Nightmare.
« Reply #28 on: September 28, 2011, 08:48:32 AM »
People are blowing this issue completely out of proportion. Microsoft isn't requiring OEMs to ship with secure boot firmware that only allows booting a Microsoft OS nor are they providing an incentive to do so. An OEM could do that, but there is no financial incentive to do so. The consumer will be able to turn off secure boot if they choose to and configure TPM however they please to meet whatever requirements they may have.

Requireing OEMs who want to participate in the logo program to enable secure boot != uber draconian end of the world we're all gonna die scenarios. Windows will still install on machines that don't have it.
« Last Edit: September 28, 2011, 08:50:52 AM by koaftder »
 

Offline Duce

  • Off to greener pastures
  • Hero Member
  • *****
  • Join Date: Jul 2009
  • Posts: 1699
    • Show only replies by Duce
    • http://amigabbs.blogspot.com/
Re: UEFI Palladium reborn Nightmare.
« Reply #29 from previous page: September 28, 2011, 09:36:09 AM »
As Koaftder said, no one is forcing OEM's to put this stuff on boards.

UEFI isn't anything new, and MS has had enough trouble with the DOJ/Euro trade comm. to be this damned stupid, lol.

Most of the people chiming in shouting "BIG BROTHER" have no idea what it does or how it works.  I recommend reading some unbiased information, assuming you can find any in this recent wave of "omg M$ is taking over and locking out Linux" headlines.  The article on osnews.com was pure garbage, as are most of them these days.  Uninformed morons not seeing both sides of the coin - pro and con.