~/.login_conf mechanism is flawed
jhell
jhell at dataix.net
Fri Aug 13 05:34:16 UTC 2010
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 at 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
More information about the freebsd-security
mailing list