Re: services installed and running "out of the box"
Hi, On Wed, Sep 24, 2003 at 01:42:01PM -0700, Adam Lydick wrote: > Is there any effort to reduce the number of services running on a > default debian install? For example: a typical workstation user doesn't > really need to have inetd enabled, nor portmap (unless they are running > fam or nfs -- which isn't enabled by default) What about a package like the harden-* package, but one that conflicts with packages that are pointless for a client/desktop system? -- Ryan Underwood, , icq=10317253
Re: services installed and running "out of the box"
Hi, On Wed, Sep 24, 2003 at 01:42:01PM -0700, Adam Lydick wrote: > Is there any effort to reduce the number of services running on a > default debian install? For example: a typical workstation user doesn't > really need to have inetd enabled, nor portmap (unless they are running > fam or nfs -- which isn't enabled by default) What about a package like the harden-* package, but one that conflicts with packages that are pointless for a client/desktop system? -- Ryan Underwood, , icq=10317253 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
harden-* conflict with bad kernels?
Hi, harden-localflaws package conflicts with some kernel-image packages (needs to be updated for the <2.4.23 vulnerability) in order to ensure that they are removed. However, this can result in an unbootable system if they are inadvertently removed, and furthermore, does not solve the immediate problem of an insecure kernel in memory. (The vulnerability is not removed until the machine is rebooted with a new kernel.) Would it be a better idea to, instead of removing the bad kernel package through a Conflicts: , instead through postinst on install and each update, scan the system for bad kernel packages and tell the admin about them so he can take manual action about it? -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
better apt security with 3rd-party sites
Hi, I've often questioned the security of adding 3rd-party sites to my sources.list that are required for various non-free or other packages that aren't in Debian yet. Basically, I am putting the security of my system at the mercy of however secure their system happens to be, by allowing them to run arbitrary code as root on my system. Would it be a good idea to add a flag to an apt source somehow, that would be passed along to dpkg, to prevent any maintainer scripts from being run and prevent any executables being made setuid? This way, the user would be able to pick and choose what sites he trusts, rather than hoping on every apt-get update/upgrade that none of his 3rd-party sources have been rooted recently. There is no reason that most 3rd-party packages need to run maintainer scripts since the packages tend not to be very complex. Why give an attacker another easy vector? Note that I ignore trojaned binaries/libraries. The reason is that, without setuid, you would have to purposefully run these as root, hopefully knowing the consequences for doing so; there are warnings everywhere that you should not run untrusted code as root. Maintainer scripts, OTOH, are run with full root privileges nearly invisibly to the typical user and as a part of software installation. So simply installing software, not even running it, from a compromised source could get your machine rooted. I'm curious if anyone else has had any ideas for taking some of the implicit trust out of software installation from non-Debian sources. thanks, -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: better apt security with 3rd-party sites
On Mon, Jan 12, 2004 at 07:18:07PM +, Steve Kemp wrote: > > > Note that I ignore trojaned binaries/libraries. The reason is that, > > without setuid, you would have to purposefully run these as root, > > hopefully knowing the consequences for doing so; there are warnings > > everywhere that you should not run untrusted code as root. Maintainer > > scripts, OTOH, are run with full root privileges nearly invisibly to the > > typical user and as a part of software installation. So simply > > installing software, not even running it, from a compromised source > > could get your machine rooted. > > What about an evil script modifying an existing setuid binary? For > example /bin/login? > > To prevent against this type of attack you need aide/tripwire/etc. Hmm, along this line, what about forcing package installations to only install binary/library files somewhere else, like /usr/local, or maybe a /usr/untrusted. Or, can dpkg be given an alternate root altogether for installation? Something just makes me cringe when I see suggestions all over the web of "Debian users, just put into your /etc/apt/sources.list and apt-get install foo to install this software". Sure, maybe it's ok *now*, but what about 6 months later when you've forgotten all about it and you apt-get upgrade, and the site had been trojaned in the meantime? I mean, yeah, adding another apt source is super easy and lets all the dependencies be tracked automatically, but I'm not sure if the risks are laid out clearly enough to the user. Unfortunately, this is the best method in terms of convenience; otherwise the user has to download a bunch of .debs individually, hope they are matched, and dpkg -i *.deb which is considerably less convenient. Actually, it might be better if apt-get could use a source from the command line, instead of Dir::Etc::SourceList. # apt-get --source "deb http://."; update # apt-get --source "deb http://."; install foobar-client libfoo foobard Then that suggestion could be made by non-Debian package maintainers, instead of the (IMHO dangerous) suggestion of adding something to sources.list. We could even put a little box in synaptic "Install From Non-Debian Location" in which to paste the source line and the packages to install. That way the packages are installed now because you trust the site now, and you don't have to worry about the site being trojaned behind your back when you upgrade later. I think this is the method that should be suggested to new users; experienced people who know what sites they trust should also know how to add something to their sources.list for automatic upgrade tracking. thoughts? -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
[ [Dri-devel] XFree86 local root exploit]
This may or may not apply to any released packages, but various people have unofficial XFree86 4.3.x packages floating around that probably need to be fixed. - Forwarded message from Roland Scheidegger <[EMAIL PROTECTED]> - From: Roland Scheidegger <[EMAIL PROTECTED]> Date: Thu, 12 Feb 2004 13:44:09 +0100 Subject: [Dri-devel] XFree86 local root exploit To: DRI developer's list <[EMAIL PROTECTED]> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 There's a buffer overflow in XFree86 allowing local attackers to gain root privileges. Here's the patch, ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/fontfile.diff the advisory http://www.idefense.com/application/poi/display?id=72&type=vulnerabilities&flashstatus=false and a demo exploit also already has been published. I think it would be a good idea if someone could apply the patch to the dri cvs (applies with some fuzz and offset), if it is vulnerable. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel - End forwarded message - -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
harden-* conflict with bad kernels?
Hi, harden-localflaws package conflicts with some kernel-image packages (needs to be updated for the <2.4.23 vulnerability) in order to ensure that they are removed. However, this can result in an unbootable system if they are inadvertently removed, and furthermore, does not solve the immediate problem of an insecure kernel in memory. (The vulnerability is not removed until the machine is rebooted with a new kernel.) Would it be a better idea to, instead of removing the bad kernel package through a Conflicts: , instead through postinst on install and each update, scan the system for bad kernel packages and tell the admin about them so he can take manual action about it? -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
better apt security with 3rd-party sites
Hi, I've often questioned the security of adding 3rd-party sites to my sources.list that are required for various non-free or other packages that aren't in Debian yet. Basically, I am putting the security of my system at the mercy of however secure their system happens to be, by allowing them to run arbitrary code as root on my system. Would it be a good idea to add a flag to an apt source somehow, that would be passed along to dpkg, to prevent any maintainer scripts from being run and prevent any executables being made setuid? This way, the user would be able to pick and choose what sites he trusts, rather than hoping on every apt-get update/upgrade that none of his 3rd-party sources have been rooted recently. There is no reason that most 3rd-party packages need to run maintainer scripts since the packages tend not to be very complex. Why give an attacker another easy vector? Note that I ignore trojaned binaries/libraries. The reason is that, without setuid, you would have to purposefully run these as root, hopefully knowing the consequences for doing so; there are warnings everywhere that you should not run untrusted code as root. Maintainer scripts, OTOH, are run with full root privileges nearly invisibly to the typical user and as a part of software installation. So simply installing software, not even running it, from a compromised source could get your machine rooted. I'm curious if anyone else has had any ideas for taking some of the implicit trust out of software installation from non-Debian sources. thanks, -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: better apt security with 3rd-party sites
On Mon, Jan 12, 2004 at 07:18:07PM +, Steve Kemp wrote: > > > Note that I ignore trojaned binaries/libraries. The reason is that, > > without setuid, you would have to purposefully run these as root, > > hopefully knowing the consequences for doing so; there are warnings > > everywhere that you should not run untrusted code as root. Maintainer > > scripts, OTOH, are run with full root privileges nearly invisibly to the > > typical user and as a part of software installation. So simply > > installing software, not even running it, from a compromised source > > could get your machine rooted. > > What about an evil script modifying an existing setuid binary? For > example /bin/login? > > To prevent against this type of attack you need aide/tripwire/etc. Hmm, along this line, what about forcing package installations to only install binary/library files somewhere else, like /usr/local, or maybe a /usr/untrusted. Or, can dpkg be given an alternate root altogether for installation? Something just makes me cringe when I see suggestions all over the web of "Debian users, just put into your /etc/apt/sources.list and apt-get install foo to install this software". Sure, maybe it's ok *now*, but what about 6 months later when you've forgotten all about it and you apt-get upgrade, and the site had been trojaned in the meantime? I mean, yeah, adding another apt source is super easy and lets all the dependencies be tracked automatically, but I'm not sure if the risks are laid out clearly enough to the user. Unfortunately, this is the best method in terms of convenience; otherwise the user has to download a bunch of .debs individually, hope they are matched, and dpkg -i *.deb which is considerably less convenient. Actually, it might be better if apt-get could use a source from the command line, instead of Dir::Etc::SourceList. # apt-get --source "deb http://."; update # apt-get --source "deb http://."; install foobar-client libfoo foobard Then that suggestion could be made by non-Debian package maintainers, instead of the (IMHO dangerous) suggestion of adding something to sources.list. We could even put a little box in synaptic "Install From Non-Debian Location" in which to paste the source line and the packages to install. That way the packages are installed now because you trust the site now, and you don't have to worry about the site being trojaned behind your back when you upgrade later. I think this is the method that should be suggested to new users; experienced people who know what sites they trust should also know how to add something to their sources.list for automatic upgrade tracking. thoughts? -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
[ [Dri-devel] XFree86 local root exploit]
This may or may not apply to any released packages, but various people have unofficial XFree86 4.3.x packages floating around that probably need to be fixed. - Forwarded message from Roland Scheidegger <[EMAIL PROTECTED]> - From: Roland Scheidegger <[EMAIL PROTECTED]> Date: Thu, 12 Feb 2004 13:44:09 +0100 Subject: [Dri-devel] XFree86 local root exploit To: DRI developer's list User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 There's a buffer overflow in XFree86 allowing local attackers to gain root privileges. Here's the patch, ftp://ftp.xfree86.org/pub/XFree86/4.3.0/fixes/fontfile.diff the advisory http://www.idefense.com/application/poi/display?id=72&type=vulnerabilities&flashstatus=false and a demo exploit also already has been published. I think it would be a good idea if someone could apply the patch to the dri cvs (applies with some fuzz and offset), if it is vulnerable. Roland --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - End forwarded message - -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
