Bugzilla – Bug 117649
VUL-0: CVE-2005-4772: world writeable install cache directories?
Last modified: 2021-11-21 15:37:43 UTC
We recieved the following from bugtraq: Date: 16 Sep 2005 09:01:19 -0000 From: innate@gmx.de To: bugtraq@securityfocus.com Subject: worring about YaST in SuSE 9.3 and maybe lower author: l0om email: email:l0om | a7 | excluded d07 org page: www.excluded.org worring about YaST in SuSE 9.3 and maybe lower iam wondering about the installation routine from SuSE linux 9.3 and maybe some lower verisons. YaST is creating a directory named "/var/adm/YaST/InstSrcManager/IS_CACHE_0x0000000X/DATA/descr" which is worldwritable by default. the +directory contains data like packagenames and pathnames needed for YaST if you install software. for normal this directory shouldnt be +writable by everyone because if you change the install media a new "IS_CACHE_0x0000000X/DATA/descr" is created which isnt worldwritable. so you may be able to poising the data which is viewd by root while he is trying to install data. the following data may be changed for +example (file "packages"): ##---------------------------------------- =Pkg: 3ddiag 0.724 3 i586 +Req: /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/sh libc.so.6 libc.so.6(GLIBC_2.0) libhd.so.10 libsysfs.so.1 rpmlib(PayloadIsBzip2) <= 3.0.5-1 -Req: +Prq: /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadIsBzip2) <= 3.0.5-1 -Prq: +Prv: 3ddiag = 0.724-3 -Prv: =Grp: System/Base =Lic: GPL =Src: 3ddiag 0.724 3 src =Tim: 1111489970 =Loc: 1 3ddiag-0.724-3.i586.rpm =Siz: 28015 46735 +Aut: Stefan Dirsch <sndirsch@suse.de> -Aut: ##---------------------------------------- thats the information for one package. change the rpms path to somethin like "../../../" isnt possible cause its filterd. for sure you can simply prevent the admin installing new software with YaST if you destroy the "packages" file but i have noted somethin +else too. if you change the "=Loc" parameter e.g. to the following: =Loc: 1 AAAAAAAA["A"x515]AAA3ddiag-0.724-3.i586.rpm and the administrator is trying to install the package it will end in a Segmentation Fault that may be exploitable for an attacker. --- root:~# yast [trys to install some stuff] sbin/yast: line 207: 8447 Speicherzugriffsfehler (core dumped) $ybindir/y2base menu ncurses badass@linux:~> gdb /usr/lib/YaST2/bin/y2base core.8447 -q [...] Reading symbols from /usr/lib/libncursesw.so.5...done. Loaded symbols for /usr/lib/libncursesw.so.5 Reading symbols from /usr/lib/libpanelw.so.5...done. Loaded symbols for /usr/lib/libpanelw.so.5 Reading symbols from /usr/lib/YaST2/plugin/libpy2ag_system.so.2...done. Loaded symbols for /usr/lib/YaST2/plugin/libpy2ag_system.so.2 Reading symbols from /usr/lib/YaST2/plugin/libpy2ag_ini.so.2...done. Loaded symbols for /usr/lib/YaST2/plugin/libpy2ag_ini.so.2 Reading symbols from /usr/lib/YaST2/plugin/libpy2Pkg.so.2...done. Loaded symbols for /usr/lib/YaST2/plugin/libpy2Pkg.so.2 Reading symbols from /usr/lib/YaST2/plugin/libpy2ag_xml.so.2...done. Loaded symbols for /usr/lib/YaST2/plugin/libpy2ag_xml.so.2 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2...done. Loaded symbols for /usr/lib/YaST2/plugin/libpy2ag_hwprobe.so.2 Reading symbols from /lib/libhd.so.10...done. Loaded symbols for /lib/libhd.so.10 Reading symbols from /lib/libsysfs.so.1...done. Loaded symbols for /lib/libsysfs.so.1 Reading symbols from /usr/lib/libiw.so.28...done. Loaded symbols for /usr/lib/libiw.so.28 #0 0xffffe410 in ?? () (gdb) i r eax 0x1 1 ecx 0x4010d9e9 1074846185 edx 0x1 1 ebx 0x7 7 esp 0x4127c3a4 0x4127c3a4 ebp 0x4127c3d8 0x4127c3d8 esi 0x80ef104 135196932 edi 0x80ef0d8 135196888 eip 0xffffe410 0xffffe410 eflags 0x293 659 cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51
i was not able to confirm that on my machines.
Date: Sat, 17 Sep 2005 14:24:05 +0200 (MEST) From: Rene Fischer <Innate@gmx.de> To: Marcus Meissner <meissner@suse.de> Subject: Re: worring about YaST in SuSE 9.3 and maybe lower ich installierte SuSE mit hilfe von CDs. es erweckt den anschein, dass der erste IS_CACHE ordner, der bei der installation erstellt wird, das worldwritable problem hat. ich komme darauf, weil meine beiden arbeitskollegen, die ebenfalls mit dem system arbeiten, das selbe schema aufweisen. zum abschluss sei nochmal erwähnt, dass ich erst während der arbeit darauf aufmerksam wurde. hier an meinem heim pc finde ich nicht überrascht das gleiche: l0om@bad:~> ls -l /var/adm/YaST/InstSrcManager/IS_CACHE_0x0000000*/DATA/descr -d drwxrwxrwx 2 500 users 1992 2005-08-14 11:09 mfg, l0om
Date: Mon, 19 Sep 2005 08:55:49 +0200 (MEST) From: Innate@gmx.de To: Marcus Meissner <meissner@suse.de> Subject: FWD: Re: worring about YaST in SuSE 9.3 and maybe lower hi- ich habe gerade folgende mail erhalten: ---8<---snip---8<---snip---8<---snip---8<---snip---8<---snip---8<--- Guten Tag, Ich habe auf Deutsch schrieben vergisst so I won't butcher it further. I was passed your question to SuSE tech support regarding SuSE 9.3 directory /var/adm/YaST/InstSrcManager/IS_CACHE_0x00000001/DATA/descr. This install was done with the commercial version of SuSE 9.3 Professional available here in the U.S. via CDs. The permissions as determined by ls -l from the IS_CACHE_0x00000001 directory for DATA are drwxr-xr-x, owner root. For descr, dr-xr-xr-x and for files inside descr, all are -r--r--r--. So it certainly doesn't look like the world can write to my installation. I hope this has been useful to you, Ron Wagner ---8<---snip---8<---snip---8<---snip---8<---snip---8<---snip---8<--- möglicherweise steht das zugriffsproblem mit einer installation über nfs oder späterer hinzufügen von software über nfs in verbindung? mfg, l0om
Date: Mon, 19 Sep 2005 08:45:41 +0200 (MEST) From: Innate@gmx.de To: Marcus Meissner <meissner@suse.de> Subject: Re: worring about YaST in SuSE 9.3 and maybe lower hi marcus! > Wieso gehoert das denn 500:users ? > > Es sollte root:root gehoeren. das sehe ich auch so. nur leider ist das nicht der fall und so wie es aussieht, ist das kein chaotischer zufall, sondern ein fehler bei der installationsroutine. > Machmal: > df /var/adm/YaST/InstSrcManager/IS_CACHE_0x0000000*/DATA > > Evt ist die CD hart als User gemountet? > > mount|grep cd > okay: ls -ld /var/adm/YaST/InstSrcManager/IS_CACHE_0x0000000*/DATA/descr drwxrwxrwx 2 500 users 1952 2005-04-20 10:32 /var/adm/YaST/InstSrcManager/IS_CACHE_0x00000001/DATA/descr df /var/adm/YaST/InstSrcManager/IS_CACHE_0x0000000*/DATA/descr Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/hda2 15727132 3895124 11832008 25% / mount /dev/hda2 on / type reiserfs (rw,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda4 on /mount/daten type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true) /dev/hda1 on /windows/C type ntfs (rw,uid=1000,gid=100,umask=0002,utf8=true) usbfs on /proc/bus/usb type usbfs (rw) /dev/fd0 on /media/floppy type subfs (rw,nosuid,nodev,sync,fs=floppyfss,procuid) interessant ist jedenfalls, dass du anscheinend bei deinem rechner etwas anderes vorfindest. wie du siehst ist tatsächlich bei mir das verzeichniss beschreibbar und das ohne mein zutun (ehrenwort). wäre interessant zu wissen bei wem noch alles diese rechte zu finden sind. leider ist es so bei allen suse kisten die ich mir hier ansehen konnte. > Ciao, Marcus ciao, l0om
Created attachment 50272 [details] y2log.tar.gz y2logs from customer
hi marcus, ich habe hier mal die gewünschten dateien von nem arbeitskollegen gepackt. der hat das selbe problem, aber nicht so viel in den verzeichnissen rumgepfuscht wie ich :) ich hoffe das problem wird dadurch nun klarer- es müsste eigentlich ziemlich am anfang geschehen sein, denn er hat die erwähnten zugriffsrechte auch schon seid dem anfang. mfg, l0om
Caused by (liby2util)PathInfo::copy_dir which is used to copy the data from media into cache. copy_dir invokes 'cp -a'.
hi, ich finde auf der büchse folgendes vor: /store/install/os/suse93 # ls -ld cd1/ drwxrwxrwx 7 schmitz users 872 Apr 20 10:33 cd1/ /store/install/os/suse93 # id cschmitz uid=500(schmitz) gid=100(users) groups=100(users),14(uucp),16(dialout),17(audio),33(video),71(ntadmin),1000 (othe +rs) also liegt da der hund begraben? wieso behält das verzeichnis die zugriffsrechte der nfs partition? wird das mit den rechten rüberkopiert? mfg, l0om
Owner/permission bug fixed in STABLE liby2util-2.13.1. But I can't reproduce the SEGV.
Date: Mon, 19 Sep 2005 14:30:16 +0200 (MEST) From: Innate@gmx.de To: Marcus Meissner <meissner@suse.de> Subject: Re: Re: Re: worring about YaST in SuSE 9.3 and maybe lower hi, hier mal ein auszug aus der packages datei. der segfault kommt zustande, wenn der user veruscht das nss_ldap packet zu installieren: ##---------------------------------------- =Pkg: nss_ldap 234 3 i586 +Req: /sbin/ldconfig /sbin/ldconfig rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libdl.so.2 libgssapi_krb5.so.2 libgssapi_krb5.so.2(gssapi_krb5_2_MIT) liblber-2.2.so.7 libldap-2.2.so.7 libnsl.so.1 libresolv.so.2 libresolv.so.2(GLIBC_2.2) rpmlib(PayloadIsBzip2) <= 3.0.5-1 -Req: +Prq: /sbin/ldconfig /sbin/ldconfig rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadIsBzip2) <= 3.0.5-1 -Prq: +Prv: libnss_ldap.so.2 libnss_ldap.so.2(EXPORTED) libnss_ldap.so.2(nss_ldap.so) nss_ldap = 234-3 -Prv: =Grp: Productivity/Networking/LDAP/Clients =Lic: LGPL =Src: nss_ldap 234 3 src =Tim: 1111266785 =Loc: 1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnss_ldap-234-3.i586.rpm =Siz: 75135 200282 +Aut: Luke Howard <lukeh@padl.com> -Aut: ##---------------------------------------- strace: ... munmap(0x42384000, 4096) = 0 stat64 ("/var/adm/YaST/InstSrcManager/IS_CACHE_0x00000002/MEDIA/suse/i586/AAAAAAA +AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", 0xbfffbd0c) = -1 ENAMETOOLONG ... vor dem stat kommts da wohl beim zusammenbau des pfades zu einem speicherfehler. wobei der auszug da oben mit zu wenigen "A"s gefüllt war, um den segfault hervorzurufen. beim reproduzieren muss man darauf achten, dass man sich im richtigen IS_CACHE ordner befindet usw.- am besten mit strace mal checken, wo der sich die daten hergreift. mfg, l0om
That's the 'potential buffer overflow when assigning Pathnames' in liby2util. Fixed in July for SL 10.0.
'World writable cache' and 'buffer overflow when assigning Pathnames' are small fixes in liby2util. Probalely both should go into SLES9 SP3. Gerald: May I submit them?
since this could be definitely exploited by people gaining access to the infrastructure of either a SUSE mirror installserver (for the ftp versions) and/or third party package repositories, we should fix it for all affected distributions. meaning sles8, sles9, 9.0, 9.2 and 9.3. this does not need to wait for SP3 in this case.
SWAMPID: 2372
Yup, agreed.
Submitted fixes: 8.1/SLES8 liby2util-2.6.24 9.0 liby2util-2.8.17 9.1/SLES9 liby2util-2.9.27 9.2 liby2util-2.10.7 9.3 liby2util-2.11.7 10.0 liby2util-2.12.9 (not affected by buffer overflow, just fix disk cache permissions) STABLE (not affected at all)
updates approved.
i have commented on this in this weeks summary report.
postprocessed nm -DC output: New symbols: + T operator<<(std::basic_ostream<char, std::char_traits<char> >&, PathInfo::file_type) + T PathInfo::fileType() const + T PathInfo::readdir(std::list<PathInfo::direntry, std::allocator<PathInfo::direntry> >&, Pathname const&, bool, PathInfo::Mode) + T PathInfo::stat_mode::fileType() const + W std::_List_base<PathInfo::direntry, std::allocator<PathInfo::direntry> >::__clear() + W std::list<PathInfo::direntry, std::allocator<PathInfo::direntry> >::insert(std::_List_iterator<PathInfo::direntry, PathInfo::direntry&, PathInfo::direntry*>, PathInfo::direntry const&) + W std::vector<char const*, std::allocator<char const*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<char const**, std::vector<char const*, std::allocator<char const*> > >, char const* const&) Removed symbols: - T Vendor::Vendor(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
Created attachment 51766 [details] problemcause.patch this is the part of the diff between 9.1 GA and current that causes the problem
packages directly linking against liby2util.so.3 are: yast2-core yast2-debugger yast2-perl-bindings y2pmsh yast2-packagemanager
CAN-2005-3013
We need to upgrade: liby2util, liby2util-devel These cause updates for: yast2-packagemanager and yast2-core These two pull in their -devel headers yast2-packagemanager-devel and yast2-core-devel yast2-perl-bindings apparently does not need it. yast2-debugger does not need it either. But now for the real problem: yast2-packagemanager-devel got new requires: openssl-devel, curl-devel,openslp-devel These will break the system consistency.
updates released
the cp -a problem got a CVE id too: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4772 Yet another Setup Tool (YaST) in SUSE Linux before 20051007 preserves permissions and ownerships when copying a remote repository, which allows remote attackers to set weak permissions via a malicious repository server, possibly giving local users the ability to exploit CVE-2005-3013.
CVE-2005-4772: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N)