Bug 953505 (CVE-2012-6140) - CVE-2012-6140 google-authenticator: Information disclosure due insecure requirement on the secrets file
Summary: CVE-2012-6140 google-authenticator: Information disclosure due insecure requi...
Keywords:
Status: CLOSED UPSTREAM
Alias: CVE-2012-6140
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 953508 953507
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-18 10:34 UTC by Jan Lieskovsky
Modified: 2019-09-29 13:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-10 11:00:27 UTC


Attachments (Terms of Use)
0005-Add-support-for-a-user-option-that-allows-for-a-maki.patch (11.95 KB, patch)
2013-04-18 16:24 UTC, Federico Simoncelli
no flags Details | Diff

Description Jan Lieskovsky 2013-04-18 10:34:42 UTC
An information disclosure file was found in the way google-authenticator, a pluggable authentication module (PAM) which allows login using one-time passcodes conforming to the open standards developed by the Initiative for Open Authentication (OATH), performed management of its secret / state file in certain configurations. Due the lack of 'user=' option the secret file was previously required to be user-readable, allowing (in certain cases) a local attacker to obtain the (pre)shared client-to-authentication-server secret, possibly leading to victim's account impersonation.

A different vulnerability than CVE-2013-0258.

References:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#20

Relevant upstream patch:
[4] https://code.google.com/p/google-authenticator/source/detail?r=c3414e9857ad64e52283f3266065ef3023fc69a8

Comment 1 Jan Lieskovsky 2013-04-18 10:36:34 UTC
This issue affects the versions of the google-authenticator package, as shipped with Fedora release of 17 and 18. Please schedule an update.

--

This issue affects the version of the google-authenticator package, as shipped with Fedora EPEL 6. Please schedule an update.

Comment 2 Jan Lieskovsky 2013-04-18 10:47:09 UTC
Created google-authenticator tracking bugs for this issue

Affects: fedora-all [bug 953507]
Affects: epel-6 [bug 953508]

Comment 3 Jan Lieskovsky 2013-04-18 10:48:35 UTC
CVE (-2012) Request:
  http://www.openwall.com/lists/oss-security/2013/04/18/4

Comment 4 Federico Simoncelli 2013-04-18 16:17:50 UTC
Rawhide, Fedora 18 and Fedora 19 are not affected since they ship git a096a62.

The backport of the suggested patch (c3414e9) to the old hgd525a9bab875 (for f17/epel6) is not trivial.

To make it simpler I decided to backport also:

2d125fc Add support for HOTP to libpam.
26f5977 strtoul() does not return an error

Which apply cleanly.

The patch required for the CVE:

c3414e9 Add support for a "user=" option

Doesn't apply cleanly because of two custom downstream patches (added before I started contributing to this package). I never knew exactly how they were used or where they came from (or why they were in the fedora package if they weren't committed upstream).

Now, we can either remove the two custom patches (f17/el6, since in rawhide, f19, f18 they've been removed already) or we can try to deal with the conflicts (2). I'll attach a proposed patch and comment on the conflicts ASAP.

Comment 5 Federico Simoncelli 2013-04-18 16:24:23 UTC
Created attachment 737353 [details]
0005-Add-support-for-a-user-option-that-allows-for-a-maki.patch

The conflicting parts are:

++<<<<<<< HEAD
 +  int        no_drop_privs;
++=======
+   int        fixed_uid;
+   uid_t      uid;
++>>>>>>> c3414e9... Add support for a "user=" option that allows for a) making the state file

Which has been resolved to:

 +  int        no_drop_privs;
+   int        fixed_uid;
+   uid_t      uid;

And:

++<<<<<<< HEAD
 +      (params.no_drop_privs ||
 +       (old_uid = drop_privileges(pamh, username, uid))) >= 0 &&
 +      (fd = open_secret_file(pamh, secret_filename, params.no_drop_privs?"root":username,
 +                           params.no_drop_privs?0:uid, &filesize, &mtime)) >= 0 &&
++=======
+       !drop_privileges(pamh, username, uid, &old_uid, &old_gid) &&
+       (fd = open_secret_file(pamh, secret_filename, &params, username, uid,
+                              &filesize, &mtime)) >= 0 &&
++>>>>>>> c3414e9... Add support for a "user=" option that allows for a) making the state file

Which has been resolved to:

 -      !drop_privileges(pamh, username, uid, &old_uid, &old_gid) &&
 -      (fd = open_secret_file(pamh, secret_filename, &params, username, uid,
 -                             &filesize, &mtime)) >= 0 &&
 +      (params.no_drop_privs ||
-        (old_uid = drop_privileges(pamh, username, uid))) >= 0 &&
-       (fd = open_secret_file(pamh, secret_filename, params.no_drop_privs?"root":username,
++       !drop_privileges(pamh, username, uid, &old_uid, &old_gid)) &&
++      (fd = open_secret_file(pamh, secret_filename, &params, params.no_drop_privs?"root":username,
 +                           params.no_drop_privs?0:uid, &filesize, &mtime)) >= 0 &&

Comment 6 Vincent Danen 2013-04-18 20:34:53 UTC
This was assigned CVE-2012-6140:

http://www.openwall.com/lists/oss-security/2013/04/18/10

Comment 7 Jan Lieskovsky 2013-04-19 07:38:31 UTC
Hello Federico,

  thank you for checking with me.

(In reply to comment #4)
> Rawhide, Fedora 18 and Fedora 19 are not affected since they ship git
> a096a62.

I don't have Fedora 18 system around to check if the google-authenticator-1.0-0.gita096a62.fc18 is in the -stable repository already (or just in -testing). So it's possible the issue is fixed in Fedora 18 already (couldn't verify).

> 
> The backport of the suggested patch (c3414e9) to the old hgd525a9bab875 (for
> f17/epel6) is not trivial.
> 
> To make it simpler I decided to backport also:
> 
> 2d125fc Add support for HOTP to libpam.
> 26f5977 strtoul() does not return an error
> 
> Which apply cleanly.
> 
> The patch required for the CVE:
> 
> c3414e9 Add support for a "user=" option
> 
> Doesn't apply cleanly because of two custom downstream patches (added before
> I started contributing to this package). I never knew exactly how they were
> used or where they came from (or why they were in the fedora package if they
> weren't committed upstream).
> 
> Now, we can either remove the two custom patches (f17/el6, since in rawhide,
> f19, f18 they've been removed already) or we can try to deal with the
> conflicts (2). I'll attach a proposed patch and comment on the conflicts
> ASAP.

What are the rules for rebasing package version in Fedora 17 / Fedora EPEL 6? Would it be possible to rebase them to the upstream version, which is in Fedora 18 already? If so, I would follow this approach (rebase to latest upstream version in those products too). If not, I would just remove the two custom patches (if those are truly useful features, they should be proposed upstream for inclusion into the current code) and apply the upstream one for the security fix.

HTH, Jan.

Comment 8 Federico Simoncelli 2013-04-19 14:05:01 UTC
(In reply to comment #7)
> Hello Federico,
> 
>   thank you for checking with me.
> 
> (In reply to comment #4)
> > Rawhide, Fedora 18 and Fedora 19 are not affected since they ship git
> > a096a62.
> 
> I don't have Fedora 18 system around to check if the
> google-authenticator-1.0-0.gita096a62.fc18 is in the -stable repository
> already (or just in -testing). So it's possible the issue is fixed in Fedora
> 18 already (couldn't verify).

Ah yes it might be in -testing.
We can go ahead and release, the point is that it's not really clear to me what the two custom patches are doing and why they are there.
As far as I'm concerned we can go ahead and remove them hoping that nobody is using them.

The two patches are:

Add no-drop-privs option to manage secret files as root
http://pkgs.fedoraproject.org/cgit/google-authenticator.git/tree/0001-Add-no-drop-privs-option-to-manage-secret-files-as-r.patch?h=f17

Allow expansion of PAM environment variables in secret file name
http://pkgs.fedoraproject.org/cgit/google-authenticator.git/tree/0002-Allow-expansion-of-PAM-environment-variables-in-secr.patch?h=f17

> > Now, we can either remove the two custom patches (f17/el6, since in rawhide,
> > f19, f18 they've been removed already) or we can try to deal with the
> > conflicts (2). I'll attach a proposed patch and comment on the conflicts
> > ASAP.
> 
> What are the rules for rebasing package version in Fedora 17 / Fedora EPEL
> 6? Would it be possible to rebase them to the upstream version, which is in
> Fedora 18 already? If so, I would follow this approach (rebase to latest
> upstream version in those products too). If not, I would just remove the two
> custom patches (if those are truly useful features, they should be proposed
> upstream for inclusion into the current code) and apply the upstream one for
> the security fix.

If we can get rid of the two custom patches either way it's fine by me (upgrade to latest version or just apply the fix).
I'd prefer to upgrade to the latest version though: gita096a62.

I think that this security issue is a quite good reason to finally remove these custom patches. If there's no objection I'll go ahead and do that.

Comment 10 David Woodhouse 2013-04-19 21:07:49 UTC
The patches allow a saner option for file storage than the original broken one where the user's home directory was used.

One patch allows the secret file name to contain expanded PAM environment variables: http://code.google.com/p/google-authenticator/issues/detail?id=108

The other allows it to do the file manipulation as root rather than using files owned by the user. Can't find the upstream bug for that right now...

Please don't kill this functionality; we really want to be able to use secret files as root in /etc/google-authenticator/$USER, not the default stupid scheme.

Yes, it sucks that Google are so bad at merging submitted patches.

Comment 11 Federico Simoncelli 2013-04-22 10:12:40 UTC
David please provide a feedback on the patch proposed in comment 5 (and the possible conflict resolution). Thanks.

Comment 12 Product Security DevOps Team 2019-06-10 11:00:27 UTC
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.


Note You need to log in before you can comment on or make changes to this bug.