~/.login_conf mechanism is flawed

[Janne Snabb]

Hi,

I am posting to a public list as this issue has been already disclosed
publicly on full-disclosure mailing list.

This looks a bit worrying:

http://lists.grok.org.uk/pipermail/full-disclosure/2010-August/075944.html

Looks like the per-user login capability database (~/.login_conf,
~/.login_conf.db) functionality is creating a vulnerability.

What I found especially worrying is that this user-supplied untrustable
file is being parsed and processed by various daemons and other
login mechanisms BEFORE permanently dropping root privileges. Unless
there is a very strong reason, which I am overlooking, to do so, I
find this design very flawed.

It makes the following possible for example:

 - System administrator sets a limit (for example datasize) in
   /etc/login.conf to a certain class of users, and expects it to
   limit those users' use of system resources.

 - User creates their own .login_conf where they set the limit
   unlimited. This succeeds because the user's .login_conf{,.db}
   is processed before dropping privileges.

The problematic execution order is evident by doing for example the
following:

 - Enable tracing of sshd and its child processes (as root):

    # ktrace -i -p `cat /var/run/sshd.pid`

 - Log in as normal user with sshd from other terminal and do nothing
   there. Just log out immediately or whatever.

 - Stop the trace:

   # ktrace -C

 - Examine the execution order in the trace (pay attention to process 
   ID numbers):

    # kdump | grep ' sshd ' | grep 'NAMI.*/.login.conf\|set.*uid' | less



I think that the following is needed:

 - Change the execution order in several daemons, maybe in PAM? 
   /usr/bin/login?

 - Fix the database handling routines (the problem pointed out in
   HI-TECH's e-mail to full-disclosure). Even if the user-specific
   login capabilities database is being processed in the user's
   context, this might still allow for example breaking to /bin/sh
   from an (authorized) ftp-only account.

 - Add a flag in global login capababilities database for choosing
   whether the per-user login capabilities should be processed and
   make it DISABLED default. User-specific .login_conf{,.db} would
   be processed only if excplicitly enabled by the administrator.

I think this bug goes in to a class of local privilege escalation.

Am I missing something obvious? What do you think?

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/