|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2005-4772: world writeable install cache directories? | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Marcus Meissner <meissner> |
| Component: | Incidents | Assignee: | Marcus Meissner <meissner> |
| Status: | RESOLVED FIXED | QA Contact: | Security Team bot <security-team> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aj, gp, hmuelle, ma, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | CVE-2005-4772: CVSS v2 Base Score: 6.4 (AV:N/AC:L/Au:N/C:P/I:P/A:N) | ||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
y2log.tar.gz
problemcause.patch |
||
|
Description
Marcus Meissner
2005-09-17 20:25:38 UTC
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) |