[Desktop-packages] [Bug 1780365] Re: Credentials located in gnome-keyring can be compromised easily
** Changed in: gnome-keyring (Ubuntu) Status: New => Confirmed ** Changed in: gnome-keyring (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1780365 Title: Credentials located in gnome-keyring can be compromised easily Status in gnome-keyring package in Ubuntu: Confirmed Bug description: Dear all, I figure out that login credentials, located in gnome-keyring, can be easily compromised. Linux based on Gnome basically uses ‘gnome-keyring’ as their backend to store login credentials in a secure manner. Specifically, google- chrome browser, network-manager and gnome-online-accounts use this as a backend solution to store login credentials. To use this, authentication is performed together with gnome-keyring as part of ‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut down or logged out. In this state, a simple program that uses ‘Secret Service API’ call and their ‘D-Bus’ interface can easily retrieve login credentials from those gnome-keyring without any privilege escalation, listening into the X events going to another window, or installation an application on target computer. (please check PoC source https://github.com/sungjungk/keyring_crack and video https://youtu.be/Do4E9ZQaPck) The issue is different from the content shown on the Ubuntu Security FAQ and GnomeKeyring Wiki [1][2]. It was even said that “PAM session is closed via the screensaver, all keyrings are locked, and the ‘login’ keyring is unlocked upon successful authentication to the screensaver”. After trying to crack the keyring, it was far from what they really thought. It is no different than plain text file for login credentials somewhere on disk. To deal with, the root cause of the problem is that ‘Secret Service API’ on anyone can be easily accessed on DBus API. If access control is enabled, only well-known? or authorized processes, such as google- chrome, network-manager, and gnome-online-accounts, will be able to access the login credentials. DBus originally provides capability that is essential to access control of DBus API by defining security policy as a form of *.conf file. Currently, various services based on DBus interface are employing above security policy feature to perform access control. For example, login/system related functions is controlled from ‘login1’ and its security policy is described in “org.freedesktop.login1.conf”. (see https://github.com/systemd/systemd/blob/master/src/core/org.freedesktop.systemd1.conf) Likewise, why don’t we try adopting the access control of secret service API into gnome-keyring environment? Due to the fact that a process with root privilege can access “.conf” file, an approved program may only update the target file during installation process Here is really simple ‘org.freedesktop.secrets.conf’ example. = http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> = Many Thanks!! [1] https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact [2] https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-keyring 3.28.0.2-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 5 17:45:22 2018 InstallationDate: Installed on 2018-07-06 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1780365/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1780365] Re: Credentials located in gnome-keyring can be compromised easily
This issue was reported upstream: https://gitlab.gnome.org/GNOME/gnome-keyring/issues/5 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1780365 Title: Credentials located in gnome-keyring can be compromised easily Status in gnome-keyring package in Ubuntu: New Bug description: Dear all, I figure out that login credentials, located in gnome-keyring, can be easily compromised. Linux based on Gnome basically uses ‘gnome-keyring’ as their backend to store login credentials in a secure manner. Specifically, google- chrome browser, network-manager and gnome-online-accounts use this as a backend solution to store login credentials. To use this, authentication is performed together with gnome-keyring as part of ‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut down or logged out. In this state, a simple program that uses ‘Secret Service API’ call and their ‘D-Bus’ interface can easily retrieve login credentials from those gnome-keyring without any privilege escalation, listening into the X events going to another window, or installation an application on target computer. (please check PoC source https://github.com/sungjungk/keyring_crack and video https://youtu.be/Do4E9ZQaPck) The issue is different from the content shown on the Ubuntu Security FAQ and GnomeKeyring Wiki [1][2]. It was even said that “PAM session is closed via the screensaver, all keyrings are locked, and the ‘login’ keyring is unlocked upon successful authentication to the screensaver”. After trying to crack the keyring, it was far from what they really thought. It is no different than plain text file for login credentials somewhere on disk. To deal with, the root cause of the problem is that ‘Secret Service API’ on anyone can be easily accessed on DBus API. If access control is enabled, only well-known? or authorized processes, such as google- chrome, network-manager, and gnome-online-accounts, will be able to access the login credentials. DBus originally provides capability that is essential to access control of DBus API by defining security policy as a form of *.conf file. Currently, various services based on DBus interface are employing above security policy feature to perform access control. For example, login/system related functions is controlled from ‘login1’ and its security policy is described in “org.freedesktop.login1.conf”. (see https://github.com/systemd/systemd/blob/master/src/core/org.freedesktop.systemd1.conf) Likewise, why don’t we try adopting the access control of secret service API into gnome-keyring environment? Due to the fact that a process with root privilege can access “.conf” file, an approved program may only update the target file during installation process Here is really simple ‘org.freedesktop.secrets.conf’ example. = http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> = Many Thanks!! [1] https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact [2] https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-keyring 3.28.0.2-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 5 17:45:22 2018 InstallationDate: Installed on 2018-07-06 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1780365/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1780365] Re: Credentials located in gnome-keyring can be compromised easily
Thank you for reporting this bug. The access via DBus when the keyring is unlocked is a well-known issue and the design of the feature as explained when reading the entirety of https://wiki.ubuntu.com/SecurityTeam/FAQ#gnome-keyring. Users who prefer to be prompted can choose to use a separate keyring than the one that is automatically unlocked upon successful login. That said, I'm not clear if you are saying that the keyring is not locked during screensaver or logout. If either of these is the case, that sounds like a bug. Can you confirm and detail your methodology? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1780365 Title: Credentials located in gnome-keyring can be compromised easily Status in gnome-keyring package in Ubuntu: New Bug description: Dear all, I figure out that login credentials, located in gnome-keyring, can be easily compromised. Linux based on Gnome basically uses ‘gnome-keyring’ as their backend to store login credentials in a secure manner. Specifically, google- chrome browser, network-manager and gnome-online-accounts use this as a backend solution to store login credentials. To use this, authentication is performed together with gnome-keyring as part of ‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut down or logged out. In this state, a simple program that uses ‘Secret Service API’ call and their ‘D-Bus’ interface can easily retrieve login credentials from those gnome-keyring without any privilege escalation, listening into the X events going to another window, or installation an application on target computer. (please check PoC source https://github.com/sungjungk/keyring_crack and video https://youtu.be/Do4E9ZQaPck) The issue is different from the content shown on the Ubuntu Security FAQ and GnomeKeyring Wiki [1][2]. It was even said that “PAM session is closed via the screensaver, all keyrings are locked, and the ‘login’ keyring is unlocked upon successful authentication to the screensaver”. After trying to crack the keyring, it was far from what they really thought. It is no different than plain text file for login credentials somewhere on disk. To deal with, the root cause of the problem is that ‘Secret Service API’ on anyone can be easily accessed on DBus API. If access control is enabled, only well-known? or authorized processes, such as google- chrome, network-manager, and gnome-online-accounts, will be able to access the login credentials. DBus originally provides capability that is essential to access control of DBus API by defining security policy as a form of *.conf file. Currently, various services based on DBus interface are employing above security policy feature to perform access control. For example, login/system related functions is controlled from ‘login1’ and its security policy is described in “org.freedesktop.login1.conf”. (see https://github.com/systemd/systemd/blob/master/src/core/org.freedesktop.systemd1.conf) Likewise, why don’t we try adopting the access control of secret service API into gnome-keyring environment? Due to the fact that a process with root privilege can access “.conf” file, an approved program may only update the target file during installation process Here is really simple ‘org.freedesktop.secrets.conf’ example. = http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> = Many Thanks!! [1] https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact [2] https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-keyring 3.28.0.2-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 5 17:45:22 2018 InstallationDate: Installed on 2018-07-06 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1780365/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1780365] Re: Credentials located in gnome-keyring can be compromised easily
** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1780365 Title: Credentials located in gnome-keyring can be compromised easily Status in gnome-keyring package in Ubuntu: New Bug description: Dear all, I figure out that login credentials, located in gnome-keyring, can be easily compromised. Linux based on Gnome basically uses ‘gnome-keyring’ as their backend to store login credentials in a secure manner. Specifically, google- chrome browser, network-manager and gnome-online-accounts use this as a backend solution to store login credentials. To use this, authentication is performed together with gnome-keyring as part of ‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut down or logged out. In this state, a simple program that uses ‘Secret Service API’ call and their ‘D-Bus’ interface can easily retrieve login credentials from those gnome-keyring without any privilege escalation, listening into the X events going to another window, or installation an application on target computer. (please check PoC source https://github.com/sungjungk/keyring_crack and video https://youtu.be/Do4E9ZQaPck) The issue is different from the content shown on the Ubuntu Security FAQ and GnomeKeyring Wiki [1][2]. It was even said that “PAM session is closed via the screensaver, all keyrings are locked, and the ‘login’ keyring is unlocked upon successful authentication to the screensaver”. After trying to crack the keyring, it was far from what they really thought. It is no different than plain text file for login credentials somewhere on disk. To deal with, the root cause of the problem is that ‘Secret Service API’ on anyone can be easily accessed on DBus API. If access control is enabled, only well-known? or authorized processes, such as google- chrome, network-manager, and gnome-online-accounts, will be able to access the login credentials. DBus originally provides capability that is essential to access control of DBus API by defining security policy as a form of *.conf file. Currently, various services based on DBus interface are employing above security policy feature to perform access control. For example, login/system related functions is controlled from ‘login1’ and its security policy is described in “org.freedesktop.login1.conf”. (see https://github.com/systemd/systemd/blob/master/src/core/org.freedesktop.systemd1.conf) Likewise, why don’t we try adopting the access control of secret service API into gnome-keyring environment? Due to the fact that a process with root privilege can access “.conf” file, an approved program may only update the target file during installation process Here is really simple ‘org.freedesktop.secrets.conf’ example. = http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> = Many Thanks!! [1] https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact [2] https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-keyring 3.28.0.2-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 5 17:45:22 2018 InstallationDate: Installed on 2018-07-06 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1780365/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1780365] Re: Credentials located in gnome-keyring can be compromised easily
** Description changed: Dear all, I figure out that login credentials, located in gnome-keyring, can be easily compromised. Linux based on Gnome basically uses ‘gnome-keyring’ as their backend to store login credentials in a secure manner. Specifically, google-chrome browser, network-manager and gnome-online-accounts use this as a backend solution to store login credentials. - To use this, authentication is performed together with gnome-keyring as part of ‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut down or logged out. In this state, a simple program that uses ‘Secret Service API’ call and their ‘D-Bus’ interface can easily retrieve login credentials from those gnome-keyring without any privilege escalation, listening into the X events going to another window, or installation an application on target computer. + To use this, authentication is performed together with gnome-keyring as part of ‘pam-gnome-keyring.so’. At this point, it remains unlocked until system is shut down or logged out. In this state, a simple program that uses ‘Secret Service API’ call and their ‘D-Bus’ interface can easily retrieve login credentials from those gnome-keyring without any privilege escalation, listening into the X events going to another window, or installation an application on target computer. (please check PoC source https://github.com/sungjungk/keyring_crack and video https://youtu.be/Do4E9ZQaPck) The issue is different from the content shown on the Ubuntu Security FAQ and GnomeKeyring Wiki [1][2]. It was even said that “PAM session is closed via the screensaver, all keyrings are locked, and the ‘login’ keyring is unlocked upon successful authentication to the screensaver”. After trying to crack the keyring, it was far from what they really thought. It is no different than plain text file for login credentials somewhere on disk. To deal with, the root cause of the problem is that ‘Secret Service API’ on anyone can be easily accessed on DBus API. If access control is enabled, only well-known? or authorized processes, such as google- chrome, network-manager, and gnome-online-accounts, will be able to access the login credentials. DBus originally provides capability that is essential to access control of DBus API by defining security policy as a form of *.conf file. Currently, various services based on DBus interface are employing above security policy feature to perform access control. For example, login/system related functions is controlled from ‘login1’ and its security policy is described in “org.freedesktop.login1.conf”. (see https://github.com/systemd/systemd/blob/master/src/core/org.freedesktop.systemd1.conf) Likewise, why don’t we try adopting the access control of secret service API into gnome-keyring environment? Due to the fact that a process with root privilege can access “.conf” file, an approved program may only update the target file during installation process Here is really simple ‘org.freedesktop.secrets.conf’ example. = http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> + "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd;> - + - + + + - - + + - - - - - - + + + = - Many Thanks!! [1] https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact [2] https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-keyring 3.28.0.2-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 5 17:45:22 2018 InstallationDate: Installed on 2018-07-06 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - XDG_RUNTIME_DIR= - LANG=en_US.UTF-8 - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=en_US.UTF-8 + SHELL=/bin/bash SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) ** Information type changed from Public to Private Security -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-keyring in Ubuntu. https://bugs.launchpad.net/bugs/1780365 Title: Credentials located in gnome-keyring can be compromised easily Status in gnome-keyring package in Ubuntu: New Bug description: Dear all, I figure out that login
