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.