Wednesday, November 4, 2009

GNOME Keyring

For the past week or so, people have been talking about a “security issue” in Seahorse. This sums up my opinion on the matter:

This isn't a security issue, and there is no good way to fix it.

There, I've said it. Now, here's some background:

Although people are talking about Seahorse, the actual application that manages passwords is called GNOME Keyring. GNOME Keyring is an application that manages a user's authentication information, such as user names and passwords. It stores the authentication information in one or more encrypted databases, called keyrings. A password, supplied by the user, is required to unlock a keyring, at which point all the information contained within is decrypted and is made available to applications via the libgnome-keyring library. It is similar to the Keychain in Mac OS X, and Protected Storage in Microsoft Windows.

Traditionally, a desktop application that needed to remember a user's password, such as an email or an instant messaging program, would store the password in a hidden configfile in the user's home directory. Appropriate permissions would be set on the file to make sure other local users can't read it.

Sometimes, passwords stored in this manner would be obfuscated using a reversible scheme, as the password needs to be converted back to plain text in order to be used. This would provide a false sense of security. Users inspecting the file would think the passwords were encrypted, but a myriad of littlerecoveryscripts and on-line converters were available to anyone who knows how to perform a Google search.

A password managing daemon, such as GNOME Keyring, increases the security of stored passwords for the following reasons:

Passwords are stored in a database that uses real encryption, not just an obfuscation scheme

A single code base needs to be audited to make sure no vulnerabilities exist in the encryption algorithms that are being used

The database is protected by a password that is known only to the user who unlocks it

Since the database is encrypted, no other user or bootable CD can recover the stored passwords if the unlock password is not known

So, if GNOME Keyring increases the security of user credentials, why can you see your passwords exposed in plain text when you open Seahorse? Because you've unlocked the keyring using your login password.

Although GNOME Keyring supports multiple keyrings, there is only one by default, called “login”. This keyring is automatically unlocked by a PAM module when logging into a GNOME desktop. When the desktop session is closed, the keyring is locked. When the keyring is in an “unlocked” state, the database files are decrypted using the decryption password and all the contents are in memory for gnome-keyring-daemon to access.

Now, the attack scenario that has been talked about this past week has been leaving your computer unattended, and an attacker using Seahorse to access your clear text passwords. This has been criticized as being a security issue, and a few “solutions” have been suggested to “fix” the issue. Here are some of the scenarios proposed:

This scenario doesn't work in practice. Once the keyring is unlocked, the contents are available under the user's security context. Since the GNOME Keyring daemon is under the user's security context, the intruder has every privilege necessary to simply bypass the authentication step and directly read the unencrypted keyring from memory. Even if Seahorse asked for a user password, nothing could prevent the intruder from simply downloading a “reveal passwords” application from the Internet or a USB key. There is no difference in time or skill required to open Seahorse and display passwords, or to type “gnome password revealer” in Google and execute the first application available for download. The GNOME Keyring project has a web page to explain this.

Even worse, the fact that a password would be required in Seahorse would make the user think that a password is required to see the clear text information. This would give the user a false sense of security. If Seahorse asks for a password, but a five line python script can bypass the password, bug reports would change from “Seahorse displays clear text passwords” to “Seahorse authentication can be easily bypassed”. This scenario doesn't solve the problem.

If the keyring session expires automatically, such as every 15 minutes, it becomes useless. The purpose of the keyring is to store passwords that are needed by applications. With keyring session expiration, Evolution can't automatically check for new mail, Empathy can't auto-reconnect to instant messaging networks, the wireless connection can't re-authenticate to access points.

If you expire the keyring session every 15 minutes, you will probably need to type in your password every 15 minutes. Besides, if you leave your computer unattended, 15 minutes is long enough for an intruder to steal your passwords. This scenario doesn't solve the problem.

Scenario 3: Make the keyring daemon run as root or as a dedicated user.

The idea behind this is to have a central daemon that would authenticate users and applications before giving out passwords. Since the daemon doesn't run under the user's security context, no amount of hacking by an intruder in an unlocked desktop session would result in gaining access to the unlocked password database.

Although this scenario may seem appealing, it would probably be less secure than the current approach. If we have a central daemon that serves all users, a programming vulnerability could result in other users gaining access to your confidential information. Besides, if your desktop applications, under your security context, can gain access to the passwords they need, so can an intruder in your security context. The intruder's script can simply spoof the desktop applications themselves to get the passwords, or get them out of the application's memory. This scenario doesn't solve the problem.

Scenario 4: Stop using GNOME Keyring.

Well, GNOME Keyring was created to solve the problem of people writing down their passwords everywhere, including text files or their computer, and the problem of applications storing passwords in text files. Removing GNOME Keyring would decrease security to the state it was before. This scenario doesn't solve the problem.

Scenario 5: Locking the desktop session when stepping away from the keyboard.

Now we're getting somewhere!

Since the attack vector that's being discussed is an intruder gaining physical access to an unlocked desktop, the simplest way to prevent this from happening is to lock the desktop when you leave it unattended.

If someone gains access to your desktop, your passwords are not the only thing they can access. Who needs your email password, when they have access to your whole mail file?

Even if we assume GNOME Keyring could be made attacker proof, we would need to do the same for every desktop application. An intruder could, in a few seconds, install a Trojan horse downloaded off the Internet that runs in the background and emails him your passwords as soon as your desktop applications use them. The same application could intercept your sudo password, and become root to access the GNOME Keyring data. Absolutely no technical skill is required to do this.

Leaving your desktop unattended exposes all your confidential data to an attacker, not just your passwords.

Set a low screen-saver idle timeout, for example, 5 minutes. If you forget to lock your session, it will do so automatically after a couple of minutes, reducing the time your confidential data is exposed.

And remember: This isn't a security issue, and there is no good way to fix it.

30 comments:

I was wondering if the locking of the session also locks the keyring (and unlocks it again if the screen is unlocked) or if the protection "merely" is that an adversary can't do anything on the system since the screen is locked.

One possible issue could be that if I'm logged in on one of the consoles as well (CTRL-ALT-F1 and such) the adversary still has access to the users security context.

A very good explanation of the issue. Anyway, doesn't gnome-keyring allow for more than one keyring? Wouldn't it be possible then for a user to dettach those sensible passwords/encryption keys from the default "login" keyring and attach to a different keyring? Or indeed make the default keyring not the login but another different one?

You forgot "Scenario 6 : Stick your head in sand", which is what you're suggesting here.

Unlike the developers thank goodness, who, on the mailling lists are at least talking to the people who believe that this is, indeed, a security concern.

This isn't about an "attacker". It's about a perhaps otherwise trustworthy colleague perhaps out to do some mischief. Remove the temptations - why does Seahorse even LET you see the passwords? As long as you have the option of re-typing/changing them, then fine.

By your logic, there should be absolutely NO reason to authenticate your identity to the change password box in "About me".

All we're asking for is the same technique here before revealing passwords.

@VictorJ: I don't think locking the session locks the keyring, as applications would not be able to download mail and stay connected while your session is locked. Putting your computer to Suspend mode does, though.

If you leave a virtual console logged in, yes, your data is at risk.

@apanoia: Users who don't want the keyring unlocked by default simply need to change the keyring's password to a different one than their login password. It is also possible to add a second keyring, as you describe and set it as default.

@nilux: because when you open Synaptic, you are accessing stuff that's in a different security context than your own. The password is asked to switch from your own security context, to the security context of the root user, which has the rights to access the system packages/updates.

Seahorse _could_ ask for your password, but that would just be a placebo that is easily bypassed with a small script as all the information contained in the keyring is in your own security context.

@mdeslaur : Seahorse already has a placebo - it asks you if you want to "deny", "grant once" or "grant always", but because the keyring is already unlocked, there's no password prompt on any of these "grant" options.

As for scripts - ignore that, please. There's over 350 posts on the security thread discussing this issue and it's been mentioned many times that a script attack isn't relevant to the use case here.

So, no, a password will not be a placebo effect. It will simply solve this particular problem. And given how often I suspect that people use Seahorse to view their passwords, I'm guessing that absolutely no-one will notice.

Then we can start haranguing Network Manager for having the exact same problem...

@Scaine: well, if scripts aren't an issue for you, and having your data compromised isn't an issue for you, then why don't you just uninstall Seahorse? That will take care of your extremely limited attack vector.

Yep, un-installing has been discussed on the thread and until this is fixed, I've already un-installed it on my work PC.

But this is about "me". It's about this being on the default install of every Ubuntu build. Someone even suggested removing it from default, but I believe that would really hurt Seahorse's install base, so would prefer to talk to the developers (as I'm doing) and see if I can't convince them a change is necessary.

Good blog, by the way. It's a shame you don't post more. Did you ever find a suitable iPod replacement?? (considering a Sony X-Series right now...)

I really agree with marius, a little of password encryption won't hurt anyone. The process of recovering a weak encrypted password may take 1 minute, but remebering a plaintext password is a 1 second thing.

WTF? Do you people want a false sense of security? What you are asking for is akin to saying 'When I leave my house and don't lock the front door, why can thieves easily come in and steal my stuff?' - this is exactly the same. Simply lock your session (ie. lock your front door) and this will stop anyone accessing your passwords. Otherwise you are asking to have to re-authenticate yourself when your are already authenticated and your front door is unlocked. This will end up as 'Why when I have already unlocked my front door and am inside my house, do I have to re-unlock my front door just to grab my wallet which is already inside my house?' - it just doesn't make any sense. Seahorse and gnome-keyring do the right thing and don't give you a false sense of security, and don't get in your way - they achieve a really good balance between security and usability, which as a computer security researcher I can tell you is always a tough balancing act.

@Mauricio - gnome-keyring already employs encryption of all your passwords, so you've already got what you want - keeping them encrypted during your session will only result in dialogs popping up everytime evolution or network-manager or pidgin needs to access a password, which is a usability nightmare - not to mention a security nightmare since it will train you to always allow apps access to your passwords, rather than just the few which actually need it.

The fix is easy! Just open Seahorse, right click your login keychain, and chooose "Change password". Change it to something other than your user account password. Your keychain will then remain locked when you login, until an app asks to unlock it, at which point you will have to enter a password. This should serve as a reminder that you have an unlocked keychain. You can then right-click your keychain again and select "Lock" to relock your keychain. Kludgy, but a bit more secure at least.

If you read carefully my post, I said "weak encryption". It means that gnome-keyring might use a weaker encryption algorithm than the one used for the real database in order to ease the process. Anyway I think that "non technical people", aka users, won't care too much how you store the information in the disk as long they are told it is secure. So the "false sense of security" is always there.

Anyway I think that instead of writing passwords in plaintext files it would be better to obfuscate them a little. As a computer security researcher you should know that most of the users won't even look the plaintext file, so there would not be any "sense of insecurity".

People forget to lock their sessions for the same reason that you they forget to use the seat belt: they think that nothing bad is going to happen to them. Maybe that's why airbags where invented, as an additional security device that prevent your brain to be all over the windshield in case you forget to use the seat belt in your car.

Changing the keyring password is not only inconvenient, it changes nothing. You'll still, after logging in and spuriously typed a second password, have unlocked the keyring and so Seahorse will show it if you ask it to.

The answer here is to have Seahorse not show the passwords at all (only offer to change them), as is the case in Windows, or better still, password-protect the act of viewing them. (not password protecting Seahorse itself though - just the act of unlocking).

Best of both worlds.

I'm still pretty stunned that people defend this and say "oh, just lock your computer when you're away".

No-one, yet, has managed to explain why we need to type our passwords into a sudo operation for it to work. After all, you always lock your laptop don't you? You /know/ that you're the only one using your computer, right? What *possible* use is it to type that password? Why don't you just press "okay", like UAC in Windows?

Because that's what the "lock your computer" brigade's argument boils down to. If only YOU can use YOUR computer, then after logging in why should your computer EVER ask you who you are again?

I think Seahorse should not even give the option of displaying your password. When you initially set up an application like email, it asks for your password, stores it in the keyring, done. Opening Seahorse will show you that you do have a stored email password and that should be enough. Why do you need to see it?

If you change your email password on the email server, then obviously your email retrieval will fail with the currently stored password. So just have the email application prompt for a new password, delete the old one stored in Seahorse and store the new one.

I think the an important step would be that ONLY the application that stored the password is able to read it (without the system asking you to confirm that action with re-entering your keyring password). This way seahorse could NEVER show you the password without you getting prompted for the keyring password (because it did not store the password itself)

And for those having problems with paranoia

This should be a big step forward, but then you still have the (small) risk of the "attacker" spoofing the application, which can be solved by integrating a hash/signature control system (which would be more advanced since you don't want all your app's to be untrusted after a system update)

Necessary??

another thing is that seahorse is unnecessary in my opinion, because why would there be a program that has access to ALL the user's passwords,it should be more than enough that the individual app's that use the password can access there own passwords (an decide themselves if they want to make it possible for the user to see them in plain text, which would be handy for programs using "shared" passwords like wifi key's)

The "house" metaphor

to reduce the whole thing to the house metaphor:In my house my parents (the user) unlock the door, me and my sister (the programs) come in, i can access my wallet (the password) i got from my parents, my sister can access hers, but she can't (without explicit permission of my parents) access mine

by the way: i used seahorse for the first time in my live (and i'm using ubuntu since 6.4) while reading this post, to change the keyring password (to nothing because i needed the keyring to unlock automatically on auto-login), and i didn't even know about it's existence before. (i think ubuntu has to take a good look at his default installation)

Little dig out of this thread. I used surber.us method to change the default keyring password (right click). And I was happy to notice there is then a timeout option you can set.This is in v 2.30.0 (ubuntu 10.04) hopefully it's still like that in the newest release.

I just had the scary experience of "gpg -d" decrypting an important file without any prompt, TWO DAYS and at least one sleep/resume cycle after I entered my key passphrase.

While I see the general argument you're getting at, there's a big difference between browser & email passwords, etc, and passphrases to cryptographic keys.

A way to have cached keys time out and have them cleared when suspending would be a BIG reassurance. I really don't want GNOME caching my keys indefinitely.

Seahorse doesn't seem to offer a way to remove a cached key password, either. It lists the keys, but doesn't list the passwords separately. Right clicking on the key offers to delete the key (permananently, from my keyring) but not to forget the password to it.

A way to tell gnome-keyring-daemon "don't cache my GPG keys" or "cache them on a separate keyring with an expiry timer that isn't auto-decrypted at login" would be rather reassuring. Better yet, a way to move cached credentials between keyrings.