Date: Thu, 12 Aug 2010 19:01:38 +0000 (UTC) From: Janne Snabb <snabb@epipe.com> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-security@freebsd.org Subject: Re: ~/.login_conf mechanism is flawed Message-ID: <alpine.BSF.2.00.1008121828360.96753@tiktik.epipe.com> In-Reply-To: <201008121302.o7CD2BJv044208@lava.sentex.ca> References: <alpine.BSF.2.00.1008100841350.96753@tiktik.epipe.com> <alpine.BSF.2.00.1008101503190.96753@tiktik.epipe.com> <201008121302.o7CD2BJv044208@lava.sentex.ca>
index | next in thread | previous in thread | raw e-mail
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/home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1008121828360.96753>