Bug 95350 (CVE-2005-1625)

Must fix ASAP, looks easily remote exploitable.   
  
AJ, this is going to bite us severly, because we still have acroread5  
in 9.2 and before. 
 
NLD fix can wait until SP2 (which goes out this week, right)? 

This means we can only do a version update to version 7, right?

In that case a version upgrade is approved where it's possible to do so without
major problems.  for older distros we might need to advice folks to remove acroread.

So, let's try to get a version update out for at least 9.1 and 9.2 - and talk
with Gerald and Thorsten about SLES9.

 SM-Tracker-1744

I'm afraid we have little alternatives than doing the same for SLES9,
though I wonder why we have a package like acroread, which only runs
on two of our platforms, on SLES at all.

Thorsten, what do you think (both on the security update and dropping
this for SLES10)?

Security update: We have no choice. 
Dropping it: There is no free implementation is works as good as acroread 
itself for me. 

We need updated packages ASAP ...  George, are you there? 

Am I supposed to check out the 9.1 and 9.2 acroread versions, update the spec 
file to now use the 7.0 code, or can I just checkin the 9.3 version into those 
previous versions? I'll start on the first option because that is how I 
believe I'm supposed to do it... 

start with the distros that have version 7 first (stable, 9.3 , nld-sp2) 
 
9.1 , sles9 and nld will share the same codebase for acroread at the end I 
hope, so we will use an RPM based on the NLD-SP2 version you already have. 
 
for 9.2, use the 9.3 version if possible. 

I don't have most of these distributions to test on, however I did test the 
sles9 version and it worked great. 
 
I tried to build the 9.3 version building against 9.2 but it fails because of 
some other package that is needed for delivering the acroread.png icon. 
 
I took the current NLD one I've been working on (which installs the 
acroread.png also), built it succesfully on 9.1, 9.2, 9.3, and sles9. I 
submitted it to 9.1-beta, 9.2-beta, NLD-beta, sles9-beta, and STABLE. 
 
If I've done anything wrong let me know (I am concerned that the change log 
will be totally different with this package, then what they had in the v5, but 
maybe that is OK...)  I won't be in town tomorrow until Sunday, so after that 
I can work on it some more if needed. 
 
 

The 9.3 submission was missing. 
 
I submitted the 9.2 one to 9.3 too. 
 
Btw, does adobe supply us the non-versioned tarball this way? 
this is a bit irritating. 

this leaves vulnerable: 
 
ul1-i386 , sles8-slec-i386 
8.2-i386 and 9.0-i386 
 
 
Ralf, Gerald, Andreas ... what to do? 

patchinfos submitted for 9.1-9.3 and sles9 / Nld  

8.2 is at the end of it's lifetime.
If we can do the same for 9.0 as for 9.1 fine - otherwise announce that no
fix is available.

Marcus, according to comment #5 by Thorsten and comment #4 we don't have
a choice, so we'll need to update ul1-i386 and sles8-slec-i386 as well,
don't we?

rpm -q --requires -p /work/CDs/all/full-9.1-i386/suse/i586/acroread.rpm |grep 
GLIBC 
... 
libc.so.6(GLIBC_2.3)   
 
 
tough luck, since sles8 is GLIBC 2.2.5 based. 
 
any further insights? 

The maintenance update (f8ccd543430abb4644c845b0ed77b60f, YOU-Patchfile: 10304)
does not work on nld9-x86_64:

brecht:~ # /usr/X11R6/bin/acroread
Aborted

A stack trace will be attached.

Created attachment 41631 [details]
stack trace of acroread7 on nld-x86_64

After installing glibc-locale-32bit from GA, acroread does work.
Looks like a dependency problem.

rpm -Va --nofiles did not complain after applying the patch without having
glibc-locale-32bit installed !

On our reference host for sles9-x86_64, I see another problem:

nicolaus:~ # rpm -Va --nofiles
Unsatisfied dependencies for acroread-7.0.0-5.4: libcurl.so.2

This hasn't been there before.

nicolaus:~ # rpm -ql curl
/usr/bin/curl
/usr/lib64/libcurl.la
/usr/lib64/libcurl.so.2
/usr/lib64/libcurl.so.2.0.2
...

mls and I found a solution for these 2 issues.  

For nld - x86_64 we added glibc-locale-32bit to the selection file.  That is how
it works for 9.3-x86_64 also.  Patching still would not work though because the
base install would not have that other package...  Is the solution you guys have
good for x86_64 and i386? because it really should work for the same for i386
and not create a new x86_64 package that is really only i386 - as that is what
it's compiled for at acrobat.

we use a trick with the YOU patch files. 
 
we have sets for i386 which just update the acroread package. 
 
the sets for x86_64 include the glibc-locale-32bit and curl-32bit packages 
and are specified as "UpdateOnlyInstalled: false", so if one of the packages 
is there, all 3 will be installed.  
The acroread for those is the exact one as used for i386. 

Thats a nice way to handle it.  I have one other issue, when I submitted this
package to all the distributions I missed a tag Rudi added to the spec file:
"NoSource: 0"   I read a little about it but I don't understand the need except
that it helps for encription laws or something?  I've submitted the fixed
package to STABLE,  do we need to update the patch to have this in it for all
the dist's?

nosource is for: 
- we do not want to ship the sourcecode (if it included patented stuff for 
instance) 
- its a pure binary tarball which we 1:1 repackage without information loss 
 
the latter is the case for acroreade ... it saved space on the CDs. 
 
 
I have published the updated for 9.0 -> 9.3 , sles 9, and nld 9 now. 
 
8.2 discontinued, sles8 / ul1 / slec8 we can not upgrade, I also added this 
information to the security advisory. 
 
 
All is well -> resolved/fixed 

CVE-2005-1625: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)