FreeBSD Security Advisory FreeBSD-SA-06:26.gtar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-06:26.gtar Security Advisory The FreeBSD Project Topic: gtar name mangling symlink vulnerability Category: contrib Module: contrib_tar Announced: 2006-12-06 Credits:Teemu Salmela Affects:FreeBSD 4.x and 5.x releases Corrected: 2006-12-06 09:16:17 UTC (RELENG_5, 5.5-STABLE) 2006-12-06 09:16:41 UTC (RELENG_5_5, 5.5-RELEASE-p9) 2006-12-06 09:17:09 UTC (RELENG_4, 4.11-STABLE) 2006-12-06 09:18:02 UTC (RELENG_4_11, 4.11-RELEASE-p26) CVE Name: CVE-2006-6097 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.FreeBSD.org/. I. Background GNU tar (gtar) is a utility to create and extract tape archives, commonly known as tar files. GNU tar is included in FreeBSD 4.x as /usr/bin/tar, and in FreeBSD 5.x as /usr/bin/gtar. II. Problem Description Symlinks created using the GNUTYPE_NAMES tar extension can be absolute due to lack of proper sanity checks. III. Impact If an attacker can get a user to extract a specially crafted tar archive the attacker can overwrite arbitrary files with the permissions of the user running gtar. If file system permissions allow it, this may allow the attacker to overwrite important system file (if gtar is being run as root), or important user configuration files such as .tcshrc or .bashrc, which would allow the attacker to run arbitrary commands. IV. Workaround Use bsdtar, which is the default tar implementation in FreeBSD 5.3 and higher. For FreeBSD 4.x, bsdtar is available in the FreeBSD Ports Collection as ports/archivers/libarchive. V. Solution NOTE: The solution described below causes GNU tar to exit with an error when handling an archive with GNUTYPE_NAMES entries. The FreeBSD Security Team does not consider this to be a significant regression, since GNUTYPE_NAMES has not been used for many years and is not supported by other archival software such as libarchive(3); but the original (insecure) behaviour can be retained by running GNU tar with the newly added --allow-name-mangling option. Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE, or 5-STABLE, or to the RELENG_5_5 or RELENG_4_11 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.11 and 5.5 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-06:26/gtar.patch # fetch http://security.FreeBSD.org/patches/SA-06:26/gtar.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/gnu/usr.bin/tar # make obj make depend make make install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_4 src/contrib/tar/src/common.h1.2.2.2 src/contrib/tar/src/extract.c 1.4.2.4 src/contrib/tar/src/tar.c 1.2.2.3 RELENG_4_11 src/UPDATING 1.73.2.91.2.27 src/sys/conf/newvers.sh 1.44.2.39.2.30 src/contrib/tar/src/common.h 1.2.2.1.10.1 src/contrib/tar/src/extract.c 1.4.2.3.8.1 src/contrib/tar/src/tar.c 1.2.2.2.6.1 RELENG_5 src/contrib/tar/src/common.h 1.2.10.1 src/contrib/tar/src/extract.c 1.6.8.1 src/contrib/tar/src/tar.c 1.3.4.1 RELENG_5_5 src/UPDATING 1.342.2.35.2.9 src/sys/conf/newvers.sh 1.62.2.21.2.11 src/contrib/tar/src/common.h 1.2.22.1 src/contrib/tar/src/extract.c 1.6.20.1 src/contrib/tar/src/tar.c 1.3.16.1 - - VII. References http://marc.theaimsgroup.com/?l=full-disclosurem=116414883029517 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6097 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-06:26.gtar.asc -BEGIN PGP
Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
FreeBSD Security Advisories wrote: FreeBSD-SA-06:25.kmem Security Advisory The FreeBSD Project ... III. Impact A user in the operator group can read the contents of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way; for example, a terminal buffer might include a user-entered password. For what it's worth, there was a lot of debate about whether this deserved an advisory: Members of the operator group are allowed (by default, at least) to read raw disk devices, so being able to read kernel memory really isn't very much of a privilege escalation. In the end I decided to go ahead with this advisory largely because we were already planning on issuing an advisory this week (for a far more serious issue in GNU tar), but if a similar issue arises next month, we might decide not to bother with an advisory. I'd be interested to hear opinions from the FreeBSD community about whether this sort of issue is one which anyone really cares about. Colin Percival FreeBSD Security Officer ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
On Wednesday 06 December 2006 04:07, Colin Percival wrote: FreeBSD Security Advisories wrote: FreeBSD-SA-06:25.kmem Security Advisory The FreeBSD Project ... III. Impact A user in the operator group can read the contents of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way; for example, a terminal buffer might include a user-entered password. For what it's worth, there was a lot of debate about whether this deserved an advisory: Members of the operator group are allowed (by default, at least) to read raw disk devices, so being able to read kernel memory really isn't very much of a privilege escalation. In the end I decided to go ahead with this advisory largely because we were already planning on issuing an advisory this week (for a far more serious issue in GNU tar), but if a similar issue arises next month, we might decide not to bother with an advisory. I'd be interested to hear opinions from the FreeBSD community about whether this sort of issue is one which anyone really cares about. Colin Percival FreeBSD Security Officer Sure, and if you can read raw disk devices you can read /etc/master.passwd and /etc/groupand if you can do that then it's trivial to break the passwords you need to su to someone in wheel and then su to root. I guess my point is someone in the operator group has a far easier way to gain root than this vuln. It's great to fix bugs, but I bet this one won't prompt many people to apply the patches and/or rebuild world to fix. Damned if you do, damned if you don't. If you don't issue an SA then people mumble about how FBSD ignores security issues. If you do issue the SA then people mumble about how pointless this one was. My opinion is I'd rather know about it and make the decision myself whether to apply the fixes than not know about it at all. -- Thanks, Josh Paetzel ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
On Wed, Dec 06, 2006 at 02:43:03PM +0100, Ruben de Groot wrote: On Wed, Dec 06, 2006 at 06:26:31AM -0600, Josh Paetzel typed: On Wednesday 06 December 2006 04:07, Colin Percival wrote: FreeBSD Security Advisories wrote: FreeBSD-SA-06:25.kmem Security Advisory The FreeBSD Project ... III. Impact A user in the operator group can read the contents of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way; for example, a terminal buffer might include a user-entered password. For what it's worth, there was a lot of debate about whether this deserved an advisory: Members of the operator group are allowed (by default, at least) to read raw disk devices, so being able to read kernel memory really isn't very much of a privilege escalation. In the end I decided to go ahead with this advisory largely because we were already planning on issuing an advisory this week (for a far more serious issue in GNU tar), but if a similar issue arises next month, we might decide not to bother with an advisory. I'd be interested to hear opinions from the FreeBSD community about whether this sort of issue is one which anyone really cares about. Colin Percival FreeBSD Security Officer Sure, and if you can read raw disk devices you can read /etc/master.passwd and /etc/groupand if you can do that then it's trivial to break the passwords you need to su to someone in wheel and then su to root. I guess my point is someone in the operator group has a far easier way to gain root than this vuln. True, but only in the default configuration. The reading of raw disk devices really is controlled by filesystem privileges: # ls -l /dev/ad4 crw-r- 1 root operator0, 84 Dec 6 08:50 /dev/ad4 So you could for example remove the read bit for operators on some devices, while still allowing them to dump/backup some other specific devices. This isn't the case for kmem: # ls -l /dev/kmem crw-r- 1 root kmem0, 25 Dec 6 08:50 /dev/kmem In my opinion that makes this a bug and a security issue. Ehh... but from what I gather, the point of this security advisory is that users in the operator (not kmem) group can access the /dev/fwN and /dev/fwmemN devices, and thus do Bad Things(tm) to the kernel. S - the only in the default configuration qualification applies just as much to the FireWire devices as to the raw disk ones - both may be controlled by filesystem privileges. Unless I've really misunderstood what you were saying, of course :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence every third, but it still comprehensible. pgp26DZ4iWPgh.pgp Description: PGP signature
Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
Colin Percival napsal/wrote: A user in the operator group can read the contents of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way; for example, a terminal buffer might include a user-entered password. For what it's worth, there was a lot of debate about whether this deserved an advisory: Members of the operator group are allowed (by default, at least) to read raw disk devices, so being able to read kernel memory really isn't very much of a privilege escalation. Even if the user with (unwanted) access memory has the read access to raw disk device we can't assume that all private data presend in memory are present on disk also. Especially when swap disabled. Paranoid application allocate non-swappable memory to store critical data also. There may be in-memory decrypted data (password supplied by user) that are never present on disk in raw form. Also, the PAM allow to configure the computer to authenticate users without passwords in master.passwd - but the correct and usable password still can be found in memory during authentication phase. Unless we can safelly assume that an user can't use the bug to acces data that isn't accesible via other interface, then we found new data channel. If we founded a new data channel where it should not be, then we found a point of possible data leakage. If data leak to someone who should not have acces to it, we found the security bug. There - someone has unwanted access to memory. It's security bug. The fact the user has the regular read-only access to raw disk device is irelevant unless all data avaiable in memory are avaiable on disk also. I'd be interested to hear opinions from the FreeBSD community about whether this sort of issue is one which anyone really cares about. Despite the fact that this bug don't create real security violation on any system under my supervision, I would like to know all informations that *may* affect security of a system. Including those you are not sure they really affect security or not. I'm administrator of system, I'm responsible for it's security, I will make final decision. I will ignore those information that doesn't claim security problem on my systems (but it still may claim security problem on other's system). Informations doesn't hurt. The lack of information may hurt. Dan ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Security Advisory FreeBSD-SA-06:25.kmem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doesn't securelevel completely mitigate this even for root users anyway, if set? Setting securelevel denies raw access to disk devices and kmem in this way does it not? - -- Craig Edwards Dan Lukes wrote: Colin Percival napsal/wrote: A user in the operator group can read the contents of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way; for example, a terminal buffer might include a user-entered password. - -- OpenPGP Key ID: 0x49B959F7 Better to reign in Hell than to serve in Heaven -- Milton -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFdwdqCd57Ikm5WfcRAmx9AKDCtIqEj5lREwepRoFfcnMJNGwixQCfQ3WI c34CNp+R5Zsgl/PyE32Qr0c= =lRB+ -END PGP SIGNATURE- ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED]
