Summary: | app-backup/dar, sys-apps/module-init-tools, app-shells/sash contain static zlib | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Torsten Kaiser <Storklerk> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.enyo.de/fw/security/zlib-fingerprint/ | ||
Whiteboard: | B2? [noglsa] | ||
Package list: | Runtime testing required: | --- |
Description
Torsten Kaiser
2005-07-29 03:21:44 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. 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. |