Re: ~/.login_conf mechanism is flawed

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

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"