gdomap multiple local information disclosure vulnerabilities

Bug #573108 reported by Dan Rosenberg on 2010-05-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnustep-base (Ubuntu)
Jamie Strandboge

Bug Description

gdomap, part of GNUstep, is vulnerable to two different information disclosure vulnerabilities that each allow unprivileged local users to read the contents of arbitrary files.

gdomap is installed setuid root by default. When invoked with the -c (config file for probe) flag, gdomap reads a user-specified file without confirming its ownership or permissions, and then attempts to parse it as a configuration file. In a failed attempt to parse, gdomap will print an error message containing the full contents of the provided file, allowing an unprivileged local user to read anything on disk. This also occurs when gdomap is invoked with the -a (config file for interface list) flag, which uses a separate (but nearly identical) code path.

This behavior can by confirmed by:

$ gdomap -c /etc/shadow


$ gdomap -a /etc/shadow

The ability to read arbitrary files on disk can easily result in privilege escalation (reading SSH keys, etc.). To mitigate the issue, permissions should be dropped to that of the invoking user prior to opening a provided configuration file.

Dan Rosenberg (dan-j-rosenberg) wrote :

On a second look, it appears that gdomap is no longer installed with the setuid bit on Ubuntu. I could find no mention of a change in any of the changelogs, but I assume it was installed setuid at some point in the past, since it was setuid root on my Karmic machine and I did not set it manually.

With the setuid bit unset, this no longer represents a security issue to Ubuntu, but I'm sure upstream would be interested, since gdomap is evidently intended for usage as a setuid binary in some cases, based on its documentation and code.

Jamie Strandboge (jdstrand) wrote :

I just confirmed that Hardy, Jaunty, Karmic and Lucid are not affected (don't have the setuid bit set).

Dan, have you filed or are you planning to file an upstream bug?

Changed in gnustep-base (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: New → Incomplete
Dan Rosenberg (dan-j-rosenberg) wrote :

I'd be happy to submit a report upstream later today.

Despite the fact that the gnustep-base package does not install gdomap setuid root, I suspect that other Ubuntu packages that require gdomap set this themselves, so it might be worth fixing here as well. This appears to be what happened on my system, but unfortunately I can't track down which package was responsible.

Jamie Strandboge (jdstrand) wrote :

Hmm, gdomap is installed by gnutstep-base-runtime. If another package is setting its setuid bit, then that is a problem and we need to find it. Can you hold off of the upstream bug until this can be found? Dan, can you grep /var/lib/dpkg/info for the chmod of gdomap?

Dan Rosenberg (dan-j-rosenberg) wrote :

After much investigation, I found the problem. On installation, gnustep-base-runtime adds a statoverride of:

root root 4755 /usr/bin/gdomap

This override doesn't seem to take effect for the initial installation of this package, but if you ever reinstall it (for example with apt-get install --reinstall gnustep-base-runtime), then gdomap will be setuid root.

Unfortunately, I already submitted my upstream bug report. I'll be sure to let you know if they get back to me.

Jamie Strandboge (jdstrand) wrote :

Upstream bug (still private):

Dan Rosenberg (dan-j-rosenberg) wrote :

I've attached my fix here - I drop privileges to the invoking user before opening configuration files, and regain privileges afterwards.

I also put in checks to prevent a second security-relevant bug, which is a potentially exploitable integer overflow leading to heap corruption by providing a configuration file (or socket) with a very large number of lines, causing several malloc() calls to under-allocate space.

Jamie Strandboge (jdstrand) wrote :

Requested CRD of 2010-05-13. Unless otherwise noted, this bug can be made public on this date.

Jamie Strandboge (jdstrand) wrote :
Changed in gnustep-base (Ubuntu):
status: Incomplete → Triaged
visibility: private → public
Lenin (gagarin) wrote :

this should be updated (sync from debian)

Luca Falavigna (dktrkranz) wrote :

Fixed in Natty gnustep-base package.

Changed in gnustep-base (Ubuntu):
status: Triaged → Fix Released
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.