Date: Fri, 13 Aug 2010 01:02:39 -0400 From: jhell <jhell@dataix.net> To: Janne Snabb <snabb@epipe.com> Cc: freebsd-security@freebsd.org Subject: Re: ~/.login_conf mechanism is flawed Message-ID: <4C64D1EF.6030508@dataix.net> In-Reply-To: <alpine.BSF.2.00.1008121828360.96753@tiktik.epipe.com> References: <alpine.BSF.2.00.1008100841350.96753@tiktik.epipe.com> <alpine.BSF.2.00.1008101503190.96753@tiktik.epipe.com> <201008121302.o7CD2BJv044208@lava.sentex.ca> <alpine.BSF.2.00.1008121828360.96753@tiktik.epipe.com>
index | next in thread | previous in thread | raw e-mail
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,vhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C64D1EF.6030508>