[1966] in linux-security and linux-alert archive
[linux-security] shadow-971001
daemon@ATHENA.MIT.EDU (High Tide)
Sat Jul 11 19:37:11 1998
Date: Fri, 10 Jul 1998 18:02:52 -0500 (EST)
From: High Tide <hightide@ginch.org>
To: linux-security@redhat.com
In-Reply-To: <199807081440.KAA17970@pace.picante.com>
Resent-From: linux-security@redhat.com
Resent-Reply-To: linux-security@redhat.com
I think I may have found a security weakness w/ login in shadow-971001. I
can't imagine this being a large problem if no one has run into it yet,
but I know that's not the way to run security.
It seems that after the user has been authenticated, it makes a call to
setup_uid_gid to change the userID, and (for systems which support
multiple concurrent groups), make a call to initgroups before changing the
UID. if initgroups fails (apparently, EPERM || ENOMEM), setup_uid_gid
returns -1, however is still running as root. Main() does not check a
return from setup_uid_gid, and should continue processing, and execute a
shell, as root.
Tell me I'm missing something...
I appologize for being out of coding long enough to put together a patch
and contact the _right_ people before hand (I'm getting back though),
however if this does in fact need to be patched, it should be as simple as
what's done in su.c from the same package:
Change login.c:960 from
setup_uid_gid(&pwent, is_console);
to:
if (setup_uid_gid(&pwent, is_console))
exit(1);
Sean
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
