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 config file 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 little recovery scripts 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:
Scenario 1: Ask for the user's password before displaying the clear text keyring contents.
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.
Scenario 2: Make keyring session expire automatically after a certain time.
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.
Game Over.
Recommendations:
- Always lock your screen when you leave your computer unattended. This is akin to locking your front door when leaving the house. Hit Ctrl-Alt-L, select “Lock Screen” from the user switch applet, or put the “Lock Screen” applet somewhere in your panel for easy access.
- 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.
Thank you so much for this post! It really sums up what I think.
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.
It's absurd that people are defending this behaviour.
@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.
When I open administrative applications like Synaptic, I'm being asked the password even if the keyring is open.
Why can't Seahorse do the same?
@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.
I think it's a security issue. Not in the remote attack sense, but still.
I have already seen it, and it leaves me, an otherwise *very* knowledgeable user, feel totally powerless.
Other systems don't solve it like this (OS X Keyring). If it's illogical to ask for a password to see all passwords stored, perhaps the whole Architecture of Gnome Keyring is wrong then?
@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...)
Whoops! I meant "Isn't"!
As is this is NOT about me... sorry about that! :-)
Not asking for a password, and showing the password in clear, is a very, very bad idea IMO.
Yes, you can download and run a script to bypass the password prompt, but that is a separate use case.
The simple use case when someone walks up to your computer and can simply look at all you password is there and can be solved simply, why not do it?
False sense of security, I don't think so. A real problem is solved.
Also, showing in plain is bad as well. Should allow you to copy to clipboard, and nothing else.
OS X does that and I think it is a good desing.
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.
"Get in the way"? Alex, how often do you actually access Seahorse to look at your passwords?
And enough with the analogies about houses, already. There's a reason why they all fail in the end. Talk about the technology, don't try to dumb it down.
If you're so vehement about this ("WTF?"), then why, please explain, do you have to put your password before changing it?
Oh wait, because otherwise it would be a huge, glaring, offensive security risk and no one would use this operating system? Yep.
Sticking with the house metaphor, if you had all the windows wide open, or no walls at all, then yes, it would be silly to lock the front door.
But, if you have an open door on the second floor balcony, then locking the front door totally makes sense.
Installing a script to steal passwords is not a trivial task, only a minority can do that. The rest can be stopped with an extra password prompt.
Why would this give you a sense of false security? Some extra wording on that password prompt could help with that?
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.
I'm thinking that part of the problem is that the way that the gnome-keyring was designed was as an all or nothing appliance.
If I connect to a server that uses something like Kerberose authentication to validate the authority I have it is granular to the application, files, even the database forms that I have access to.
From the description you have given of the gnome-keyring, an application that can see the password for a web site that it needs to access can also get every password in the keyring.
That sounds like a design flaw, which may not be a bug, but it is definately undesirable.
@Alex
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.
Is it just me who always forgets the wifi password when guests need it?
Rather than go into the room with the router, open the router cupboard, get down on my hands and knees and read it from the router I just look in the keyring
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?
Sorry if I am hijacking this thread a bit but is there any way to access another users gnome-keyring with su or sudo?
It is discussed here somewhat: https://answers.launchpad.net/gkeyring/+question/90029
I'm curious as to why there's a GUI option to display passwords in plain-text in the first place.
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.
Limited access
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)
Greetings/Hilsen/Groeten
Simon
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.
Also, "Automatically unlock this keyring when I log in" seems to re-check its self every time, undermining my efforts to manage my key security with a separate manually managed keyring.
Post a Comment