Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

See URL. There is a clamav database that allows to scan for zlib and displays 
the version of the included zlib. 
When scanning my up-to-date system I found several instances of zlib-1.2.2 even 
if glsa-check -t all does not notify me of any vulnerabilities. 

Reproducible: Always
Steps to Reproduce:
1.emerge =sys-libs/zlib-1.2.2  
2.emerge app-backup/dar  
3.emerge sys-apss/module-init-tools  
4.emerge app-shells/sash  
5.emerge -uD world 
  
Actual Results:  
/usr/bin/dar_static, /sbin/modprobe, /sbin/modinfo, /sbin/depmod and /bin/sash 
still contain the vulnerable zlib-1.2.2 even after a complete system update. 

Expected Results:  
Remerge of all packages that include the system zlib in a static way.  

I also found a static zlib in media-gfx/megapov, but I am not sure, if this is    
a problem only on my system (Why should a normal application like megapov be   
linked static?). I also did not audit any packages not installed on my system,   
so there could be still more static copies of zlib out there.   
(There are many static copies of zlib-1.1 (for example blackdown-jdk/jre), but   
these are not affected by GLSA-200507-19)   
   
Things that could be done to secure a gentoo system against this problem:   
   
* Make all static users of zlib depend on >=sys-libs/zlib-1.2.3 and block on   
<sys-libs/zlib-1.2.3   
* rev-bump all packages of static users to build new versions on all gentoo   
installations   
(* remove zlib-1.2.2* from portage?)   
  
I would make this bug critial like the original zlib bug, but normaly the 
affected applications will probably not be used to process any untrusted data.

app-backup/dar, module-init-tools, sash do not include a local zlib but link to
it statically. You need to rebuild. Security team please vote if a GLSA is
needed. megapov has been checked and does not include a local zlib so this is
probably a linking issue, and povray links to a dynamic zlib.

For packages linking to affected static versions, I think we need :
- to have a new ebuild forcing the >=1.2.3 dep
- to post a GLSA

app-backup/dar-2.2.2 is forcing >=1.2.3, needs a few stable (sparc, ppc)
sys-apps/module-init-tools isn't forcing anything, needs a bump with a forced dep
app-shells/sash isn't forcing anything, needs a bump with a forced dep

Pulling in base-system for module-init-tools (we'll probably need a 3.0-r3 and a
3.2_pre7-r2)
We'll need someone to bump sash to 3.7-r1 (no metadata)

by 'need a GLSA' you mean update the current one to note packages which link
statically with zlib

also, i dont think module-init-tools links with zlib statically

module-init-tools links a static copy of zlib. 
 
From the configure of this package: 
# If zlib is required, libz must be linked static, modprobe is in 
# /sbin, libz is in /usr/lib and may not be available when it is run. 
# Check whether --enable-zlib or --disable-zlib was given. 
if test "${enable_zlib+set}" = set; then 
  enableval="$enable_zlib" 
  if test "$enableval" = "yes"; then 
  cat >>confdefs.h <<\_ACEOF 
#define CONFIG_USE_ZLIB 1 
_ACEOF 
 
  zlib_flags="-Wl,-Bstatic -lz -Wl,-Bdynamic" 
fi 
fi; 
 
 
On gentoo libz.so is in /lib, but this seem not to be the default location. 
 
As for dar: It seems dar is missing from my world, because it was only a 
dependency of kdar. But I masked >kdar-2.0.0 and now the updating of dar broke 
also. So dar is no longer an issue. 

you cant just read the configure script

consult the ebuild where we purposefully disable static zlib linking

Sorry, I really did not read the ebuild. 
 
But the static zlib linking is only in the 3.1 and 3.2 ebuild disabled. 
The stable module-init-tools-3.0-r2.ebuild still uses static linking for the 
zlib. 
 
There seems to be something wrong with the commit: 
http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-apps/module-init-tools/module-init-tools-3.0-r2.ebuild?r1=1.13&r2=1.14 
 
The comment says  
"Our zlib.so is in /lib vs /usr/lib so it should be safe for us to link with 
just -lz ...", but the commit only removes 'filter-flags -fPIC' 

true, consulting KEYWORDS shows that we didnt disable the static stuff in the
stable version

i'll have to check with a few people to make sure 3.1 is safe for stable

all in all, not a big deal for module-init-tools/sash since they shouldnt be
exploitable in such a way to escalate privs

More trouble: 
There is the USE-flag 'static'. 
 
The following packages use this flag and depend on zlib: 
 
app-misc/zisofs-tools (DEPENDS on >=sys-libs/zlib-1.1.4) 
net-misc/openssh (DEPENDS on >=sys-libs/zlib-1.1.4) 
net-www/apache (DEPENDS on sys-libs/zlib) 
 
 
I also looked more into media-gfx/megapov 
 
This package is extended version of povray, which links dynamicly to libz.so.1 
/usr/bin/povray dynamicly linked (also to libz.so) and is ~1.2 
MB, /usr/bin/megapov is a static elf and ~3 MB. Clamscan says it contains a 
zlib and everything looks like this is true. 
(There is only megapov-1.0 in portage, on the website there are also versions 
1.1 and 1.2. All linux versions on the website are called 'compiled with static 
libraries') 
 
I also noted that the new media-video/ffmpeg-0.4.9_p20050226-r5.ebuild uses 
zlib and it builds static libpostproc.a . But this might be a false alarm, 
because clamscan does not detect a zlib in this file. 
 
This list of affected packages is probably still not complete. I only found the 
first three packages by setting USE=static and emerge -puD --newuse world. 
That I found the static elf of megapov also is only related to the fact that I 
have this package installed. There might still be more things like this out 
there, but I don't know how to scan for this. Nothing in the megapov ebuild 
points to the fact that it will be build static. 
Another thing are ebuilds like ffmpeg that build static parts. I discoverd the 
combination of partly static linking and using zlib only by pure luck. 

sash-3.7-r1 added with zlib-1.2.3 depend

Do we agree that of those, only dar may potentially be used on untrusted data ?
I don't think we should multiplicate GLSAs on unexploitable issues just because
they happen to contain affected zlib code...

Agreed -- module-init-tools needs root anyway (and I vote for no GLSA on it)...
dar seems to be a user utility though so that probably could do with a GLSA.

ppc, sparc: please test and mark app-backup/dar-2.2.2 stable

marked ppc stable

sparc stable.
maybe of interest to someone is that i had to use.mask dar32 & dar64 since they
caused a shiny bus error (the sparc equivalent of a segfault).
dunno if this affect any other arch since i didn't try.

module-init-tools still needs to be moved into stable

sash includes a -gunzip command, which could be used on untrusted data...

I would vote weak NO on glsa.

I tend to vote NO. 

I'd vote YES on dar and sash.

ok, if arches are ready, i'd suggest we move module-init-tools-3.1 to stable

security, make up your mind on GLSA need.

Recounting, that means GLSA for dar, no GLSA for the others. People that
disagree should explain/comment here before the GLSA goes out.

Mhh, hard one. I'd tend to say yes to dar or sash, but i also wouldn't mind if
we don't issue a GLSA for this at all.

-> GLSA on dar, no GLSA on thers.

I'm changing my vote on dar.
I don't feel confident sending this without more analysis. It's easy to issue
"DoS and maybe even code execution" for the servers or the library, but for
specific client utilities like dar you are left with the very slight possibility
of code execution in the specific heap structure of the tool, because there is
no "DoS" in this case.

So I feel we shouldn't issue a GLSA for code execution in dar without more
analysis to back up our claims. If you agree with me, close this one as FIXED...

I still agree -> Closing.