Bug#956045: gnome-keyring: several cryptographic vulnerabilities

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

brian m. carlson-2
Package: gnome-keyring
Version: 3.36.0-1
Severity: important
Tags: security upstream

gnome-keyring has several vulnerabilities with regard to its handling of
its encrypted data files.

First, the code to verify the integrity hash is done with memcmp.  This
is not safe against timing attacks, so an attacker can tamper with the
data and determine how much of the hash matches based on the amount of
time it takes[0].  This comparison should be done in a constant-time
way.

Second, because the integrity algorithm used is MD5, which is vulnerable
to collisions, it doesn't uniquely identify a sequence of bytes.
Consequently, the padding must be checked to be zero, and it must be
done in constant time with the actual integrity algorithm, such that a
failure of either takes exactly the same amount of time.

Third, the metadata that occurs unencrypted in the file is hashed with
MD5.  Since MD5 is cheap to compute, an attacker can guess to see if the
items they want to access are in the keyring without needing to decrypt
the data.  The keys themselves are also stored unencrypted, which makes
it easy to determine which types of objects and how many of each type
are stored in the keyring.  For example, GnuPG stores a "keygrip"
attribute.  This violates user privacy and leaks a significant amount of
data.  All of this data should be stored encrypted.  Even storing both
keys and values as MACs using a secret key would leak which keys and
values are repeated, which in many cases would still leak a significant
amount of information.

Fourth, the metadata stored unencrypted is also stored without any sort
of integrity check.  As a result, an attacker can modify it at will
without any detection whatsoever.  All data stored in the file,
including version numbers, algorithm identifiers, and other structural
content, as well as encrypted data, should be protected either by an
AEAD encryption algorithm or a strong MAC (such as HMAC with SHA-2,
SHA-3, or BLAKE2).

This was originally reported to the Debian Security Team on February 3,
but they were unable to issue a CVE, so I reported it to the GNOME
Security Team on February 4.  The response was the gnome-keyring team is
"aware of those issues" but they "don't think those issues are severe
enough to urge an immediate fix" and plan to address them at an
unspecified point in the future.

Since 45 days have elapsed since the initial report and no fix is
forthcoming[1], I've opened this bug to disclose this issue publicly.
This is probably severity grave, but I don't have a true
proof-of-concept demonstrating that it allows access to user accounts,
so I opted for important.  Feel free to change as you see fit.

Please ensure CVEs are issued for these bugs.

[0] This can be a problem with an untrusted container with the user's
home directory mounted in it.  There's documentation for VS Code that
tells people how to do exactly this, so it's clearly a common situation.
[1] https://github.com/bk2204/dev-practices/tree/master/security-research

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]                   1.12.16-2
ii  dconf-gsettings-backend [gsettings-backend]   0.36.0-1
ii  gcr                                           3.36.0-2
ii  libc6                                         2.30-4
ii  libcap-ng0                                    0.7.9-2.1+b2
ii  libcap2-bin                                   1:2.33-1
ii  libgck-1-0                                    3.36.0-2
ii  libgcr-base-3-1                               3.36.0-2
ii  libgcrypt20                                   1.8.5-5
ii  libglib2.0-0                                  2.64.1-1
ii  p11-kit                                       0.23.20-1
ii  pinentry-gnome3                               1.1.0-3+b1

Versions of packages gnome-keyring recommends:
ii  gnome-keyring-pkcs11  3.36.0-1
ii  libpam-gnome-keyring  3.36.0-1

gnome-keyring suggests no packages.

-- no debconf information

--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

signature.asc (271 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

Daiki Ueno-2
"brian m. carlson" <[hidden email]> writes:

> First, the code to verify the integrity hash is done with memcmp.  This
> is not safe against timing attacks, so an attacker can tamper with the
> data and determine how much of the hash matches based on the amount of
> time it takes[0].  This comparison should be done in a constant-time
> way.
>
> [0] This can be a problem with an untrusted container with the user's
> home directory mounted in it.  There's documentation for VS Code that
> tells people how to do exactly this, so it's clearly a common situation.

Could you elaborate which document you are referring to?  I'm wondering
how it can be a problem provided that VS Code and gnome-keyring-daemon
are running as a separate process.  I believe that both snap and flatpak
provide a process isolation mechanism.

> This was originally reported to the Debian Security Team on February 3,
> but they were unable to issue a CVE, so I reported it to the GNOME
> Security Team on February 4.  The response was the gnome-keyring team is
> "aware of those issues" but they "don't think those issues are severe
> enough to urge an immediate fix" and plan to address them at an
> unspecified point in the future.

It's a bit disappointing that you didn't quote the full response with
the additional context.  Here it goes, for reference:

--8<---------------cut here---------------start------------->8---
Hello Brian,

First, thank you for reaching out to us.  We were aware of those issues
and have been piloting a new keyring format in libsecret[1], that should
address most of them, aiming at eventually merging it back to
gnome-keyring.

That said, we don't think those issues are severe enough to urge an
immediate fix.  I'm also particularly concerned with the use of AES-GCM
you suggested for encrypting data at rest, considering its brittleness
in terms of nonce reuse, and that using a key wrapping algorithm would
be more appropriate for certification purposes[2].

Footnotes:
[1]
https://opensource.com/article/19/11/secrets-management-flatpak-applications

[2]  https://phabricator.services.mozilla.com/D54589#1662092

Regards,
--8<---------------cut here---------------end--------------->8---

Reply | Threaded
Open this post in threaded view
|

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

brian m. carlson-2
On 2020-04-07 at 13:45:20, Daiki Ueno wrote:

> "brian m. carlson" <[hidden email]> writes:
>
> > First, the code to verify the integrity hash is done with memcmp.  This
> > is not safe against timing attacks, so an attacker can tamper with the
> > data and determine how much of the hash matches based on the amount of
> > time it takes[0].  This comparison should be done in a constant-time
> > way.
> >
> > [0] This can be a problem with an untrusted container with the user's
> > home directory mounted in it.  There's documentation for VS Code that
> > tells people how to do exactly this, so it's clearly a common situation.
>
> Could you elaborate which document you are referring to?  I'm wondering
> how it can be a problem provided that VS Code and gnome-keyring-daemon
> are running as a separate process.  I believe that both snap and flatpak
> provide a process isolation mechanism.
The document at [0] provides documentation on how to mount your home
directory into containers.  It is well known that people download
containers using Docker that are not audited and may contain malware[1].

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

It is, in general, not safe to assume that any timing attack is
unexploitable.

> > This was originally reported to the Debian Security Team on February 3,
> > but they were unable to issue a CVE, so I reported it to the GNOME
> > Security Team on February 4.  The response was the gnome-keyring team is
> > "aware of those issues" but they "don't think those issues are severe
> > enough to urge an immediate fix" and plan to address them at an
> > unspecified point in the future.
>
> It's a bit disappointing that you didn't quote the full response with
> the additional context.  Here it goes, for reference:

I believe my report substantially mentioned the relevant points, which
are that

* you are aware of the issues;
* you don't see the issues as warranting an immediate fix; and
* you are working on a plan to address them in gnome-keyring, but the
  point at which they will be fixed is not presently specified.

It was my intention to fairly and accurately present the substance of
your comments as relevant to the bug report without quoting the full
email.  I didn't wish to include the full contents of a private
discussion, some of which would not have even made sense without
additional email context that was not relevant to the bug report.

My response stated my position, which is that letting security
vulnerabilities linger unfixed long term is not in the public interest.
I appreciate that fixing this may be nontrivial, but a prompt and timely
security response is essential.  If I discovered the vulnerabilities,
others probably have, too, and users deserve secure software.

[0] https://code.visualstudio.com/docs/remote/containers
[1] https://www.theregister.co.uk/2017/07/28/malware_docker_containers/
[2] https://blog.cryptographyengineering.com/2012/10/27/attack-of-week-cross-vm-timing-attacks/
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

signature.asc (271 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

Daiki Ueno-2
"brian m. carlson" <[hidden email]> writes:

> On 2020-04-07 at 13:45:20, Daiki Ueno wrote:
>> "brian m. carlson" <[hidden email]> writes:
>>
>> > First, the code to verify the integrity hash is done with memcmp.  This
>> > is not safe against timing attacks, so an attacker can tamper with the
>> > data and determine how much of the hash matches based on the amount of
>> > time it takes[0].  This comparison should be done in a constant-time
>> > way.
>> >
>> > [0] This can be a problem with an untrusted container with the user's
>> > home directory mounted in it.  There's documentation for VS Code that
>> > tells people how to do exactly this, so it's clearly a common situation.
>>
>> Could you elaborate which document you are referring to?  I'm wondering
>> how it can be a problem provided that VS Code and gnome-keyring-daemon
>> are running as a separate process.  I believe that both snap and flatpak
>> provide a process isolation mechanism.
>
> The document at [0] provides documentation on how to mount your home
> directory into containers.  It is well known that people download
> containers using Docker that are not audited and may contain malware[1].

How could that be relevant?  Note that, to leverage the weakness you
reported, you would need to monitor either the activity of
gnome-keyring-daemon running on the host, or potentially, any
communication between other (trusted) applications and
gnome-keyring-daemon.  I don't think this container use-case could help.

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

> 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

Fortunately, the situation is improving thanks to the emerging
sandboxing technologies (snap, flatpak) and the Wayland security model,
though we can't be perfect as long as the user can always choose
insecure options to install untrusted applications.

>> It's a bit disappointing that you didn't quote the full response with
>> the additional context.  Here it goes, for reference:
>
> I believe my report substantially mentioned the relevant points, which
> are that
>
> * you are aware of the issues;
> * you don't see the issues as warranting an immediate fix; and
> * you are working on a plan to address them in gnome-keyring, but the
>   point at which they will be fixed is not presently specified.

By omitting the text, your report didn't convey the following important
points:
* we have a different analysis, stance, and ongoing efforts on the
  issues as mentioned in the linked article
* that article indicates that running untrusted applications with
  unnecessary previleges IS the problem

> It was my intention to fairly and accurately present the substance of
> your comments as relevant to the bug report without quoting the full
> email.

I am afraid this didn't work apparently.

Regards,

Reply | Threaded
Open this post in threaded view
|

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

brian m. carlson-2
On 2020-04-08 at 12:15:22, Daiki Ueno wrote:
> "brian m. carlson" <[hidden email]> 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

signature.asc (271 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#956045: gnome-keyring: several cryptographic vulnerabilities

Daiki Ueno-2
"brian m. carlson" <[hidden email]> writes:

> On 2020-04-08 at 12:15:22, Daiki Ueno wrote:
>> "brian m. carlson" <[hidden email]> 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.

That attack assumes that the gnome-keyring-daemon process is running
inside the VM and the attacker on the host has full control.  That
certainly falls into the category of active attacks.

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

We never say that that it is not worth fixing, but we consider it's not
our priority, because it's not vulnerable in our supported use-cases.

> 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];

And you thought that it's more effective to report it as a vulnerability
and just wait 45 days, rather than providing a trivial patch.

> You have also not mentioned the other attack which I mentioned in
> which there is information disclosure of metadata.

That's because it has already been disclosed 5 months before you
reported.  See the slides (from page 19) at my GUADEC presentation:
https://people.gnome.org/~dueno/libsecret-guadec.pdf

Although I admit I probably should have filed an issue on the upstream
tracker, I don't see any point re-evaluating the same issue and forcing
embargo.

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

Our security team lead immediately forwarded your report to us and
discussed the impact with the maintainers.  While we agreed that none of
those issues are considered to be serious enough, we also filed the
upstream issues to track those, which you've never got involved with.

If our agreement was not clear to you, there was probably a
communication problem.

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