From owner-freebsd-security@FreeBSD.ORG Fri Aug 13 05:34:16 2010 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA8A71065694 for ; Fri, 13 Aug 2010 05:34:16 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B16A8FC14 for ; Fri, 13 Aug 2010 05:34:16 +0000 (UTC) Received: by gwj23 with SMTP id 23so939975gwj.13 for ; Thu, 12 Aug 2010 22:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9t/3mbIGbvXxJUJVC2AG+dajfRrG+4NW8hXEUGLXr/E=; b=tv8ZAPy8z/15CeKE5Gimw8X0KD4XG0SMcxgHEXIvJiqWMBfHIB5ZArLkre8VPC2eB7 D/vysqOwqCl0yF5OSTo3HAyA8RRw7coxl4AK0XqLcaSTUeUu0wwLc8K3EL8jC9eEOLJr nG8V/O9yt5KUhL77v15pQiz31+I0UtiWjhCck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gpkQnnpnwYzCi+Av3XAl7Y+mSTzqw5fJrGzoUrLt7ntaPLobIIiHemSR6THxiQ15AL mCU9J3zSxoqK6iTNszz7KGt9FLdHqHzWL0HVViDzvANWd2mTOgNe1FjJ+9XlrX8gF9AQ 4DRWIC98uMEyyOdYTLt4pekvcu2VSqMIJhkkc= Received: by 10.100.119.14 with SMTP id r14mr1247998anc.156.1281675762939; Thu, 12 Aug 2010 22:02:42 -0700 (PDT) Received: from centel.dataix.local ([99.19.46.227]) by mx.google.com with ESMTPS id c6sm3533839anj.31.2010.08.12.22.02.40 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Aug 2010 22:02:41 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C64D1EF.6030508@dataix.net> Date: Fri, 13 Aug 2010 01:02:39 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Janne Snabb References: <201008121302.o7CD2BJv044208@lava.sentex.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-security@freebsd.org Subject: Re: ~/.login_conf mechanism is flawed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 05:34:16 -0000 On 08/12/2010 15:01, Janne Snabb wrote: > On Thu, 12 Aug 2010, Mike Tancsa wrote: > >> Are there any other tricks / work around people have implemented ? MACs ? > > Binary patch libutil: > > 1. cd /lib > > 2. perl -pi.bak -e 's!\.login_conf!../.noexist!;' libutil.so.* > > 3. /etc/rc.d/sshd restart ; /etc/rc.d/ftpd restart > > The above binary patch makes the login procedure to look for a file > called ".noexist" one level up from the user's home directory. If > that directory is not writable by the user (as is typically), the > patch will protect you from the potential vulnerability (by disabling > user-specific capabilities processing). > > (Yes, you can use perl regular expressions to do binary patches. > They do not seem to break anything in the binary data. I have been > doing similar things for years. sed is not robust for this purpose. > Obviously you will break everything if the replacement string is > not of the same length as the original.) > > I was looking at the lib/libc/db code today for some time. valgrind > reports several out-of-allocated-space accesses when db functions > are given a malicious .db file (__getbuf_crash_suspicious.db from > HI-TECH's mail attachment for example). The code is somewhat > complicated to understand, as I am not familiar with it, thus no > real solution (from me at least). > > -- > Janne Snabb / EPIPE Communications > snabb@epipe.com - http://epipe.com/ Very nice and easy way to patch & a great suggestion. On the note of using a ~/.login_conf file for setting limits and in this case increasing them. when they shouldn't be. I have been using a ~/.login_conf without generating the ~/.login_conf.db through the use of cap_mkdb(1) for quite some time. So on that, is it really necessary to look for that .db file at all since ~/.login_conf works without it... Regards, -- jhell,v