Ubuntu

gypsy opens arbitrary files, has unchecked buffer overflows

Reported by Kees Cook on 2010-12-14
262
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Gypsy
Fix Released
Critical
gypsy (Fedora)
Unknown
Unknown
gypsy (Suse)
Fix Released
Medium
gypsy (Ubuntu)
High
Unassigned
Maverick
High
Unassigned
Natty
High
Unassigned
Oneiric
High
Unassigned

Bug Description

Regular users can request that arbitrary files be opened for reading. In the best case, this is a denial of service. Worst-case, this could lead to information disclosure or privilege escalation.

** (gypsy-daemon:23540): DEBUG: Creating client for /etc/shadow
** (gypsy-daemon:23540): DEBUG: Device name: shadow
** (gypsy-daemon:23540): DEBUG: Registered client on /org/freedesktop/Gypsy/shadow
** (gypsy-daemon:23540): DEBUG: Starting connection to /etc/shadow
** (gypsy-daemon:23540): DEBUG: Starting connection to /etc/shadow
open("/etc/shadow", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 6
open("/etc/shadow", O_RDWR|O_NOCTTY|O_NONBLOCK) = 7
** (gypsy-daemon:23540): DEBUG: GPS channel can connect

There appear to be unchecked buffer overflows as well in gps_channel_garmin_input() via nmeabuf and nmea_gpgsv(), which could be used in an attack. (If the local user attaches gypsy to a pseudo-tty they might be able to trick the string handling.)

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: gypsy-daemon 0.8-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.37-9.22-generic 2.6.37-rc5
Uname: Linux 2.6.37-9-generic x86_64
Architecture: amd64
Date: Tue Dec 14 11:23:26 2010
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: gypsy

Kees Cook (kees) wrote :
Kees Cook (kees) wrote :

Reported to upstream on Dec 14th, never heard back. :(

Changed in gypsy (Ubuntu):
status: New → Confirmed
importance: Undecided → High
visibility: private → public

https://bugs.launchpad.net/ubuntu/+source/gypsy/+bug/690323

Regular users can request that arbitrary files be opened for reading. In the best case, this is a denial of service. Worst-case, this could lead to information disclosure or privilege escalation.

** (gypsy-daemon:23540): DEBUG: Creating client for /etc/shadow
** (gypsy-daemon:23540): DEBUG: Device name: shadow
** (gypsy-daemon:23540): DEBUG: Registered client on /org/freedesktop/Gypsy/shadow
** (gypsy-daemon:23540): DEBUG: Starting connection to /etc/shadow
** (gypsy-daemon:23540): DEBUG: Starting connection to /etc/shadow
open("/etc/shadow", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 6
open("/etc/shadow", O_RDWR|O_NOCTTY|O_NONBLOCK) = 7
** (gypsy-daemon:23540): DEBUG: GPS channel can connect

There appear to be unchecked buffer overflows as well in gps_channel_garmin_input() via nmeabuf and nmea_gpgsv(), which could be used in an attack. (If the local user attaches gypsy to a pseudo-tty they might be able to trick the string handling.)

Changed in gypsy:
status: Unknown → Confirmed

Via oss-sec:

Date: Mon, 24 Jan 2011 13:57:11 -0800
From: Kees Cook
To: oss-security

Hello,

I'd like to get CVEs assigned for two issues in Gypsy[1]:

reads arbitrary files as root user on behalf of regular user
https://bugs.freedesktop.org/show_bug.cgi?id=33431

buffer overflow in nmea device input handling
https://bugs.freedesktop.org/show_bug.cgi?id=33431

Thanks,

-Kees

[1] http://gypsy.freedesktop.org/wiki/

Via oss-sec:

I'm giving these 2011 IDs. None of the information was public in 2010.

----- Original Message -----
> Hello,
>
> I'd like to get CVEs assigned for two issues in Gypsy[1]:
>
> reads arbitrary files as root user on behalf of regular user
> https://bugs.freedesktop.org/show_bug.cgi?id=33431

Use CVE-2011-0523.

>
> buffer overflow in nmea device input handling
> https://bugs.freedesktop.org/show_bug.cgi?id=33431
>

Use CVE-2011-0524.

Thanks.

--
    JB

has anyone seen patches floating around for these.
upstream does not look too alive and no-one else has touched the package yet

the whole program has code like this in countless places:

        char nmeabuf[256];
        nmea_foobar(foo, nmeabuf);

nmea_foobar(foo2* foo, char* bar)
{
           char buf[256];

           sprintf(buf, ....);

           unsigned char cksum = nmea_cksum(buf);

           sprintf(bar, "$%s*%02X\r\n", buf, cksum);
}

so at least we'd have to make buf a few bytes smaller to have a chance,
but I guess that does not even completely fix one of the two issues

WOW: this is gross:

gypsy-client.c line 653:

        /* Open a connection to our device */
        /* we assume that a device path starting with slash is a tty device */
        if (priv->device_path[0] == '/') {

how do we continue here ?

This doesnt look good and it seems there are more
problems than what has been reported.
Is it an important package?

"gps multiplexing daemon" to let multiple clients access gps devices.

does not really sound too common.

I did not even know I was assigned to this package, had never touched it before.

Vincent, you're the only one listed in the changelog of this package, can you
comment on the importance of this package ?

It's not an essential package, but without it, only one app can access to a gps device, which is an issue if many apps are doing geolocation -- it's starting to become common.

If we consider dropping the package, I guess some review to know what else is wrong would be nice, so that upstream can go ahead and fix things.

in https://bugs.launchpad.net/ubuntu/+source/gypsy/+bug/690323
the reporter says this was reported to upstream on December 14th
but he never heard back (there have not been any code changes in this
project since last June)

Changed in gypsy (Suse):
importance: Unknown → Medium
status: Unknown → Confirmed

Unlikely to be used on multi-user machines. Let's ignore it and when upstream fixed it we will have it in Factory.

I disagree. That thing runs as root and I bet it's nowhere documented that it opens gaping security holes.

p5->p3 mass change

Changed in gypsy:
importance: Unknown → Critical

maybe policykit can be of use here for a non-intrusive change.
Define two actions "device-open" and "device-change". The former could be granted to local, active sessions by default. The latter should be auth_admin. By starting with no device defined the daemon would require admin auth once to set the initial device. The daemon stores the device name in a config file. As long as the user requests to open only that device the "device-open" action would be granted. If the user changes the device the "device-change" action requires admin auth again. That way overly paranoid checks at device open time are not needed.

Created attachment 52255
security fix

Patch by Michael Leibowitz, further modified by myself.

Created attachment 52256
Fix buffer overflows in 0.8 codebase

(In reply to comment #0)
<snip>
> There appear to be unchecked buffer overflows as well in
> gps_channel_garmin_input() via nmeabuf and nmea_gpgsv(), which could be used in
> an attack. (If the local user attaches gypsy to a pseudo-tty they might be able
> to trick the string handling.)

Note that this is only a problem in the 0.8 codebase, the latest master's parsing code is completely rewritten and doesn't use sprintf() anymore.

Now that we have the discovery system in master, we could use that to only allow known device files to be connected to

(In reply to comment #4)
> Now that we have the discovery system in master, we could use that to only
> allow known device files to be connected to

That could be a second keyword for the conf file (bluetooth-known). Though I'd like to say that the current code will hide a lot of older Bluetooth GPS devices because they don't use the correct Class (the positioning device class was fairly recent).

Could I get some review on those patches?

There are patches in the upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=33431

They look okay to me, but haven't been reviewed by upstream maintainer yet. Do we want to just go ahead with the patches?

Please go ahead. The glob restrictions are not really a good solution though as it still allows users to specify devices that they problably shouldn't because there's other hardware connected (or a vt in case of e.g. /dev/tty1).

Andreas Moog (amoog) wrote :

Fixed in version 0.8-0ubuntu4

Changed in gypsy (Ubuntu):
status: Confirmed → Fix Released
Andreas Moog (amoog) on 2012-02-11
Changed in gypsy (Ubuntu Maverick):
importance: Undecided → High
Changed in gypsy (Ubuntu Natty):
importance: Undecided → High
Changed in gypsy (Ubuntu Oneiric):
importance: Undecided → High
Changed in gypsy (Ubuntu Maverick):
status: New → Triaged
Changed in gypsy (Ubuntu Natty):
status: New → Triaged
Changed in gypsy (Ubuntu Oneiric):
status: New → Triaged
Andreas Moog (amoog) on 2012-02-11
Changed in gypsy (Ubuntu Oneiric):
status: Triaged → Confirmed
Changed in gypsy (Ubuntu Natty):
status: Triaged → Confirmed
Changed in gypsy (Ubuntu Maverick):
status: Triaged → Confirmed
Andreas Moog (amoog) wrote :
Andreas Moog (amoog) wrote :
Andreas Moog (amoog) wrote :

This service should not run as root, and udev should be responsible for identifying GPS devices and setting a
group r/w access for this daemon. The conf file whitelist is insufficient.

Marc Deslauriers (mdeslaur) wrote :

I agree with Kees, this should be fixed in a better way than with a whitelist.

That being said, I don't mind sponsoring this fix to earlier releases until something better comes along.

I took a look at the precise package, and the debdiffs for the previous releases, and none of them actually ship the whitelist config file in the binary packages (/etc/gypsy.conf).

Please fix that in precise, and submit updated debdiffs. Thanks.

Marc Deslauriers (mdeslaur) wrote :

I am unsubscribing ubuntu-security-sponsors for now, please resubscribe the team once updated debdiffs have been attached, and you have described the testing you've performed to make sure no regressions are introduced in the stable releases. Thanks.

Andreas Moog (amoog) wrote :

Kees, I know that this is only a workaround and not a proper fix. But as upstream is pretty inactive at the moment I don't think another solution is likely to come soon.

Marc, thanks for spotting, sorry for that. Updated debdiffs attached.

Andreas Moog (amoog) wrote :
Andreas Moog (amoog) wrote :
Andreas Moog (amoog) wrote :
Andreas Moog (amoog) wrote :

I tested the package in oneiric and precise and it works as before. I didn't encounter a regression so far.

Marc Deslauriers (mdeslaur) wrote :

Thanks for the updated debdiffs Andreas. ACK.
I have uploaded them to be built, and will release them as security updates today.

The only thing I did was regenerate the autoreconf patch, as I didn't have any way to review it.

Thanks!

Changed in gypsy (Ubuntu Maverick):
status: Confirmed → Fix Committed
Changed in gypsy (Ubuntu Natty):
status: Confirmed → Fix Committed
Changed in gypsy (Ubuntu Oneiric):
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gypsy - 0.8-0ubuntu3.1

---------------
gypsy (0.8-0ubuntu3.1) oneiric-security; urgency=low

  * SECURITY UPDATE: "arbitrary file access and buffer overflows"
    A new config file, /etc/gypsy.conf, is added that specifies a whitelist
    of globs. By default, they are "/dev/tty*", "/dev/pgps", and "bluetooth"
    (which matches Bluetooth addresses).
    Thanks to Michael Leibowitz <email address hidden>
    CVE-2011-0523
  * SECURITY UPDATE: Prevent buffer overflows in NMEA parsing by using
    snprintf() instead of sprintf.
    Thanks to Bastien Nocera <email address hidden>
    CVE-2011-0524 (LP: #690323)
  * Run autoreconf to include changes to configure.ac
 -- Andreas Moog <email address hidden> Sat, 11 Feb 2012 15:51:56 +0100

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gypsy - 0.8-0ubuntu2.1

---------------
gypsy (0.8-0ubuntu2.1) natty-security; urgency=low

  * SECURITY UPDATE: "arbitrary file access and buffer overflows"
    A new config file, /etc/gypsy.conf, is added that specifies a whitelist
    of globs. By default, they are "/dev/tty*", "/dev/pgps", and "bluetooth"
    (which matches Bluetooth addresses).
    Thanks to Michael Leibowitz <email address hidden>
    CVE-2011-0523
  * SECURITY UPDATE: Prevent buffer overflows in NMEA parsing by using
    snprintf() instead of sprintf.
    Thanks to Bastien Nocera <email address hidden>
    CVE-2011-0524 (LP: #690323)
  * Run autoreconf to include changes to configure.ac
 -- Andreas Moog <email address hidden> Sat, 11 Feb 2012 15:59:26 +0100

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gypsy - 0.8-0ubuntu1.1

---------------
gypsy (0.8-0ubuntu1.1) maverick-security; urgency=low

  * SECURITY UPDATE: "arbitrary file access and buffer overflows"
    A new config file, /etc/gypsy.conf, is added that specifies a whitelist
    of globs. By default, they are "/dev/tty*", "/dev/pgps", and "bluetooth"
    (which matches Bluetooth addresses).
    Thanks to Michael Leibowitz <email address hidden>
    CVE-2011-0523
  * SECURITY UPDATE: Prevent buffer overflows in NMEA parsing by using
    snprintf() instead of sprintf.
    Thanks to Bastien Nocera <email address hidden>
    CVE-2011-0524 (LP: #690323)
  * Run autoreconf to include changes to configure.ac
 -- Andreas Moog <email address hidden> Sat, 11 Feb 2012 16:02:45 +0100

Changed in gypsy (Ubuntu Maverick):
status: Fix Committed → Fix Released
Changed in gypsy (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in gypsy (Ubuntu Oneiric):
status: Fix Committed → Fix Released

Again, can I get a review on those patches, please?

Buffer overflow fixes look fine to me.

I still prefer that udev or something is used to set permissions on devices and that this daemon run as a non-root user. The whitelist is better than nothing, but it'd be nice to see this not running as root at all.

Have committed the first patch.
The second patch no longer applies to the codebase as the whole NMEA parser system has been removed and there isn't a 0.8 branch to apply it to.

Changed in gypsy:
status: Confirmed → Fix Released

Submitted for 11.4/12.1/12.2 in mr#127426. Submitted for Factory in sr#127428

This is an autogenerated message for OBS integration:
This bug (666839) was mentioned in
https://build.opensuse.org/request/show/127428 Factory / gypsy

openSUSE-SU-2012:0884-1: An update that fixes two vulnerabilities is now available.

Category: security (moderate)
Bug References: 666839
CVE References: CVE-2011-0523,CVE-2011-0524
Sources used:
openSUSE 12.1 (src): gypsy-0.8-7.4.1
openSUSE 11.4 (src): gypsy-0.8-5.1

Changed in gypsy (Suse):
status: Confirmed → Fix Released

This is an autogenerated message for OBS integration:
This bug (666839) was mentioned in
https://build.opensuse.org/request/show/129672 Evergreen:11.2 / gypsy

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.