Practice Cryptography!
Even with all of the cryptologic and cryptographic technology that has existed in the world for the past 60 years, we still don't really know what encryption is good for or how to use it -- or, more importantly, why it's important. Maybe it's time for people and coders to actually start practicing how to use it, like any other skill.Saturday, February 09, 2008
Message(s) I posted to dev-tech-crypto (mozilla)
I'm just going to point out something that a couple of friends
recently pointed out to me. The business models of commercial CAs
involves what is essentially "selling trust".
On Feb 9, 2008 8:50 AM, Frank Hecker <hecker@mozillafoundation.org> wrote:
> We also have the problem that the cure (removal of root certs) is often
> seen as worse than the disease (problems with particular CAs), in the
> sense that the actual security threat to users is perceived as not
> justifying provoking user annoyance at having a whole set of SSL sites
> suddenly stop working. So instead of going with the "nuclear option" of
> removing root certs, in practice we've fallen back on the alternative of
> nagging CAs to improve their practices (of which the issue at hand is
> yet another example).
See, that's the problem... there's also a conflict of interest inrecently pointed out to me. The business models of commercial CAs
involves what is essentially "selling trust".
If you look at the fact that they have no real accountability, no
procedure in place in any of the browsers to revoke their trust as a
matter of policy if they violate their CSPs, and a need to maintain a
positive cash flow, you will quickly see that there are severe
conflicts of interest inside the individual organizations.
(If you don't believe my assertion that there is no means to remove
root certificate trust as a matter of policy, I am still waiting for
action on Thawte's issuing of SSL123 certificates by a root which had
a CSP which stated that no SSL server certificates would be issued
without at least "medium assurance" of identity. This issue was
brought up before I moved to my Mac as my primary machine, so over a
year and a half ago.)
Frankly, this entire discussion is utterly and disgustingly ludicrous
in light of this.
Add to this the fact that there is no legal recourse available for
"relying parties" if the CA somehow fails to live up to its CSP, and
the entire argument falls completely on its face.
You all seem to be frighteningly disconnected from the realities of
the situation if you're still arguing the minutae of trust models
allowed by CSPs. I lost my faith in the process you're trying to
follow long ago.
On Feb 9, 2008 8:50 AM, Frank Hecker <hecker@mozillafoundation.org> wrote:
> We also have the problem that the cure (removal of root certs) is often
> seen as worse than the disease (problems with particular CAs), in the
> sense that the actual security threat to users is perceived as not
> justifying provoking user annoyance at having a whole set of SSL sites
> suddenly stop working. So instead of going with the "nuclear option" of
> removing root certs, in practice we've fallen back on the alternative of
> nagging CAs to improve their practices (of which the issue at hand is
> yet another example).
Mozilla (and the other browser vendors). They have to maintain market
share, which means ensuring compatibility -- even when the
compatibility flies in the face of one of the reasons why the CA
program exists in the first place (basically, it was started by
Netscape to make it possible for people to have faith in the
identities of the entities they were giving their credit card numbers
to, in order to facilitate electronic commerce).
The end result is that anyone who chooses to spend a hundred thousand
bucks or so on a single audit can then go around selling the benefit
of their inclusion in the trust list to the highest bidder without
fear of repercussion. Which is what they've been doing. And nobody
has the balls to stand up and say "user security is more important
than user convenience". (In addition, roots have been sold to other
companies, which have not passed continuing conformance audits.)
With this kind of a view, it's more of a "you have to have money and
spend money to make money" game than any kind of attempt to adhere to
the principles that actually allow the system to be 'secure'.
Without fear of delisting and decertification, CAs are running
roughshod (not just 'are going to run roughshod', but 'ARE RUNNING
roughshod'), making a farce of the process and the 'trust' in place.
Without a clear view of user security held by a majority of the
Mozilla Foundation board, everything that happens on this list with
respect to CA inclusion requests is as effective as pseudointellectual
masturbation.
Not that my vote counts for anything since I'm not a member of MoFo,
but until these issues are resolved I must vote 'nay' to any
additional inclusion requests under the current guidelines.
-Kyle H
Thursday, February 07, 2008
UAC and what sucks about it
Okay, usually I try not to use this forum to rant about and particular technology that's associated with a specific corporation. However, UAC (user account control) is a technology that gets this treatment, if only because Microsoft came so close to getting it right -- but fell far too short of the mark to be useful.
First, a little overview of what I understand about it:
UAC creates two user tokens for every logon by an administrator. The user's shell (usually explorer.exe) and all processes created directly by it get the standard, unprivileged, normal user account token. (Even if a piece of malware exploits a hole in the software running under this token, only the user's own files are subject to tampering. In order to get access to the administrative token, when UAC is enabled the user is prompted for permission to use it.
Next, UAC also allows for what are called "integrity levels", which are used to roughly classify applications into how much of an attack surface the application wants to expose. Access Control Lists can contain entries that specify the minimum integrity level that a process must have in order to write to the file or registry key, though reading values is always permitted. They are implemented as additional attributes (like group memberships) set in the token that the application is run with -- and the case of "no explicit integrity level" is treated as "medium" (protected operating system files are given "high" integrity level requirements, which are only assigned to the administrator tokens that UAC prompts the user for. Realistically, this means that the only usually-available IL's are "medium" and "low".
Internet Explorer running in Protected Mode runs with an Integrity Level of Low.
On 32-bit systems, there is an additional thing that Microsoft does when UAC is enabled, so that it can support badly-written software that could run on older systems. This is file and registry virtualization. What it does is provide every old program its own view of the registry and the filesystem, such that program can put their own things where the expect them to be, but only for that software running under that user account. It is implemented as a shadow mount with copy-to-shadow on write semantics.
Notably, it is not supported for 64-bit apps or in situations where the UAC user interface is disabled.
And now that I've explained what I know, it's time to state what's wrong with this setup, in my view.
First: virtualization. It should be supported more places, but not for backward-compatibility reasons. As an example of a situation that virtualization could help, we can look at the case of Mozilla Thunderbird and its Eudora-inspired next beta version... When you run the beta, it directly manipulates the settings that are used by the prior version. Since it's beta, it is prone to bugs in every part of it. This means that your working settings can be fubar'ed by the beta, causing a need to restore or recreate the settings that worked pre-beta.
Next, UAC relies on the digital signatures on software to ensure that it has not been tampered with. Since we can no longer rely on our software doing only what we think it should be, why can't we assign every application running under a given token context its own security identifier? This would allow for explicit management of what things can access what -- in such a way that the OS itself can use its well-honed ACL system to perform the access checks.
For this to work, there would need to be a means of allowing applications the means to request access to other applications' data stores, and possibly a "copy other app settings", "virtualize access to other app's settings", or "allow direct access to other app's settings" choice that the user can respond to. This would function a lot like the integrity level concept... In that certain processes that manipulate data stores directly could be given a "allow user-integral access by this app to all data stores" SID. (as an additional note, this cannot only be granted to Windows components, it must be allowable for any piece of software at anythng above Low integrity-level. Since the IL is designed to reduce the attack surface, it should be honored.)
In addition, things running at Low IL should always have virtualization turned on. This would allow Internet Explorer to install ActiveX controls solely for its own use, for example, without requiring that Protected Mode be turned off.
Application datastores should be viewed as OS-level objects -- not as "files" or "keys", but rather as specific settings locations.
Users (yes, even home users) need to be able to positively identify any app running, even if the app itself does not have a digital signature from its developer. This is so that software like City of Heroes can be granted its own configuration space, and so that the OS can grant a security ID to it. This can be accomplished by creating detached signatures, perhaps in separate NTFS file streams.
The base that UAC can provide is mind-bogglingly useful. However, its current implementation is not well-described in ways that users (especially home users) can understand, and is so different from what users are used to that they end up just turning it off. As well, the technology has gotten enough bad rap that the name is not going to inspire trust in those people who have turned it off ever again. It poses a very difficult-to-understand change in how the OS works, and even most developers I talk with just disable it because they have work to do... and they don't even have the 2 weeks to play with it that I have had to get even this much idea of what it does. Thus, Microsoft should retire the name when they revisit it.
Now, let's hope my iPhone doesn't eat this when I post it...
First, a little overview of what I understand about it:
UAC creates two user tokens for every logon by an administrator. The user's shell (usually explorer.exe) and all processes created directly by it get the standard, unprivileged, normal user account token. (Even if a piece of malware exploits a hole in the software running under this token, only the user's own files are subject to tampering. In order to get access to the administrative token, when UAC is enabled the user is prompted for permission to use it.
Next, UAC also allows for what are called "integrity levels", which are used to roughly classify applications into how much of an attack surface the application wants to expose. Access Control Lists can contain entries that specify the minimum integrity level that a process must have in order to write to the file or registry key, though reading values is always permitted. They are implemented as additional attributes (like group memberships) set in the token that the application is run with -- and the case of "no explicit integrity level" is treated as "medium" (protected operating system files are given "high" integrity level requirements, which are only assigned to the administrator tokens that UAC prompts the user for. Realistically, this means that the only usually-available IL's are "medium" and "low".
Internet Explorer running in Protected Mode runs with an Integrity Level of Low.
On 32-bit systems, there is an additional thing that Microsoft does when UAC is enabled, so that it can support badly-written software that could run on older systems. This is file and registry virtualization. What it does is provide every old program its own view of the registry and the filesystem, such that program can put their own things where the expect them to be, but only for that software running under that user account. It is implemented as a shadow mount with copy-to-shadow on write semantics.
Notably, it is not supported for 64-bit apps or in situations where the UAC user interface is disabled.
And now that I've explained what I know, it's time to state what's wrong with this setup, in my view.
First: virtualization. It should be supported more places, but not for backward-compatibility reasons. As an example of a situation that virtualization could help, we can look at the case of Mozilla Thunderbird and its Eudora-inspired next beta version... When you run the beta, it directly manipulates the settings that are used by the prior version. Since it's beta, it is prone to bugs in every part of it. This means that your working settings can be fubar'ed by the beta, causing a need to restore or recreate the settings that worked pre-beta.
Next, UAC relies on the digital signatures on software to ensure that it has not been tampered with. Since we can no longer rely on our software doing only what we think it should be, why can't we assign every application running under a given token context its own security identifier? This would allow for explicit management of what things can access what -- in such a way that the OS itself can use its well-honed ACL system to perform the access checks.
For this to work, there would need to be a means of allowing applications the means to request access to other applications' data stores, and possibly a "copy other app settings", "virtualize access to other app's settings", or "allow direct access to other app's settings" choice that the user can respond to. This would function a lot like the integrity level concept... In that certain processes that manipulate data stores directly could be given a "allow user-integral access by this app to all data stores" SID. (as an additional note, this cannot only be granted to Windows components, it must be allowable for any piece of software at anythng above Low integrity-level. Since the IL is designed to reduce the attack surface, it should be honored.)
In addition, things running at Low IL should always have virtualization turned on. This would allow Internet Explorer to install ActiveX controls solely for its own use, for example, without requiring that Protected Mode be turned off.
Application datastores should be viewed as OS-level objects -- not as "files" or "keys", but rather as specific settings locations.
Users (yes, even home users) need to be able to positively identify any app running, even if the app itself does not have a digital signature from its developer. This is so that software like City of Heroes can be granted its own configuration space, and so that the OS can grant a security ID to it. This can be accomplished by creating detached signatures, perhaps in separate NTFS file streams.
The base that UAC can provide is mind-bogglingly useful. However, its current implementation is not well-described in ways that users (especially home users) can understand, and is so different from what users are used to that they end up just turning it off. As well, the technology has gotten enough bad rap that the name is not going to inspire trust in those people who have turned it off ever again. It poses a very difficult-to-understand change in how the OS works, and even most developers I talk with just disable it because they have work to do... and they don't even have the 2 weeks to play with it that I have had to get even this much idea of what it does. Thus, Microsoft should retire the name when they revisit it.
Now, let's hope my iPhone doesn't eat this when I post it...
Labels: microsoft, security, uac
Archives
2006-02-12 2006-02-19 2006-02-26 2006-03-05 2006-03-12 2006-03-19 2006-03-26 2006-04-02 2006-04-09 2006-04-16 2006-04-23 2006-07-23 2008-01-13 2008-01-20 2008-02-03 2008-02-17 2008-03-16 2008-04-06 2008-05-11
