Bug#956045: gnome-keyring: several cryptographic vulnerabilities

[brian m. carlson]

On 2020-04-08 at 12:15:22, Daiki Ueno wrote:
> "brian m. carlson" <sandals at crustytoothpaste.net> writes:
> > [2] is an example of a cross-VM cryptographic timing attack, which can
> > also be applied across processes.  Other timing attacks are known even
> > across networks.
> 
> I am not sure why you suddenly mention cross-VM attacks while VMs are a
> different beast from containers.

The attack I mentioned states that it is possible to simply run on the
same processor as the affected process to conduct a side-channel attack.
That applies to containers as well as other processes, in addition to
VMs.

> > It is, in general, not safe to assume that any timing attack is
> > unexploitable.
> 
> I would also be concerned with that, if this was reported against crypto
> components.  However, this was reported against desktop, where
> protecting active attacks is not a goal for various reasons:
> https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy#Active_Attacks

gnome-keyring stores data in a cryptographic format and is therefore a
cryptographic tool.  The standard cryptographic model assumes an active
attacker, Mallory, who tampers with the data and monitors the actors.
Even if you do not wish to protect against active attacks where an
attacker tampers with the data, reasonable users will expect
cryptographic tools to do so.  Moreover, it is in fact part of the
threat model of other password managers, such as 1Password.

Moreover, protecting against timing attacks like this is extremely
simple.  It can be done with three lines of portable C:

  int x = 0;
  for (size_t i = 0; i < n; i++)
      x |= a[i] ^ b[i];

Now x is zero if the values matched, and nonzero if they didn't, and the
operation is constant time.  There's no reason not to fix this, even if
you don't consider it a vulnerability.

You have also not mentioned the other attack which I mentioned in which
there is information disclosure of metadata.  This is in fact trivial to
reproduce and is in my opinion the most damning of the vulnerabilities
because it is entirely passive and can be done completely offline.

An attacker should not be able to determine from my keyring how many
GnuPG keys I have stored passphrases for, which wireless network
passwords I've saved, or if I have a password for a given username on a
given Git hosting site.  Right now, all of those are trivial from my
login keyring.

The fix to issue 1 is a simple, well-known technique which is standard
practice among cryptographic tools.  The fix to the other issues is to
encrypt all the data using a secure AEAD or EtM construction.  Since the
former is easy to do and the latter is required to fix the most severe
of the issues, I'm not sure why we're arguing about the particulars.

I should also point our that when someone reports a security issue to
you with a disclosure deadline, the right time to discuss the matter or
dispute the findings is during the coordination period.  If you don't
bother to respond then, then the reporter can only assume that you don't
care at all.  I received no such discussion or feedback about the
reports during the 45 day disclosure window, only notification that some
bug reports were filed.

I would not perform coordinated disclosure with the GNOME Project again.

I stand by my bug report that these issues represent security-related
defects in the gnome-keyring package and that they need to be fixed.
Unless you are specifically disputing that they constitute defects
needing fixing, or are reporting on your intention to productively fix
them, I ask you not to further respond to this report.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20200409/fb4eedfc/attachment-0001.sig>