Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 100683 - app-backup/dar, sys-apps/module-init-tools, app-shells/sash contain static zlib
Summary: app-backup/dar, sys-apps/module-init-tools, app-shells/sash contain static zlib
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://www.enyo.de/fw/security/zlib-f...
Whiteboard: B2? [noglsa]
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-29 03:21 UTC by Torsten Kaiser
Modified: 2005-08-27 01:29 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Kaiser 2005-07-29 03:21:44 UTC
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.
Comment 1 Tim Yamin (RETIRED) gentoo-dev 2005-07-29 03:37:38 UTC
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.
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-07-29 06:14:38 UTC
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)
Comment 3 SpanKY gentoo-dev 2005-07-29 07:44:22 UTC
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
Comment 4 Torsten Kaiser 2005-07-29 08:07:53 UTC
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. 
Comment 5 SpanKY gentoo-dev 2005-07-29 08:33:32 UTC
you cant just read the configure script

consult the ebuild where we purposefully disable static zlib linking
Comment 6 Torsten Kaiser 2005-07-29 08:48:42 UTC
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' 
Comment 7 SpanKY gentoo-dev 2005-07-29 10:41:53 UTC
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
Comment 8 Torsten Kaiser 2005-07-29 12:03:54 UTC
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. 
Comment 9 SpanKY gentoo-dev 2005-07-29 23:14:54 UTC
sash-3.7-r1 added with zlib-1.2.3 depend
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2005-07-30 01:55:42 UTC
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...
Comment 11 Tim Yamin (RETIRED) gentoo-dev 2005-07-30 03:57:01 UTC
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.
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2005-07-30 04:47:51 UTC
ppc, sparc: please test and mark app-backup/dar-2.2.2 stable
Comment 13 Tobias Scherbaum (RETIRED) gentoo-dev 2005-07-30 09:16:09 UTC
marked ppc stable
Comment 14 Gustavo Zacarias (RETIRED) gentoo-dev 2005-08-01 08:17:18 UTC
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.
Comment 15 SpanKY gentoo-dev 2005-08-01 08:58:54 UTC
module-init-tools still needs to be moved into stable
Comment 16 Tavis Ormandy (RETIRED) gentoo-dev 2005-08-05 00:40:02 UTC
sash includes a -gunzip command, which could be used on untrusted data...

I would vote weak NO on glsa.
Comment 17 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-08-05 01:12:00 UTC
I tend to vote NO. 
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2005-08-08 10:34:59 UTC
I'd vote YES on dar and sash.
Comment 19 SpanKY gentoo-dev 2005-08-18 15:34:40 UTC
ok, if arches are ready, i'd suggest we move module-init-tools-3.1 to stable
Comment 20 Thierry Carrez (RETIRED) gentoo-dev 2005-08-21 08:49:33 UTC
security, make up your mind on GLSA need.
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2005-08-24 07:02:14 UTC
Recounting, that means GLSA for dar, no GLSA for the others. People that
disagree should explain/comment here before the GLSA goes out.
Comment 22 Stefan Cornelius (RETIRED) gentoo-dev 2005-08-24 07:07:33 UTC
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.
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2005-08-24 07:21:42 UTC
-> GLSA on dar, no GLSA on thers.
Comment 24 Thierry Carrez (RETIRED) gentoo-dev 2005-08-26 08:18:09 UTC
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...
Comment 25 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-08-27 01:29:38 UTC
I still agree -> Closing.