After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 764014 - Gnome-keyring stores plaintext passwords in memory
Gnome-keyring stores plaintext passwords in memory
Status: RESOLVED OBSOLETE
Product: gnome-keyring
Classification: Core
Component: general
3.10.x
Other Linux
: Normal major
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-03-22 05:28 UTC by xivoct
Modified: 2021-06-18 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description xivoct 2016-03-22 05:28:54 UTC
gnome-keyring stores copies of login passwords in memory as strings. 

It's possible to retrieve passwords via ptrace() and dump, /proc, /mem methods. 

Reproduce: sudo gcore $(pgrep gnome-keyring)

strings core.$pid

Possible alternative:

1. hash the password, store the hash in memory.
2. user login, challenged for password, hash and compare with stored hash.
3. allow or deny based on match.
Comment 1 Stef Walter 2016-03-22 06:34:36 UTC
Agreed. It would make sense to change this situation. Are you interested in contributing changes? We could work out how to get to one of the alternatives.
Comment 2 xivoct 2016-03-29 04:18:28 UTC
Interested in contributing to a solution here. Unfamiliar with the key parts of the codebase for gnome-keyring which would have to be modified. Any pointers to key functions for gnome-keyring-daemon?

PBKDF2 or bcrypt with per user salts would be possible, both have work factors that can be adjusted to make brute force harder. Both would add dependencies. 

What about crypt() with id = 6? (SHA-512 + salt). This is debian's default password storage for /etc/shadow.
Comment 3 Stef Walter 2016-04-27 08:41:51 UTC
Sorry for the delay responding. In my opinion the goal should be to remain compatible with previously encrypted keyrings, and not introduce a new format at this point.

The key part of the code is in encrypt_buffer() in gnome-keyring/pkcs11/secret-store/gkm-secret-binary.c. Instead of running egg_symkey_generate_simple() during encrypt_buffer() we should run it when decrypting the keyring and keep the resulting symkey in memory until needed for encryption.

In addition in the code in gkm_secret_binary_write() when rewriting a keyring, we should choose to use a hash_iterations of the previously decrypted keyring.

What do you think?
Comment 4 André Klapper 2021-06-18 10:41:13 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/

Thank you for your understanding and your help.