96606 - Pretty Poor Protection (Random Directories for Profiles) (salting)

Status: VERIFIED INVALID

(Core :: Security, enhancement)

Description

[Matthew Kruer]

Background: 

This all started regarding making backups of user profiles, and problems in
restoring the profiles on new systems. The problem lies in the mail client,
loosing all the information because of the little random directory trick that
was implemented. 

Flaw and problems with the current user security:

Reading through everything regarding the randomly generated directory to
increase security, I have found it quite easy to potentially crack.  You don?t
have to have these random billion links as suggested by others to find the
directory. It?s so simple its scary. In the Mozilla application directory, 
Usually ?C:\Windows\Application Data\Mozilla? there is a file called
?registery.dat? In this file is the information required to find which directory
the profile is stored in. you don?t need to decode it, just view it as a simple
text file. Once you have gotten the file all the information for the profiles is
there, including the name(s) for the randomly generated directory. I just opened
it as a text file and voila I got the random directory information and the
entire user IDs. It?s not even encrypted so this entire security option is in my
opinion bogus because it doesn?t have to be cracked. The information is there
clear as day.

Also doing it this way leads to much bigger headaches down the road if a user is
able to back-up and should backup. Currently to restore you have to create a
profile and then copy all the information back into the new directory random
directory, but it does not stop there. You then have to go through the profile
and re-associate all the links for such things as mail, which in all cases I
lost the information in the mail client. This is the preverbal tip of the iceberg.

A much better solution to protecting user information:

This is a two step process. 

The first step is to create a random key when the program is installed. The key
would not be ?stored? but rather generated from the program itself. Information
such as program location, system build, date installed would be used to generate
this key. I would have to be generated from files that do not change all the
frequently, and are not easily accessible by ?hackers? this key is use to
encrypt another file that stores the real keys for user profiles. 

Step two. Each profile will have its own Password that in entered when the
profile is created to a) keep other user from accessing your profile, b) to keep
malicious hackers from gaining access to you sensitive data. This password would
be used to encrypt the information in the user profile and stored in the systems
encrypted file.

Additional Benefits: There are three major advantages to this method

One: Much hard to ?hack?
Two: Increased protection on a user, by user basis (each user has their own
password hence you cannot use one password to crack all profiles)
Three: Eliminates the problems associated with the randomization of the directories.

Concepts 

The idea is to keep the path the same so for proposes of back-up so you dont
have to re-associate folders because they are in different directories. If and
when you do restore or update it will ask for verification that you have
permission to uses the profile again. You then just reenter the password, and
see if it works. If it did it would then store that password for future access
automatically

Opinions

In my final analysis you can either develop a new security scheme for user
profiles that is much more powerful and simpler or spend the same amount of time
trying to figure out how to recover and bebug profiles from a flawed system. 

Hope that makes sense.

Additional Resources
http://bugzilla.mozilla.org/show_bug.cgi?id=56002
http://bugzilla.mozilla.org/show_bug.cgi?id=95331

Comment 1

[Ferdinand]

If someone can read the registry.dat, there's a more serious security breach
than possible access to a mozilla profile. The point of this random directory
was stopping webpages from writing malicious data to (eg) cookies.txt (to which
all webpages can write), and knowing where the cookies.txt is by guessing at the
same time, thereby making it possible to execute whatever was written to
cookies.txt.
That file would have been assumed to be at ~/.mozilla/default/cookies.txt in
linux. There's no read access (which as far as i know can not be gained through
mozilla), just a possible way to execute data that's been written. All this is
blocked by the randomized location of all files that can be written to.

You suggest creating a key from the program itself, but the way that key is
created will be available to anyone, and consequently so will the key, only
randomizing the key will give some security.

You suggest forcing the user to create a password for the profile data, which is
inconvenient, and will disable the (sometimes still required) manual editing of
the profile. Added to that, mozilla must not assume presence of NSS/PSM which is
required for encryption.

That's my view of this issue anyway.

Comment 2

[Grace Bush]

Matt,

For a much longer discussion of security/password issue see bug 16489

Comment 3

[Markus Gerstel]

I'm on your team, i hate the salted directories, too =)

I filed Bug 96601 for it, but your description is better than mine - I'll copy
and dupe :


This is the second part of the neverending story :
"If M$ IE is good at patronizing users, Mozilla MUST be better !"

(A short summary : Mozilla-created profiles will not reside in /mozilla/profile
but instead in /mozilla/profile/08sdfj3rf.slt - Bug 56002
This so-called "feature" is so important for some developers that they can't
live without it.
Since this "intentional security feature" (which increases security to a maximum
- be assured !) certainly does not cause any problems (besides Bug 95331 or Bug
93112 or maybe Bug 63851) and since this feature is so important nobody on earth
can live without it, it MUST be mandatory - Bug 70931)

I was sorry to hear some rebellious enitites are out there who dislike this
marvellous feature and requested removal, calling it "unneccessary",
"ridiculous", "user unfriendly", etc.

Hm. Would not be that surprising if this bug somehow disappears in a few minutes
or gets "verified wontfix" or "verified invalid" or even "verified idiot".

Comment 4

[Markus Gerstel]

*** Bug 96601 has been marked as a duplicate of this bug. ***

Comment 5

[Conrad Carlen (not reading bugmail)]

    The problem here is not the salted name, it's the fact that we store file
locations in the prefs as absolute paths. If they were stored as relative paths,
it would not matter at all whether the random string was present. 

    For example, if the path to your mail account is "C:\WINNT\Profiles\<user
name>\Application
Data\Mozilla\Profiles\some_profile\adaj44rw.slt\ImapMail\some_account, it is
written to prefs.js exactly as such. With the proposed relative file name
scheme, it would be instead written as %ProfD%\ImapMail\some_account where
%ProfD% is expanded at runtime by XPCOM to the location of the current profile.
This location can be found by XPCOM's directory service whether it has a salted
name or not. It just doesn't matter. Doing this will allow profiles to be moved,
backed up, and made portable across different OSs.
    I would stop beating the salted directory dead horse because it's really not
the probem here and instead push for XP, relative file descriptors. It's bug 12911.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Wow, Matthew can alliterate, how creative.

You raise a valid issue as to the difficulty of restoring profiles from a
backup. Apparently there is already a bug (12911) which would make that
possible. However, because a feature has flaws does not mean the feature should
be removed - it means the flaws should be fixed. Let's separate the brofile
backup problem from the fact that you find the salt directory annoying - those
are separate issues and both already have bugs filed on them. 

> I have found it quite easy to potentially crack.

The attack you describe is not plausible. If a remote attacker can read
registry.dat to find the location of your profile, then we've already lost.
Ferdinand described this pretty well above. We're not trying to prevent someone
sitting at your computer from finding your profile directory, we're trying to
prevent a remote attacker from planting malicious content in your profile and
then running it. There have been a large number of such attacks discovered (in
the lab, that is, never exploited in the wild, but that's not to say they
couldn't be). The salt directory blocks this entire class of attacks. If you
actually have a way for a remote attacker or malicious wepbage to find the
location of a user profile directory, I would be grateful if you could share it
with us. What you described above does not seem to be so.

> A much better solution to protecting user information

Encrypting the entire profile directory is overkill in terms of security, and as
Ferdinand says, it would make hand-editing of profile info difficult, and lots
of people counf on that. I think the salting offers sufficient protection. There
was a lengthy discussion of password-protected profiles on n.p.m.security, and
the consensus was that they would be both burdensome and provide a false sense
of security. Besides, encrypting the profile wouldn't prevent the attack
Ferdinand describes above, since the browser would still be writing information
to the profile directory and would still have to decrypt it for use.

In response to Markus:

> This so-called "feature" is so important for some developers that they can't
> live without it.
Do you want to be sarcastic, or do you want to help us reach a good balance
between security and ease of use? This feature prevents several attacks we know
of and probably lots we don't. They've been listed elsewhere, I won't repeat
them here. I realize that salting has caused some problems, but those problems
can be fixed without removing the feature. 

> Since this "intentional security feature" (which increases security to a maximum
> - be assured !) 
I believe it does in fact increase security. You have offered no evidence that
it does not. Prove to me that salting is ineffrective and that its flaws cannot
be fixed, or come up with a better alternative that addresses the security
concerns, and I will remove the salting in a heartbeat.

> certainly does not cause any problems (besides Bug 95331 or Bug
> 93112 or maybe Bug 63851) and since this feature is so important nobody on earth
> can live without it, it MUST be mandatory - Bug 70931)
Bugs 9533 and 63851 need to be fixed, but they can be fixed without removing
salting. 93112 should have been marked invalid since it didn't actually cause
any problems. I have reopened 70931 as I think it's a valid concern. It need not
be mandatory when it's superfluous - see my comments in that bug.

> I was sorry to hear some rebellious enitites are out there who dislike this
> marvellous feature and requested removal, calling it "unneccessary",
> "ridiculous", "user unfriendly", etc.
It is neither unnecessary nore ridiculous. I believe this has been proven to
anyone who bothered to read the relevant bugs instead of shooting their mouth
off with no evidence. It is a bit user-unfriendly, so let's work on that - with
your help, hopefully.

I have filed bug 97180 to discuss modifications to salting to make it more
user-friendly. If you are interested in real solutions rather than hot air, I
invite you to post there, but arguments for removing the feature will not be
taken seriously unless you can prove it has no benefit, or that the problems it
causes are unsolvable.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Resolving invalid. Or if you prefer "resolved nonproductive rant"

Comment 8

[Markus Gerstel]

Reply to Mitchell :

>> This so-called "feature" is so important for some developers that they can't
>> live without it.
>Do you want to be sarcastic, or do you want to help us reach a good balance
>between security and ease of use?

This was sarcastic since it was intended to provoke a reaction. (I was referring
to the Bug you reopened - _Thanks_ for it =)

>> Since this "intentional security feature" (which increases security to a
>> maximum - be assured !) 
>I believe it does in fact increase security. You have offered no evidence that
>it does not.

Salting is effective against the type of attack you describes (storing data in
cookie and executing) - I guess that's why cache files don't have guessable
names either. But think of a bug which allows you the creation of a 0-byte file
named C:\Explorer.exe - in this case salting wouldn't help anyone.
In a case where javascript/java/anything allows access to the filesystem you
have lost (as you said before) - My fault was that I didn't think about storing
data into the profile with legal commands (such as cookies) and executing as
local content. In this case salting the directory would be ok. On the other hand
this would only be necessary for the 'default'-Profile.

> It is a bit user-unfriendly, so let's work on that - with your help,
> hopefully.
> If you are interested in real solutions rather than hot air, I
> invite you to post there, but arguments for removing the feature will not be
> taken seriously unless you can prove it has no benefit, or that the problems
> it causes are unsolvable.
I would be glad to see salting as an optional, but by default enabled, feature.
That was exactly what Bug 70931 is about, and I was upset when I read "This is
intentional - we will not do anything about it".

If you are offended by my postings (so it seems) I'm apologizing for it.
Everything I can do about this bug is talking. I know several programming
languages like M$VB, Pascal, Perl, PHP, TCL, JS, but I'm not a C/C++ Programmer
- maybe some day, but not this time =)

Guess I should now verify this bug as invalid...

Comment 9

[FZiegler]

I don't (yet) grok why this was marked invalid.

A path (1) is salted to make it unpredictable, and then immediately stored
(base64-encoded, on Mac) in an entirely predictable location (2):

(1) ~/Library/Mozilla/Profiles/default/xxxxxxxx.slt
(2) ~/Library/Mozilla/Application\ Registry

So I guess Mitchell is claiming that (unlike contents of (1)) there cannot be a
way to remotely read (2). Is this true?

Comment 10

[S Woodside]

yes.