Bugzilla Bug 229885

The tarball of sci-astronomy/xephem-3.7.3 contains bundled copies of zlib-1.2.2
and openmotif-2.2.2 (not sure if the latter is actually used).

These are vulnerable to (at least):
CAN-2005-1849, bug 99751
CAN-2005-2096, bug 97547, bug 98121
CVE-2005-3964, bug 114234

xephem should be made to link to all system provided libraries, unless there is
a very good reason not to.

Hi Robert,

Incidentally, xephem-3.7.3 does not link against any of the
libraries it ships with (motif, jpeg, png, libz)

# ldd xephem
        ...
        libXm.so.4 => /usr/lib/libXm.so.4 (0x00007f6664b82000)
        ...
        libz.so.1 => /lib/libz.so.1 (0x00007f6663dce000)
        ...
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f6661d22000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f6661afc000)
        ...

Unfortunately, this state of affairs isn't very clear from looking at
the ebuild and I will add a few pieces to make it more apparent.

I hope this is acceptable.

Thanks,
Markus

Oh, I only looked at the compilation output and saw that the libraries are
compiled. To avoid future compliations, can you edit the ebuild so that the
libraries are removed in src_unpack?

I've added

+       # make sure we use system libs not the ones that
+       # ship with the xephem tarball
+       rm -fr libjpegd/ libpng/ libz/ libXm/ \
+               || die "Failed to remove unneeded libs"
+       epatch "${FILESDIR}"/${P}-use-system-lib.patch

which removes the libs and fixes the Makefile to make
sure we link against the system libs instead.

Thanks,
Markus

(In reply to comment #3)
> Oh, I only looked at the compilation output and saw that the libraries are
> compiled.

I must admit that I filed the bug when I saw the -I../../libz and -L../../libz
compiler flags in the build.log, as well as a libz/libz.a library.

Sorry for the false alarm.

(In reply to comment #5)
> Sorry for the false alarm.
> 

That's absolutely no problem and I very much appreciated your 
note. I'd rather have a few false alarms than missing 
a security issue. The tarball (and ebuild) clearly did contain
suspicious stuff, but hopefully the new code added to the ebuild
makes things clearer.

Thanks,
Markus

It was not a false alarm, since it did link in the libs from the static
archives. Is 3.7.3 good for stabling now?

The file indimenu.c uses libz to decompress "BLOB" data. Markus, do you know
what that is?

(In reply to comment #7)
> It was not a false alarm, since it did link in the libs from the static
> archives. Is 3.7.3 good for stabling now?
> 

From my point of view, yes. However, I am not a user of xephem so if anybody
from sci has any concerns please speak up.


> The file indimenu.c uses libz to decompress "BLOB" data. Markus, do you know
> what that is?

As far as I know, xephem has the ability to interface via the INDI API
[1] to telescopes and such. The BLOBs are binary data which are part of
the transfered data structure, and probably consists of libz compressed 
images and such. Maybe somebody more versed at astronomy can correct me
should I be wrong. 

best,
Markus

[1] http://indi.sourceforge.net/index.php/Developing_INDI_drivers

(In reply to comment #8)
> (In reply to comment #7)
> > It was not a false alarm, since it did link in the libs from the static
> > archives. Is 3.7.3 good for stabling now?
> > 
> 
> From my point of view, yes. However, I am not a user of xephem so if anybody
> from sci has any concerns please speak up.

Fine with me (sorry about the mess, I was the one bumping to 3.7.3, although
3.7.2 has probably similar problems).

> 
> > The file indimenu.c uses libz to decompress "BLOB" data. Markus, do you know
> > what that is?
> 
> As far as I know, xephem has the ability to interface via the INDI API
> [1] to telescopes and such. The BLOBs are binary data which are part of
> the transfered data structure, and probably consists of libz compressed 
> images and such. Maybe somebody more versed at astronomy can correct me
> should I be wrong. 

I think it's what it does. (I play with astronomical images very often but
never used BLOBs). Anyway, the binary indiserver seems to link properly to the
system libz now.

Rerating C3 as it seems to me the vulnerable libraries are not used to process
untrusted data.

Arches, please test and mark stable:
=sci-astronomy/xephem-3.7.3
Target keywords : "amd64 ppc ppc64 x86"

x86 stable

ppc stable

ppc64 done

I've reported the issue upstream (xephem@clearskyinstitute.com).

amd64 stable, all arches done.

glsa vote ... I vote NO as per comment #10

NO, closing