** 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.

  
=================================================================================
  <?xml version="1.0"?> <!--*-nxml-*-->
  <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 
1.0//EN"
          "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>

  <busconfig>
      <policy context="default">

          <deny receive_sender="*"
                      receive_interface="org.freedesktop.Secret.Item"
                      receive_member="GetSecret"/>

          <!-- allow access to seahorse application (formerly keyring manager) 
-->
          <allow receive_sender="org.gnome.seahorse.Application"
                      receive_interface="org.freedesktop.Secret.Item"
                      receive_member="GetSecret"/>

          <!-- allow access to network-manager -->
          <deny receive_sender="org.freedesktop.NetworkManager"
                      receive_interface="org.freedesktop.Secret.Item"
                      receive_member="GetSecret"/>

          <!-- allow access to gnome-online-accounts -->
          <deny receive_sender="org.gnome.OnlineAccounts"
                      receive_interface="org.freedesktop.Secret.Item"
                      receive_member="GetSecret"/>
      </policy>
  </busconfig>
  
=================================================================================

  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=<set>
   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

Reply via email to