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
or,
$ 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.
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.