Re: basically security of linux
On 2009-01-16, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: --nextPart7126651.dTOK38xoNi Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 2009 January 16 04:13:10 Michael Loftis wrote: --On January 16, 2009 10:31:35 AM +0100 Andreas Matthus andreas.matt...@tu-dresden.de wrote: But since some days I mull over a question: What happens if a user run a selfcopy from a program with a security hole? I'm afraid he can get root-rights. Isn't it? In general, no. This requires an exploitable kernel bug. That said, there have been some of these in the past, and new ones will likely be discovered in the future, but that's far more rare. Anything you run as root should only ever come from trusted sources for this reason. What about hardlinking the suid-root binaries to a hidden location, waiting= =20 for a security hole to be found/fixed, and then running the old binary to=20 exploit the hole? Does dpkg handle suid/sgid files so that this is=20 prevented? dpkg does strip suid/sgid bits before removing the files - at least when I tested exactly that a year ago. /Sune -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
basically security of linux
Hallo, I manage a lot of debian servers and try to install often the updates. So I had in mind my systems are well prepaired. (I follow also other security rules ;-) ) But since some days I mull over a question: What happens if a user run a selfcopy from a program with a security hole? I'm afraid he can get root-rights. Isn't it? with regards Andreas Matthus smime.p7s Description: S/MIME Cryptographic Signature
Re: basically security of linux
--On January 16, 2009 10:31:35 AM +0100 Andreas Matthus andreas.matt...@tu-dresden.de wrote: Hallo, I manage a lot of debian servers and try to install often the updates. So I had in mind my systems are well prepaired. (I follow also other security rules ;-) ) But since some days I mull over a question: What happens if a user run a selfcopy from a program with a security hole? I'm afraid he can get root-rights. Isn't it? In general, no. This requires an exploitable kernel bug. That said, there have been some of these in the past, and new ones will likely be discovered in the future, but that's far more rare. Anything you run as root should only ever come from trusted sources for this reason. Windows is a different matter. There's so many ways to break local security on windows it's not funny. But with Linux, and any Unix in general, you can not arbitrarily escalate your privileges. The way applications like su, and sudo work is through the SetUID bit on their executable. What this does is causes the kernel to run the application as the user that owns the file - root in the case of su and sudo - this lets them elevate your privilege levels if you pass their access checks. That's why SetUID executables can be dangerous. You have to trust them. Very few programs are SetUID 0/root. Linux/UNIX was designed for running arbitrary programs by arbitrary users, and keeping them all separate from eachother, secure from eachother's malicious intent or accidents, provided you follow secure permissions on files and directories. root is the only user who has exceptions to this, root has the capability to read or write any file (I know i know guys there's SELinux and stuff like that for CAP management but we're talking the general case here). -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
Le Fri, 16 Jan 2009 10:31:35 +0100, Andreas Matthus andreas.matt...@tu-dresden.de a écrit : Hallo, I manage a lot of debian servers and try to install often the updates. So I had in mind my systems are well prepaired. (I follow also other security rules ;-) ) But since some days I mull over a question: What happens if a user run a selfcopy from a program with a security hole? I'm afraid he can get root-rights. Isn't it? with regards Andreas Matthus Hi, I'd say that except in the case of kernel bug, non-root users cannot get root rights with a non root running program... Regards Sébastien signature.asc Description: PGP signature
Re: basically security of linux
On Friday 2009 January 16 04:13:10 Michael Loftis wrote: --On January 16, 2009 10:31:35 AM +0100 Andreas Matthus andreas.matt...@tu-dresden.de wrote: But since some days I mull over a question: What happens if a user run a selfcopy from a program with a security hole? I'm afraid he can get root-rights. Isn't it? In general, no. This requires an exploitable kernel bug. That said, there have been some of these in the past, and new ones will likely be discovered in the future, but that's far more rare. Anything you run as root should only ever come from trusted sources for this reason. What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? Does dpkg handle suid/sgid files so that this is prevented? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: basically security of linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? IIRC, a hard link is the same file called two different names. If dpkg/apt change the file in one location (security update), the other one will be changed as well [1]... You'd have to *copy* the hard linked file, but that would still not allow you to copy it back later or to retain it's suid properties. Am I missing something? Johannes [1] http://en.wikipedia.org/wiki/Hard_link -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklw0fkACgkQC1NzPRl9qEXaKACfX8VfBxpZsSH7Lf0HAGC9JL4b 298AoIAqW+BtPtRZ6wZvT37t4zujq3a0 =rOKy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
On Friday 2009 January 16 12:29:13 Johannes Wiedersich wrote: Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? IIRC, a hard link is the same file called two different names. If dpkg/apt change the file in one location (security update), the other one will be changed as well [1]... True enough. However, if you unlink the old version before writing the new version, you have a problem. IIRC, GNU cp and GNU mv does the unlink/link rather than opening the destination with O_CREAT|O_TRUNC|O_WRITE. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: basically security of linux
--On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich johan...@physik.blm.tu-muenchen.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? This is why compromised systems can't be trusted ever again. Taht said, there are utilities and methods for finding rogue SUID binaries. Tripwire comes to mind, there are many others too. IIRC, a hard link is the same file called two different names. If dpkg/apt change the file in one location (security update), the other one will be changed as well [1]... That only holds true of edit-in-place. Something that most packaging systems do not do, the reason being is that with the way modern systems/kernels execute code, this would modify running code (They generally mmap the code, readonly, into the processes address space). FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use error. However, you can't create a hard link on a file you don't own, you can't do it across drives, and I don't think your hardlinked copy retains SUID bitsThe last bit I could be wrong though. You'd have to *copy* the hard linked file, but that would still not allow you to copy it back later or to retain it's suid properties. Am I missing something? Johannes [1] http://en.wikipedia.org/wiki/Hard_link -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklw0fkACgkQC1NzPRl9qEXaKACfX8VfBxpZsSH7Lf0HAGC9JL4b 298AoIAqW+BtPtRZ6wZvT37t4zujq3a0 =rOKy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? Does dpkg handle suid/sgid files so that this is prevented? Hi, Having /home, /tmp, (/usr)?/s?bin and /opt on different partitions is a solution. A normal user should not have the right to create a file outside /home or /tmp, and there should be no SUID file outside (/usr)?/s?bin or /opt. No hard-linking is possible across devices. François. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
On Friday 2009 January 16 14:45:44 Michael Loftis wrote: --On January 16, 2009 7:29:13 PM +0100 Johannes Wiedersich johan...@physik.blm.tu-muenchen.de wrote: Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? This is why compromised systems can't be trusted ever again. No need to compromise the system in the default partition layout. See below. Taht said, there are utilities and methods for finding rogue SUID binaries. Tripwire comes to mind, there are many others too. Yes, I know, but there could ways to mitigate the attack vector in the core system so that (this feature of) tripwire isn't needed. IIRC, a hard link is the same file called two different names. If dpkg/apt change the file in one location (security update), the other one will be changed as well [1]... That only holds true of edit-in-place. Something that most packaging systems do not do, the reason being is that with the way modern systems/kernels execute code, this would modify running code (They generally mmap the code, readonly, into the processes address space). Hrm, I didn't know you could patch running programs like this. I assumed that the kernels actively prevented this through COW or other methods. FreeBSD atleast IIRC prevents this, Text File Busy/Text File In Use error. However, you can't create a hard link on a file you don't own, Not true. You can create a hard link to any file as long as the new link is in directory to which you can write. you can't do it across drives, Right, but the default partitioning puts /sbin /usr/sbin etc. on the same filesystem as /home and /tmp, exposing the system to these attacks. and I don't think your hardlinked copy retains SUID bitsThe last bit I could be wrong though. Yes, it does. Permission bits are part of the file data (inodes), not part of the directory data (dirents) so the permissions/owner/group is the same on all (hard) links to a single file. Transcript from my system: $ sudo /bin/sh -c 'echo test file' root's password: $ ln file my_file $ ls -l *file -rw-r--r-- 2 root root 5 2009-01-16 14:54 file -rw-r--r-- 2 root root 5 2009-01-16 14:54 my_file $ ls -ld . drwxr-xr-x 99 bss users 5168 2009-01-16 14:54 . $ sudo /bin/sh -c 'echo test file' $ ls -l *file -rw-r--r-- 2 root root 0 2009-01-16 14:54 file -rw-r--r-- 2 root root 0 2009-01-16 14:54 my_file $ sudo chmod file $ ls -l *file -rwsrwsrwt 2 root root 0 2009-01-16 15:03 file -rwsrwsrwt 2 root root 0 2009-01-16 15:03 my_file -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: basically security of linux
Boyd Stephen Smith Jr. wrote: Did you mean this to go to the list? I've replied directly to you, but feel free to repost my mail or part thereof to the list if you believe the discussion could continue there. Sorry, my fault. On Friday 2009 January 16 13:03:53 you wrote: Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? Does dpkg handle suid/sgid files so that this is prevented? Against hard linking attacks, as You described, it is recommended to have user-writable directories (usually /home and /tmp) on separate filesystems (since hard linking only works within one filesystem). These filesystems should be mounted with nosuid and nodev options. Nosuid protects against exploiting of vulnerable suid/sgid binaries, while nodev denies access to probably exploitable kernel code (i.e. device drivers). The only remaining vulnerability is through an exploitable syscall. Also it is recommended to make use of noexec on filesystems containing data only (e.g. /var/log, /var/mail) and ro for filesystems containing application binaries (e.g. /usr). That makes it a bit inconvenient to upgrade applications, since you have to remount /usr with rw before and with ro after doing the upgrade. Is this documented somewhere? I can understand Debian not doing this partitioning by default, but it should be easily accessible to those that want to harden their systems. It would also be nice to see what no$feature/ro options Debian supports for various filesystems. Search for the Securing Debian Manual and see: http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2 This manual describes a lot of security improvements for Debian installation. You probably does not need them all, however, its a nice guide to Unix/Linux security. At least once, I had a nodev /home bite me. Of course, I really shouldn't be building chroots in home, but it was the filesystem with the most space at the time. The dpkg tool, and no other package manager, does not, can not, however, it is not intended to prevent hard linking of suid/sgid binaries. It certainly could mitigate the risk by intentionally writing zeros to the inode(s) containing removed suid binaries. This does not require raw-writing the disk or having non-working binaries for any period of time either. IIRC, Gentoo provided such a feature at some point. I could see dpkg handling it by hardlinking any suid binaries that are to be replaced or to be removed before doing a remove/upgrade/install normally and then writing zeros to the saved file before unlinking it. If broken binaries can be accepted for some period of time, they can simply be overwritten with zeros before the normal remove/upgrade/install process. On inode filesystems a file is removed when the link counter gets zero and the file is not open. When you open a file and unlink it, the file will be kept till it is open. To overwrite a file before it is upgraded is _very_ dangerous. What if the upgrade won't work? Then you probably lost your libc, or something? Therefore, the safe way for an upgrade is to create create the new file with an temporary name, and when it is ready, copy it with a single move operation over the original. Imagine the following. A server (e.g. apache or sshd) is running and using a certain library. The library is opened and is read from time to time. If you overwrite this file with zeros, your server crashes. If you let him use the obsolete library till its upgrade is finished, then force it to restart, the service can have a downtime of less than a second. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
On Friday 2009 January 16 15:49:46 Repasi Tibor wrote: Boyd Stephen Smith Jr. wrote: On Friday 2009 January 16 13:03:53 you wrote: Boyd Stephen Smith Jr. wrote: What about hardlinking the suid-root binaries to a hidden location, waiting for a security hole to be found/fixed, and then running the old binary to exploit the hole? Does dpkg handle suid/sgid files so that this is prevented? Against hard linking attacks, as You described, it is recommended to have user-writable directories (usually /home and /tmp) on separate filesystems (since hard linking only works within one filesystem). Is this documented somewhere? Search for the Securing Debian Manual and see: http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s3.2 Reading there and clicking through a bit I find this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225692 which indicates that dpkg does, in fact, take active steps to prevent the hardlinking attacks I described. That is good to know. It certainly could mitigate the risk by intentionally writing zeros to the inode(s) containing removed suid binaries. This does not require raw-writing the disk or having non-working binaries for any period of time either. I could see dpkg handling it by hardlinking any suid binaries that are to be replaced or to be removed before doing a remove/upgrade/install normally and then writing zeros to the saved file before unlinking it. If broken binaries can be accepted for some period of time, they can simply be overwritten with zeros before the normal remove/upgrade/install process. On inode filesystems a file is removed when the link counter gets zero and the file is not open. When you open a file and unlink it, the file will be kept till it is open. Okay, I know that, and I didn't suggest doing anything to a file that had 0 link count. To overwrite a file before it is upgraded is _very_ dangerous. What if the upgrade won't work? Then you probably lost your libc, or something? Therefore, the safe way for an upgrade is to create create the new file with an temporary name, and when it is ready, copy it with a single move operation over the original. Which is why my primary option had no period of time when the file at path /suid/binary/needed/by/upgrade_process had (a) bad content, (b) missing executable bit, or (c) missing suid bit. Turns out if I read just a little bit more, I wouldn't have wasted so much bandwidth. Sorry, guys. Big thanks to all the DDs that fix my problems before I think about them. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: basically security of linux
Hi, On Fri, Jan 16, 2009 at 03:13:10PM -0600, Boyd Stephen Smith Jr. wrote: On Friday 2009 January 16 14:45:44 Michael Loftis wrote: [hardlinking (suid binaries in hope a vulnerability will be found)] you can't do it across drives, Right, but the default partitioning puts /sbin /usr/sbin etc. on the same filesystem as /home and /tmp, exposing the system to these attacks. just an addition: Often I've seen /home as a separate mount (mounted nosuid,nodev,...) and /tmp as tmpfs, but then we have /var/tmp (which can't be tmpfs, because it's purpose is to retain the files even across reboots). I haven't tried it yet, but could a bind-mount be done (e. g. /var/real-tmp - /var/tmp) with additional options nosuid,nodev,... (while /var or / is mounted suid,dev,...)? Greetings, Mike Dornberger -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
On Friday 16 January 2009, Mike Dornberger mike.dornber...@gmx.de wrote about 'Re: basically security of linux': Hi, just an addition: Often I've seen /home as a separate mount (mounted nosuid,nodev,...) and /tmp as tmpfs, but then we have /var/tmp (which can't be tmpfs, because it's purpose is to retain the files even across reboots). I haven't tried it yet, but could a bind-mount be done (e. g. /var/real-tmp - /var/tmp) with additional options nosuid,nodev,... (while /var or / is mounted suid,dev,...)? I don't think bind mounts can change the effective permissions. If I mount -o bind,nodev /dev /mnt, mount shows the nodev option, but /proc/mounts doesn't and devices like /mnt/null and /mnt/zero work as expected. That said, you probably count mkdir /home/var with the right permissions and then mount -o bind /home/var /var/tmp to get what you are after. In any case, dpkg installed suid binaries do get scrubbed after they aren't in use, so you only have to worry about suid binaries you've created yourself. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ signature.asc Description: This is a digitally signed message part.
Re: basically security of linux
In article 20090117002104.ga...@wolfden.dnsalias.net you wrote: /tmp as tmpfs, but then we have /var/tmp (which can't be tmpfs, because it's purpose is to retain the files even across reboots). It is just supposed to hold larger data. No persistence in /var/tmp over reboots required. I haven't tried it yet, but could a bind-mount be done (e. g. /var/real-tmp - /var/tmp) with additional options nosuid,nodev,... (while /var or / is mounted suid,dev,...)? I am mounting /var as noexec, this works most of the time (dpkg has some problems on install. But since I also run with ro-root, i have a pre-install script which changes both mount options before I use apt). Gruss Bernd -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: basically security of linux
Bernd Eckenfels e...@lina.inka.de writes: In article 20090117002104.ga...@wolfden.dnsalias.net you wrote: /tmp as tmpfs, but then we have /var/tmp (which can't be tmpfs, because it's purpose is to retain the files even across reboots). It is just supposed to hold larger data. No persistence in /var/tmp over reboots required. FHS chapter 5 http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE: The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
