Re: goals for hardening Debian: ideas and help wanted
On Thu, Apr 24, 2014 at 11:45:46AM +0200, Giacomo Mulas wrote: On Thu, 24 Apr 2014, Paul Wise wrote: Would the inclusion of more AppArmor profiles be applicable? Thanks, added along with SELinux/etc. I second that. Actually, some time ago I tried using both AppArmor and SELinux, but gave up because it took forever to find legitimate behaviour of all kinds of common packages (most of them standard debian packages) and prepare configuration files for things to work. If debian wants to foster adoption of such security enhancements, it must go to great lengths in making sure that (in order of importance in my humble opinion) 1) all debian-packaged software works (very nearly) out of the box with debian-supported MAC frameworks. It should be very clear that if they don't it's an important bug that needs fixing. For example, such bugs should prevent the inclusion of a package in an official stable release. Or split the main debian archive in two, one that is MAC-ready and one that is not, so each user can decide to only use packages known to work well with debian-supported MAC frameworks. The apparmor policies in Debian apply a principle of minimal harm, confining only those services for which someone has taken the time to verify the correct profile. There are obviously pros and cons to each approach to MAC, which I'm not interested in arguing about; but one of the pros of the approach taken for apparmor is that all software *does* continue to work out of the box. If you found it otherwise, I think you should be filing a bug report against apparmor. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Why is su preserving the environment?
On Sat, Jan 24, 2009 at 08:41:37AM +0100, Josselin Mouette wrote: it has been brought to my attention (through #512803) that su does not clean the environment at all. This has several security implications: * variables like PERL5LIB or GTK_MODULES can be passed to another user, leading to unwanted execution of code; * variables like DBUS_SESSION_BUS_ADDRESS or XDG_SESSION_COOKIE export authentication information that could be used to obtain private information such as passwords in gnome-keyring. Before I work around this specific issue in the fugliest way, shouldn’t we prevent su from preserving the environment? There have been several security advisories related to sudo not cleaning the environment, and the final call has been to make env_reset the default. Is there any reason why su should not be considered vulnerable the same way? Because su does not attempt to control what commands are being run; if you can su to another user, you can run arbitrary commands as that user, which means there's no sense in trying to filter the environment. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#311772: Fwd: Password leaks are security holes
On Thu, Aug 28, 2008 at 09:36:41AM +0200, Giacomo A. Catenazzi wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, Then there is a bug in another package if this is what should be, because /var/log/auth.log is readable by group adm on all my systems. Anyway root already has the capability to view passwords (i.e. by installing alternate login programs, sniffing tty, ...) If the system uses MAC such as SELinux, this is not necessarily the case. We should design for such future technologies, and not expose passwords unnecessarily. On Thu, Aug 28, 2008 at 01:05:19PM +0200, Johan Walles wrote: auth.log was invented for this reason, and separated to standard log: it should be readable only by root, because users do errors. It's readable by anybody with physical access to the hardware. The logging we're talking about takes place in pam_unix. The normal password store for pam_unix is /etc/shadow, which is on the hard drive; if the user has physical access, they can run a password cracker against this file anyway and try to grab *all* user passwords, not just those of users who don't read before they type. (It's true that the passwords are not in /etc/shadow for systems using pam_unix together with NIS or NIS+, but I consider both NIS and NIS+ rather uninteresting cases.) So auth.log should log usernames, so that users don't do wrong assumption that password are not accessible by root! I can see a point in logging *valid* usernames. Logging invalid usernames (which aren't unlikely to actually be passwords) is a security risk. It provides information about username brute force attacks and other issues of concern to admins. On Thu, Aug 28, 2008 at 11:55:49AM +0200, Nico Golde wrote: Maybe this is the case but that's why this file is only readable for root and the adm group. So if an attacker is able to read this file you have way more problems as he wouldn't need to check the auth log for user errors but could just trace the login process, crack shadow, write a custom pam module or something similar to get your login credentials. No, that's not true. The only added permission the 'adm' group has on Debian is to be able to read log files; so this *does* expose passwords to users who wouldn't otherwise be able to get at them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1266-1] New gnupg packages fix signature forgery
On Wed, Mar 14, 2007 at 11:43:40AM +0100, Frank Küster wrote: Moritz Muehlenhoff [EMAIL PROTECTED] wrote: For the upcoming stable distribution (etch) these problems have been fixed in version 1.4.6-2. However, etch still has 1.4.6-1, and no freeze exception has been requested. But it has been granted. $ grep-excuses gnupg gnupg (1.4.6-1 to 1.4.6-2) Maintainer: James Troup Too young, only 1 of 5 days old Ignoring request to block package by freeze, due to unblock request by he Not considered $ We don't expect maintainers to request unblocks for RC bugfixes (in fact, I prefer they don't, it's just extra mail to reply to). I'm not sure about the policy for security updates in etch, but it doesn't seem proper to announce the availability in a DSA if it's not yet true... Hopefully, the fact that the security team made this statement means they were aware 1.4.6-2 was a candidate for inclusion in etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian security archive/updates b0rken???
On Sun, Jun 19, 2005 at 12:31:23AM -0400, sean finney wrote: please excuse this blatant cross-posting, i wouldn't do it if i didn't think it were critical that i do so... http://www.infodrom.org/~joey/log/?200506142140 say it isn't so! It isn't so. It's true that the design of sbuild/wanna-build means there were no autobuilders available for stable-security at the moment of sarge's release, but there was already work in progress to fix this by the time that blog entry was posted, and the claim that it looks like we'll be without security updates for quite a while caused no small amount of consternation. TTBOMK, there is now again a full complement of stable-security autobuilders available on 11 archs, and autobuilders for testing-security on 10/11 archs. It doesn't look like the security team has issued any DSAs since then, though they may have done uploads that haven't yet been published (I wouldn't know, not having access to look on klecker). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please allow drupal 4.5.3-1
On Fri, Jun 03, 2005 at 08:19:22AM +0200, Martin Schulze wrote: Steve Langasek wrote: On Wed, Jun 01, 2005 at 07:16:00PM -0700, Ian Eure wrote: On Wednesday 01 June 2005 04:54 pm, Hilko Bengen wrote: Just a few hours ago, the Drupal project has released version 4.5.3, a bugfix release which fixes a serious security bug. I have created and just uploaded a 4.5.3-1 package to unstable. Updated Debconf translations are the only additional changes over 4.5.2-3 which is the version in sarge. Any reason why you can't just apply the patch to fix that specific bug? And you probably want to be emailing the release team... He did contact the release team; unfortunately, the diff between 4.5.2 and 4.5.3 is rather large and I don't believe it's all security-related, so I think this will have to be left for the security team after all. Umh, the release team most probably has even stricter rules than the ^^^ security, I guess :) release team when it comes to cluttering the diff... Absolutely -- but the release team has a deadline before which the fix must be in unstable in order for it to be included in sarge (and if everything goes according to plan, this deadline is in 12 hours), whereas you can take as much time as you want to going back and forth with the maintainer until he gets it right. :) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Please allow drupal 4.5.3-1
On Wed, Jun 01, 2005 at 07:16:00PM -0700, Ian Eure wrote: On Wednesday 01 June 2005 04:54 pm, Hilko Bengen wrote: Just a few hours ago, the Drupal project has released version 4.5.3, a bugfix release which fixes a serious security bug. I have created and just uploaded a 4.5.3-1 package to unstable. Updated Debconf translations are the only additional changes over 4.5.2-3 which is the version in sarge. Any reason why you can't just apply the patch to fix that specific bug? And you probably want to be emailing the release team... He did contact the release team; unfortunately, the diff between 4.5.2 and 4.5.3 is rather large and I don't believe it's all security-related, so I think this will have to be left for the security team after all. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Security issue with 'elog' package
On Wed, May 04, 2005 at 12:15:15AM +0300, Recai Oktas wrote: I uploaded the new upstream of Elog a few days ago (this is a sponsored package). I've just noticed a possible security flaw which affects both versions in testing (2.5.7+r1558) and unstable (2.5.8+r1637), as can be seen in the following CVS log of r1.638: http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c Since the fix[1] is so trivial to backport, I can easily prepare a new package for just the version in testing. Please do so, unless you can point us to a release-critical bug addressed by the version currently in unstable. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: zip sarge's package vulnerable to CAN-2004-1010
On Fri, Nov 26, 2004 at 05:21:03PM -0200, Otavio Salvador wrote: Current CAN-2004-1010 was fixed on zip 2.30-8 but current sarge version still vulnerable. This package need to be included on sarge to solve it. It already has been. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Proposal for new Security subsection for non-US
On Sun, Jun 23, 2002 at 01:25:56PM -0300, Peter Cordes wrote: On Sun, Jun 23, 2002 at 12:46:27AM +0300, Pavel Minev Penev wrote: I would think of using xdelta, or similar to distrubute changes as binary patches, since there could be a real server overload when a few hundred administrators and mere people start downloading the brand new deifinitions simultaneously. What about a public rsync? Maybe a usual announce mailing list? In my oppinion, a package created ten minutes ago can't go into stable. Even if it is a simple virus/worm/blacklist/... definion. Bugs can crawl anywhere. Therefore, I don't think the proposed type of packages can ever be a part of stable. I guess it should be like: use unstable for just those packages, and stable for all the rest. Well, woody will be the first stable release to support pinning, and this looks like an excellent application for it. Still, unless you can put rsync:// URLs in sources.list, it won't solve everything. rsync or something similar would save a lot of traffic for this kind of thing. Unfortunately, it's probably too late to integrate rsync into the whole apt system, so it can rsync stuff in /var/cache/apt/archives. First thing's first: we need to have people regularly updating these data packages before we should worry about whether we have the resources to distribute them effectively. Though rsync might make things nicer for end-users on low-speed connections, I think it'll be a long time before this archive will come anywhere near the bandwidth requirements for even a single site that publically mirrors unstable or testing. Steve Langasek postmodern programmer pgpifHR7aTEMk.pgp Description: PGP signature
Re: Proposal for new Security subsection for non-US
Hello Matthew, I'm glad to see others thinking along the same lines. However, precisely because of the nature of the issues surrounding such packages -- the need for frequent updates even when running stable, the fact that this data should *not* be shipped on CDs, the relatively small mirror requirements -- I believe such a repository for definition files could thrive outside of the main Debian archive network. I'm also rather confident that, at least initially, it will be a lot *easier* to implement this outside of the main Debian archive network. Debian is effective at a lot of things, but when you start talking about IDS updates, you really want something a little more flexible and a little less process-laden. ;) On Sat, Jun 22, 2002 at 03:55:46PM +1200, Matthew Grant wrote: o Updating vulnerability databases does not work as generally the new data on the 'Net is no longer compatible with the binaries in stable. o New versions have new detection algorithms, capabilities, and methodologies that are needed to deal with current and serious threats. I would hesitate to endorse providing Debian packages for such security software if the binaries themselves really need to be updated that frequently. Where binaries can be provided and managed through the normal unstable-testing-stable system -- complete with security updates from our world-class security team -- I think having asynchronous updates to definiton files is a great boon; but where the programs have to be updated frequently to remain useful, I would argue that the software is simply not mature enough to receive the Debian seal of approval at all. Thus, the responsibilities of the maintainers of such an archive would not be to backport the software to stable, but to backport the definition files to stable. o It is placed in non-US, as the security scanning software uses encryption in lots of places. Though I disagree as noted with the premise of providing actual software this way, I'm curious what security scanning software has crypto dependencies? o We would leave out potato, and start with woody for this section as woody is very close to release. Definitely agreed on that one. All of the above combine to make the packages in stable a security risk if depended on for a site's security, even though they do not make the machine running the software insecure. Bit rot in this type of software (IDS tools, Vulnerability scanners, Virus scanners) is in fact a great cause for concern about security. I would even suggest that once such software and signature data is out of date, this be logged as a security bug. Incidentally, in addition to virus signatures, vulnerability scanners, and IDS definitions, I also nominate spam signatures (spamassassin) for inclusion in such an archive. I am putting this proposal forward for someone else to run with. I have a lot of commitments to the Linux Aid Server project (http://www.anathoth.gen.nz) and I have found that I have had to devote lots of time to getting e-mail virus scanning up to snuff under Debian for this project. Hence my interest in this to help Debian puul its socks up with regard to this sort of software. I think it shouldn't be /too/ hard to find other developers interested in working on this... Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for new Security subsection for non-US
On Sat, Jun 22, 2002 at 06:24:39PM +1200, Nick Phillips wrote: On Sat, Jun 22, 2002 at 12:21:12AM -0500, Steve Langasek wrote: I think it shouldn't be /too/ hard to find other developers interested in working on this... For example, I intend in the near-ish future to make up-to-date mailscanner .debs available whether or not any other bunch of packages does similarly As to whether or not I'll have time to help with such a coordinated effort, I'm really not sure. Depends on how the job thing goes in the next couple of months. If others are willing to work on individual packages for such tools, I can at least work on setting up a centralized archive for the packages -- either in my homedir on one of the Debian machines, or on a server here at work. Steve Langasek postmodern programmer pgptqjUItUDyC.pgp Description: PGP signature
Re: FIX: Chunk fix for Apache 1.3.24 i386 .deb + source .dsc and .diff.gz available.
Hello Matthew, I'm a little confused as to why you're cc:ing me on these messages? Steve Langasek postmodern programmer On Thu, Jun 20, 2002 at 08:20:56PM +1200, Matthew Grant wrote: Source and an i386 .deb are now up on: http://people.debian.org/~grantma MD5sums: $ md5sum apache_1.3.24-3.0.anathoth.1* 2694e435fcc5a8197d4942d38a651b43 apache_1.3.24-3.0.anathoth.1.diff.gz b84b0f106079ab7f66f40d135f5ed3f9 apache_1.3.24-3.0.anathoth.1.dsc 561f18885c58b8302d3039accea8e8bf apache_1.3.24-3.0.anathoth.1_i386.changes 5b0cf3f2a12b36063c7c19c8adbc450a apache_1.3.24-3.0.anathoth.1_i386.deb Here is a rehashed version of the patch cert_vucert944335 chunk fix patch used in apache_1.3.9-14.1 for potato which works for apache in woody and sid. The only thing stopping it was a comment about EBCDIC! Got to go - test this thing on s390 as well! Uploading .debs to fix apache chunk size stuff for i386 on woody and sid NOW! Source .dsc and .diff is there if others want to build for other architectures. The i386 .deb works on my home system. Did not know how to do NMU with new security system, or someone else can look after it. Matthew? Steve? Best Regards, Matthew Grant pgpYt8q6Mk6wc.pgp Description: PGP signature
Re: [SECURITY] [DSA 122-1] New zlib other packages fix buffer overflow
On Mon, Mar 11, 2002 at 05:16:43PM -0600, Jor-el wrote: On Mon, 11 Mar 2002, Michael Stone wrote: -BEGIN PGP SIGNED MESSAGE- - -- Debian Security Advisory DSA 122-1 [EMAIL PROTECTED] http://www.debian.org/security/ Michael Stone March 11th, 2002 - -- Package: zlib, various Vulnerability : malloc error (double free) Problem-Type : potential remote root Debian-specific: no The compression library zlib has a flaw in which it attempts to free memory more than once under certain conditions. This can possibly be exploited to run arbitrary code in a program that includes zlib. If a network application running as root is linked to zlib, this could potentially lead to a remote root compromise. No exploits are known at this time. This vulnerability is assigned the CVE candidate name of CAN-2002-0059. The zlib vulnerability is fixed in the Debian zlib package version 1.1.3-5.1. A number of programs either link statically to zlib or include a private copy of zlib code. These programs must also be upgraded to eliminate the zlib vulnerability. The affected packages and fixed versions follow: amaya 2.4-1potato1 dictd 1.4.9-9potato1 erlang 49.1-10.1 freeamp 2.0.6-2.1 mirrordir 0.10.48-2.1 ppp 2.3.11-1.5 rsync 2.3.2-1.6 vrweb 1.5-5.1 Hi, Doesnt dpkg also compile with a static zlib? Why does it not make this list? What Internet-accessible port are you running dpkg on? :) dpkg doesn't normally run on a network port, so exploiting it doesn't get you local access unless you already have it; and it's not suid, so running it from commandline doesn't let you get root. Therefore, there is no security hole opened by a vulnerability in dpkg. Steve Langasek postmodern programmer msg05937/pgp0.pgp Description: PGP signature
Re: [SECURITY] [DSA 122-1] New zlib other packages fix buffer overflow
On Tue, Mar 12, 2002 at 05:18:34PM +1300, John Morton wrote: On Tuesday 12 March 2002 15:52, Steve Langasek wrote: Doesnt dpkg also compile with a static zlib? Why does it not make this list? What Internet-accessible port are you running dpkg on? :) dpkg doesn't normally run on a network port, so exploiting it doesn't get you local access unless you already have it; and it's not suid, so running it from commandline doesn't let you get root. Therefore, there is no security hole opened by a vulnerability in dpkg. I think this reasoning is flawed - a vulnerable zlib in dpkg would be exploited by a trojaned deb package that someone unwittingly downloads, and as dpkg tends to be run as root, that would buy the attacker root privilages. Admittedly, as things stand, a trojaned package could do many of those things with doctored install scripts anyway, but this vulnerability does matter if the package has to be uncompressed just to examine it. True. Regardless of how much of a risk this really is, one of the dpkg maintainers has indicated that a fixed package is on its way. Regards, Steve Langasek postmodern programmer msg05941/pgp0.pgp Description: PGP signature
Re: [SECURITY] [DSA 122-1] New zlib other packages fix buffer overflow
On Tue, Mar 12, 2002 at 05:18:34PM +1300, John Morton wrote: On Tuesday 12 March 2002 15:52, Steve Langasek wrote: Doesnt dpkg also compile with a static zlib? Why does it not make this list? What Internet-accessible port are you running dpkg on? :) dpkg doesn't normally run on a network port, so exploiting it doesn't get you local access unless you already have it; and it's not suid, so running it from commandline doesn't let you get root. Therefore, there is no security hole opened by a vulnerability in dpkg. I think this reasoning is flawed - a vulnerable zlib in dpkg would be exploited by a trojaned deb package that someone unwittingly downloads, and as dpkg tends to be run as root, that would buy the attacker root privilages. Admittedly, as things stand, a trojaned package could do many of those things with doctored install scripts anyway, but this vulnerability does matter if the package has to be uncompressed just to examine it. True. Regardless of how much of a risk this really is, one of the dpkg maintainers has indicated that a fixed package is on its way. Regards, Steve Langasek postmodern programmer pgpbeqMESABzt.pgp Description: PGP signature
