[Secure-testing-team] Re: xpdf vulnerability?

[Frank Küster]

Hi Javier,

I'm following up on this because I want to learn, and because I'd like
to write something about it for developers reference.  Please don't take
me as "playing dumb", at most I'm playing devils advocate, but mostly I
simply didn't see the things when looking at the available information.
Maybe I am dumb, but then probably other Debian maintainers are, too...

Javier Fernández-Sanguino Peña <jfs at computer.org> wrote:

> On Tue, Mar 22, 2005 at 02:01:37PM +0100, Frank Küster wrote:
>> 
>> Thank you, I found it extremely difficult (as someone who follows their
>> own upstream, but not security-related mailinglists) to find ressources
>> of information.  Currently, the CVE IDs are often used to indicate which
>> issue is talked about (like in the original mail from the
>> secure-testing-team), but e.g. for CAN-2005-0206 there are no
>> cross-references except the RedHat and Mandrake advisories, which aren't
>> too helpful, either.
>
> Why not? RedHat should probably have references to their Bugzilla database 
> in their advisories...

Oh, yes, they have some at the very bottom.  However the page about
CAN-2005-0206 only mentions bugs that fix the older CAN's.  No, you have
to look at the oldest bug, in there is the newest information.

However, my point is still that this is not the information I like.  In
this particular case it is sufficient, probably.  But in other cases the
patches need not be in the BTS.  Anyway, this is always information
about what vendors did, not what I as a Debian maintainer should do.
Aren't there any closed lists that actually discuss vulnerabilities and
possible fixes before the embargo ends?  And couldn't these lists be
opened afterwards?

> For example, if you search by CVE the Xpdf vulnerability related to 
> CAN-2005-0206 you will get to BID-11501: 
> http://www.securityfocus.com/bid/11501
>
> In the 'solution' section you can see references to other vendors, and can 
> go searching for information on their bug tracking systems or security 
> advisories. Since you have a link to the version fixing it, you might do 
> best if you go and check their sources too. SRPM packages, for example, are 
> provided including both the original sources and the patches to those and 
> you cand download those directly from RPM vendors (RedHat, SuSE, Mandrake, 
> etc..) 

There is no occurence of "srpm" on
http://www.securityfocus.com/bid/11501/solution/.  And the last time I
klicked on some srpm link (I think by RedHat), it required me to pay for
some support contract before I would be allowed to download the
sources.  I'm sure there are simple ftp servers, but one first has to
find them.  

I just checked ftp.suse.com.  There are patches and src.rpm e.g. fixing
CAN-2005-0064 in the i386 directory, but nothing in the ia64
directory. In the x86-64 directory, there's an xpdf file at
http://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/xpdf-2.02pl1-148.src.rpm,
but it is dated 21-Jan-2005 02:18 and can hardly fix 2004-0206.  Anyway,
this is *very* tedious for a maintainer who simply wants to check
whether their package *is* affected at all.

> Gentoo sources include the patches to the sources in their CVS and 
> usually reference the Bugzilla entries in their advisories (and the 
> bugzilla entry usually includes the patch too).

Yes, the Gentoo bugzilla is quite informative.  Sigh, yet an other
possibility to fix this:  They changed libgoo so that g*alloc accept
t_int instead of int...  Can't the upstream author once get things
straight?

> GLSA-200410-20, which is referenced to bug 69662 in Gentoo's BTS (
> http://bugs.gentoo.org/show_bug.cgi?id=69662) includes both CVE references 
> and provides two patches

Things get even more strange: According to this, the problem that the
original patches were not 64bit-safe were already known on 2004-10-31.
And it does not make things clearer with respect to 0888 vs. 0889; the
two patches are just one against libgoo, the other against XRef (and not
patching Catalog.cc...).  

It seems to me every distribution, and every upstream using xpdf code
have used a different fix.  We should really ask Foolabs to provide a
libxpdf (Debian bug #252104), or else switch to libpoppler as much as
possible.

> In any case, from the Gentoo's BTS, it looks like this was disclosed first 
> on Vendor-Sec (a private mailing list used by open source distributions) so 
> you might want to send off a mail to the Security Team asking them to 
> forward you the relevant mails.

I thought they were Cc'ed with my first mails, but I always mix up
"debian-security at lists.debian.org" with "team at security.debian.org".

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer