It is unused by default. Short of modifying the PGP Boot Guard's binary, you cannot disable the feature permanently, which means any user--not just an admin-- can use this feature.
But... PGP has a peer review, open-source process. They're just a commercial product, too. [In other words, it violates the terms of service for you to compile their source code and use it without licensing it.]
The feature is there. It's not turned off in the sense that at every boot, the PGP Boot Guard is checking for the existence of the ("backdoor" or whatever noun you wish to use) account and attempting to decrypt the Volume Master Key with a static passphrase of hex x01.
It would be "disabled by default" if that function call did not exist in every customer's installation, until enabled later.
what's the guarantee that crackers weren't using the vulnerabilities earlier than they were found. I think, the normal user is always vulnerable because the bad guys might, just might have figured the things out earlier and have been using them.
How can anyone know for certain if the vulnerabilities they are finding and patching are truly overlapping that of the vulnerabilities exclusive to the bad guys (yellow circle overlapping red circle), or if they are finding vulnerabilities outside of those known exclusively by bad guys (yellow peanut shape)?
Has anyone bothered to stop and think that maybe, just maybe, we should be focusing on making the totality of vulnerabilities (blue circle) smaller instead of focusing on making the vulnerabilities known by the good guys (yellow circle) eclipse that totality (blue one)?
Absolutely, that would be of concern. Hence my comment:
Likewise, User C, whose opinion is widely regarded by the majority of the community, votes that app X is fine, also increasing the overall trustworthiness metric.
I was trying to handle the situation of the 'trusted advisor'. This could certainly become abused if not properly designed and implemented, but that's the point: to design it to be superior and resilient to these sorts of attacks.
it essentially discourages running stuff you compiled yourself
What? You think you couldn't update the whitelist with your own stuff? Now we're not talking theoretical approach, we're talking about implementation bugs or missed implementation requirements. It is possible to have both a whitelist and your own apps, you know.
Yes, you are. I've been telling Symantec and others (Sophos, McAfee, et al) to do this for years.
It creates a cumbersome and abusable solution to something that was solved better already.
BS. For a consumer, yes [because by definition a consumer doesn't know how a computer works or really what their needs are]. For an enterprise? It's perfect. Enterprises already want to have change management for all their bins. What part of having an AV tool update sigs daily is good change management? Remember what Symantec did to their Asian language Windows customers less than a year ago?
It _is_ possible to isolate something to the point where it can't do any harm at all, and can't touch anything except itself.
You must not work for an enterprise. How many apps out there need to interface other apps? In every org I have worked or consulted: tons. Simply isolating each app, while a good approach where feasible, is not feasible very often. And when it's not, what options are you left with? Blacklisting and the asymptotically rising signature databases? Good riddance.
Now about the consumer problem. I'm thinking a nice white-list, community-driven, reputation-voting algorithm could solve their problems. User A, who agrees with User B about a which subset of all apps should be trusted, has app X (outside the subset) installed, therefore the trust reputation score increases for app X. Likewise, User C, whose opinion is widely regarded by the majority of the community, votes that app X is fine, also increasing the overall trustworthiness metric. There's kinks in there, but work those out and implement it, and I smell a wonderful open source project that will shift everyone's minds about this issue. Just keep in mind most OSes (Windows, Linux, Mac included) are not designed from the ground up to separate code from data, so there will still be some remaining avenues for attack until that is resolved.
First thing that happens is the laptop gets wiped.
Exactly. There are only two motivations for theft of a laptop:
1) The hardware. In which case, the data will likely be destroyed immediately. There is no guarantee the machine will be booted with your hoodwinked "locator" software in tow.
2) The data. In which case, the drive will be imaged or some other "offline" method will suck up the data without booting the OS's controls.
The reason why remote wipe/kill functions work on a small device like a blackberry is because the service provider's network is required for the device to be usable. And even then, there's still the option that the theft is hardware-only motivated, and the thing will get wiped anyway. The blackberry wipe wasn't ever really intended on being used for a physical recovery method.
Potentially, a system BIOS would be a good place to run a "phone home" program, except that it would require advanced components, like a TCP/IP stack, etc., to run properly, and it could still be easily wiped by replacing the firmware with boot media. Apple, for that matter, has an upper hand at such a tool since they "own" both the hardware and software. But either way, what you're attempting to do is no more possible than DRM (and Slashdotters know that DRM is nothing short of an attempt at perpetual motion).
So lesson #1 is protect your data and insure your hardware. And please remember, that "protect your data" really could mean not having a copy of your data on the laptop at all. After all, encrypted data in the hands of an adversary is still your data, just with a time-sensitive lock on it (the length of time needed for CPU power to increase where access is trivial, or the length of time a well-resourced adversary will need to destroy today's top crypto).
You should have just stopped there. It doesn't matter what OS you're a fanboy of, since nearly ALL of them are monolithic kernels on DMA-supported hardware. All it takes is a hardware device that is configured to read portions of memory that it should otherwise not need, and forget passwords-- you're the kernel! As long as we don't separate trust down to the most fundamental building blocks, I don't want to hear another whining "[insert OS here] sucks because I can use a boot CD..." blah blah blah.
Oh yeah, and if we had the above figured out, it might actually be possible to have a system where the credential hashes (salted or not) are protected from random access. In fact, they could be restricted to only the authorized processes. But we have to have those building blocks first (which Windows, Mac OSX, Linux, Solaris, AIX, BSD, etc., etc. on standard DMA-supported hardware does not have).
As a Quad G5 (4x 2500) Mac owner with lots of RAM, I really don't want a browser choking up an entire CPU and flooding my memory.
So... do you have the blockquote twice (above) because half your CPUs processed the copy/paste, or is that because of your wonderfully multi-threaded and multi-programmed browser that it's up there twice?
Emergency response units included two pumpers, a ladder truck, a bamalance...
I tried to think of something funny to say here, but I was stumped... and then I wondered "is this one of those things that seems so nonsensical that it was intended to be called something so irrational?" Then I read the article. Nope, it's just dyslexic fingers at the keyboard-- another day at Slashdot.;)
Say what you want, but some people can probably remember when Samsung made cheap Sony knock-offs as their line of business. Now they're innovating and many consumers (like myself) would chose a Samsung over a Sony.
How long before consumers choose iClone over iPhone?
This is actually a bug in the driver, which is in kernel space, not a bug in the way the ATI card renders images/graphics on screen (directX libraries, etc.). Yes, that part may be better insulated, but kernel driver bugs are kernel takeover bugs.
Of course, the Minix 3 Project has been doing this for awhile, supposedly even having a fully POSIX compliant product at this point.
The major design factor of Microkernels is that it's bad practice to have a trusted path from any driver or system service in kernelspace to any other driver or system service in kernelspace. Just because you're "in" doesn't mean that anything else that's "in" should trust you.
The largest hurdle microkernels have to overcome, however, is the problem of DMA. As long as a malicious ATI video card (nevermind the driver) has direct access to all memory locations via DMA, it could easily just patch the driver's memory at runtime every time via hardware. That's why microkernel development is going to have to go hand-in-hand with tools like IOMMU, for controlling access to critical areas of memory.
Of course, critics often complain about Inter-process Communication (IPC) as being another limitation to microkernels, but at this point, it's really just an implementation hurdle as there are several ways to get processes that are in different memory spaces to communicate with high performance, especially as Moore's Law brings CPUs faster and faster.
I'm not so sure that I'd trust the Customize Google plugin to solve this problem. After all, it redirects http://whatever.google.com/ URLs to https://whatever.google.com/ URLs often after the http connection occurred, which in my mind, is ample time to send the auth cookies in the clear via http, then reload the page and do it a second time in https. I'm sure a very simple sniff would tell this for sure (but I'm trying to post this quicker than you, so sniff for yourself;).
The real solution is to NEVER do https. Or, in Google's case, they could just require https, having the http version of their site not auth users at all until the session has been redirected to https.
Re:Geeks do- everyone else doesn't.
on
The DRM Scorecard
·
· Score: 1
Umm... Maybe you intended this, but do you realize you got Hanlon's Razor backwards?
"Never attribute to malice that which can be adequately explained by stupidity."
Will other Linux flavors find their way to the likes of Lenovo... ?
I for one, would love to see Ubuntu on Lenovo, especially if they provide drivers and hooks for the fingerprint reader. [Note: it's not better security, it's more convenient security.]
Agreed. Not only that, but what about the security concerns of authenticity? How do I know that I am talking to the real true random number generator and not some MITM? We could use HTTPS to get to the true random number generator web page, that way I can have authenticity, but ah, wait... how do I know the private key in the SSL cert was truly randomly generated? And what about the SSL session keys, would they be randomly generated? I don't think I can trust that I am receiving truly random numbers from the truly random number generator. I think psuedo-random is about as good as it gets.
Slashdot Mirror
It is unused by default. Short of modifying the PGP Boot Guard's binary, you cannot disable the feature permanently, which means any user--not just an admin-- can use this feature.
But ... PGP has a peer review, open-source process. They're just a commercial product, too. [In other words, it violates the terms of service for you to compile their source code and use it without licensing it.]
The feature is there. It's not turned off in the sense that at every boot, the PGP Boot Guard is checking for the existence of the ("backdoor" or whatever noun you wish to use) account and attempting to decrypt the Volume Master Key with a static passphrase of hex x01.
It would be "disabled by default" if that function call did not exist in every customer's installation, until enabled later.
I'm pretty certain I saw that on an episode of the 4400. Does Google make Promicin?
How can anyone know for certain if the vulnerabilities they are finding and patching are truly overlapping that of the vulnerabilities exclusive to the bad guys (yellow circle overlapping red circle), or if they are finding vulnerabilities outside of those known exclusively by bad guys (yellow peanut shape)?
Has anyone bothered to stop and think that maybe, just maybe, we should be focusing on making the totality of vulnerabilities (blue circle) smaller instead of focusing on making the vulnerabilities known by the good guys (yellow circle) eclipse that totality (blue one)?
Now about the consumer problem. I'm thinking a nice white-list, community-driven, reputation-voting algorithm could solve their problems. User A, who agrees with User B about a which subset of all apps should be trusted, has app X (outside the subset) installed, therefore the trust reputation score increases for app X. Likewise, User C, whose opinion is widely regarded by the majority of the community, votes that app X is fine, also increasing the overall trustworthiness metric. There's kinks in there, but work those out and implement it, and I smell a wonderful open source project that will shift everyone's minds about this issue. Just keep in mind most OSes (Windows, Linux, Mac included) are not designed from the ground up to separate code from data, so there will still be some remaining avenues for attack until that is resolved.
1) The hardware. In which case, the data will likely be destroyed immediately. There is no guarantee the machine will be booted with your hoodwinked "locator" software in tow.
2) The data. In which case, the drive will be imaged or some other "offline" method will suck up the data without booting the OS's controls.
The reason why remote wipe/kill functions work on a small device like a blackberry is because the service provider's network is required for the device to be usable. And even then, there's still the option that the theft is hardware-only motivated, and the thing will get wiped anyway. The blackberry wipe wasn't ever really intended on being used for a physical recovery method.
Potentially, a system BIOS would be a good place to run a "phone home" program, except that it would require advanced components, like a TCP/IP stack, etc., to run properly, and it could still be easily wiped by replacing the firmware with boot media. Apple, for that matter, has an upper hand at such a tool since they "own" both the hardware and software. But either way, what you're attempting to do is no more possible than DRM (and Slashdotters know that DRM is nothing short of an attempt at perpetual motion).
So lesson #1 is protect your data and insure your hardware. And please remember, that "protect your data" really could mean not having a copy of your data on the laptop at all. After all, encrypted data in the hands of an adversary is still your data, just with a time-sensitive lock on it (the length of time needed for CPU power to increase where access is trivial, or the length of time a well-resourced adversary will need to destroy today's top crypto).
You should have just stopped there. It doesn't matter what OS you're a fanboy of, since nearly ALL of them are monolithic kernels on DMA-supported hardware. All it takes is a hardware device that is configured to read portions of memory that it should otherwise not need, and forget passwords-- you're the kernel! As long as we don't separate trust down to the most fundamental building blocks, I don't want to hear another whining "[insert OS here] sucks because I can use a boot CD
Oh yeah, and if we had the above figured out, it might actually be possible to have a system where the credential hashes (salted or not) are protected from random access. In fact, they could be restricted to only the authorized processes. But we have to have those building blocks first (which Windows, Mac OSX, Linux, Solaris, AIX, BSD, etc., etc. on standard DMA-supported hardware does not have).
Read more here, here, here, and here.
So
Exactly why this has become a major research topic at universities.
You mean, "local" as in how long does it take a trojan to trick a user into installing a local rootkit?
Well there's your problem. "I don't trust no one" means you trust everyone. Must be a simple double negative in the driver's source code then.
Say what you want, but some people can probably remember when Samsung made cheap Sony knock-offs as their line of business. Now they're innovating and many consumers (like myself) would chose a Samsung over a Sony.
How long before consumers choose iClone over iPhone?
This is actually a bug in the driver, which is in kernel space, not a bug in the way the ATI card renders images/graphics on screen (directX libraries, etc.). Yes, that part may be better insulated, but kernel driver bugs are kernel takeover bugs.
Mod Parent Up.
Even Microsoft Research is looking into making microkernel operating systems with their Singularity project.
Of course, the Minix 3 Project has been doing this for awhile, supposedly even having a fully POSIX compliant product at this point.
The major design factor of Microkernels is that it's bad practice to have a trusted path from any driver or system service in kernelspace to any other driver or system service in kernelspace. Just because you're "in" doesn't mean that anything else that's "in" should trust you.
The largest hurdle microkernels have to overcome, however, is the problem of DMA. As long as a malicious ATI video card (nevermind the driver) has direct access to all memory locations via DMA, it could easily just patch the driver's memory at runtime every time via hardware. That's why microkernel development is going to have to go hand-in-hand with tools like IOMMU, for controlling access to critical areas of memory.
Of course, critics often complain about Inter-process Communication (IPC) as being another limitation to microkernels, but at this point, it's really just an implementation hurdle as there are several ways to get processes that are in different memory spaces to communicate with high performance, especially as Moore's Law brings CPUs faster and faster.
Let's hope they support their fingerprint readers for biometric authentication.
I'm not so sure that I'd trust the Customize Google plugin to solve this problem. After all, it redirects http://whatever.google.com/ URLs to https://whatever.google.com/ URLs often after the http connection occurred, which in my mind, is ample time to send the auth cookies in the clear via http, then reload the page and do it a second time in https. I'm sure a very simple sniff would tell this for sure (but I'm trying to post this quicker than you, so sniff for yourself ;).
The real solution is to NEVER do https. Or, in Google's case, they could just require https, having the http version of their site not auth users at all until the session has been redirected to https.
Umm ... Maybe you intended this, but do you realize you got Hanlon's Razor backwards?
"Never attribute to malice that which can be adequately explained by stupidity."
Agreed. Not only that, but what about the security concerns of authenticity? How do I know that I am talking to the real true random number generator and not some MITM? We could use HTTPS to get to the true random number generator web page, that way I can have authenticity, but ah, wait ... how do I know the private key in the SSL cert was truly randomly generated? And what about the SSL session keys, would they be randomly generated? I don't think I can trust that I am receiving truly random numbers from the truly random number generator. I think psuedo-random is about as good as it gets.