linux security - May 1997 - [Linux UID/GID ''Feature'']

I picked up the following from Bugtraq.

-----Forwarded message from David Phillips <phillips@PCISYS.NET>-----

MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <01BC5D8D.679DD4A0@frank56.pcisys.net>
Date: 	Sat, 10 May 1997 21:56:05 -0600
Reply-To: David Phillips <phillips@PCISYS.NET>
Sender: Bugtraq List <BUGTRAQ@netspace.org>
From: David Phillips <phillips@PCISYS.NET>
Subject:      Linux UID/GID ''Feature''
To: BUGTRAQ@netspace.org

I mailed this to a friend as a sanity check:

While trying to make a user entry in the /etc/passwd file unrecognized
so I could demonstrate the use of valid UIDs, I placed a # in front of the UID.
My theory was that this would make it an invalid number and cause Linux
to give an authentication failure.  (This worked as expect on SunOS 4.1.4)
But then we tried to su to that user and were rewarded by being dumped
to UID 0.  It didn''t recognize the UID so it defaulted to 0.  Cool huh?

It seems ideal for a hard to find, back door but given that you must be root
to write to the passwd file, I have not found a better way to really exploit it.
My friend replied:

I did test the problem using various remote logins, such as rlogin,
rsh, ftp, telnet, exec, ssh and console login. Trying to rlogin, rsh,
rexec or telnet failed with an authentication failure. But, su, ftp, ssh
and console login all succeeded and gave UID 0. A small stumbling block,
but still useful for a backdoor. I''ll keep checking it tho''.

He also noted that it works the same for GID.  We have not taken the time
to research the problem fully but have tested it on Red Hat 4.1 (2.0.27/2.0.30).

[mod: Jon Lewis <jlewis@fdt.net> reports: It doesn''t work for
slackware
with shadow passwords.... -- REW]

David Phillips, TASC
phillips@pcisys.net

-----End of forwarded message-----

--
Eric Augustus
augustus@stic.net
-----------------
If I had only known, I would have been a locksmith.
		-- Albert Einstein

>  While trying to make a user entry in the /etc/passwd file
> unrecognized so I could demonstrate the use of valid UIDs, I placed
> a # in front of the UID.  My theory was that this would make it an
> invalid number and cause Linux to give an authentication failure.
> (This worked as expect on SunOS 4.1.4) But then we tried to su to
> that user and were rewarded by being dumped to UID 0.  It didn''t
> recognize the UID so it defaulted to 0.  Cool huh?
Some people are replying: "what do I care when a root-user is
editing /etc/passwd, and can put # in the /etc/passwd file to get
a root-account?"

That is not the issue. The issue is that as a sysop you might be
surprised that putting a "#" in the uid field doesn''t stop
the guy
from logging in, but gives him a root-account instead. You all should
better be warned.... (But I never do that -> Ok let it rest)

Say you''ve been closing accounts by adding #''s on SunOS for
years and
now are administrating a Linux machine. Surprise, that annoying cracker
you thought you threw off, now suddenly has root priviliges. Bad thing.

Another thing is a "#" in front of the whole line. That also
doesn''t work.
You have to login as "#wolff" instead of just "wolff".

One thing that does work is to put a "*" in front of the passwd entry.

                                Roger.

Your message dated: 12 May 97 15:46:51 -0000
> > Some people are replying: "what do I care when a root-user is
> > editing /etc/passwd, and can put # in the /etc/passwd file to get
> > a root-account?"
> > That is not the issue. The issue is that as a sysop you might be
> > surprised that putting a "#" in the uid field
doesn''t stop the guy
> > from logging in, but gives him a root-account instead. You all should
> > better be warned.... (But I never do that -> Ok let it rest)
> > Say you''ve been closing accounts by adding #''s on
SunOS for years and
> > now are administrating a Linux machine. Surprise, that annoying
cracker
> > you thought you threw off, now suddenly has root priviliges. Bad
thing.
> >
> > Another thing is a "#" in front of the whole line. That also
doesn''t work.
> > You have to login as "#wolff" instead of just
"wolff".
> >
> > One thing that does work is to put a "*" in front of the
passwd entry.
> >
> >                                 Roger.
>
> Doesn''t work on Slackware 2.0.30 with shadow.  I even tried adding
the
> "#" in front of the passsword entry in the shadow file.
Because it is not supposed to do that - /etc/passwd and /etc/shadow are
formatted databases and you should not violate their format. Placing # in
front of a numerical field does not make that field invalid as the result of
a translation of string ''#N'' to a number if I remember
correctly is a number
0.

If you would like to lock an account by modifing hash of a password, make
sure that you are using a character which is invalid as a hash, such as
''*''.
Also remember that by invalidating hash you are not locking an account, you
are only preventing this user from authenticating himself/herself to a
system via programs that use /etc/passwd to do authentication

Alex

R.E.Wolff@BitWizard.nl (Rogier Wolff) writes:
> Say you''ve been closing accounts by adding #''s on SunOS
for years and
> now are administrating a Linux machine. Surprise, that annoying cracker
> you thought you threw off, now suddenly has root priviliges. Bad thing.
This behavior is not part of any spec that I''ve ever seen.  I hardly
understand why anybody would put # signs in the uid field.  It is
certainly undocumented, and anything undocumented, especially in one
of the most important security files on the system, should send a
shiver down any good sysadmin''s spine.

Common sense ways to achieve this effect wihout breaking the format of
/etc/passwd:
 * Invalidate the password -- add a * in front of the crypted password
   or replace it with a *.  Will effectively block any access to the
   system that uses /etc/passwd for authentication.
 * Invalidate the login shell -- set it to /bin/nonexistant or
   something.  You could even make /bin/nonexistant be a short C
   program telling them "access denied" or whatever.  (This would
   still allow access via FTP, however.)  This could be good if you
   only want to deny them shell access but still allow access via a
   different mechanism.
[mod: Wietse Venema suggested another one to me last year:
 * Invalidate the home directory.
-- REW]

Furthermore, if there is a person trying to hack the system, I
wouldn''t be so lenient as to only star them or add # to their uid
field.  I''d just whack the account in the first place, preventing them
from receiving mail, using FTP, putting stuff up on the Web, etc.
(But of course this is a matter of policy and may not be applicable in
all situations.)
> Another thing is a "#" in front of the whole line. That also
doesn''t work.
> You have to login as "#wolff" instead of just "wolff".
Another problem with this is that the # is a shell meta-character.
This can cause some unexpected and unwanted effects in shell scripts.
> One thing that does work is to put a "*" in front of the passwd
entry.
Yes, and I don''t really see what all the fuss is about since we have
several working methods that don''t violate the format of /etc/passwd.
Anything that does violate the format ("#" included) should never be
used.  Multiple programs parse that file, some using system calls and
some not, and anything that violates spec can cause unexpected and
undesired effects in any of those programs -- core dumps, possible
security holes, whatever.

[mod: Sometimes parts of the Linux system don''t behave exactly as some
of us would have expected. If that happens in a security related way,
I like to warn everybody on this list about it. To some people this
whole issue is "against the specs", but where are the specs?  Almost
everybody has learnt the specs by experimenting. As a # in the uid
field disables an account on SunOS, I thought it might be possible for
a site to be adding a # to the uid field as the standard account
invalidating method.

This is actually not much different from a warning "there is a buffer
overrun in su". It is a (to some) unexpected insecure behaviour. This
whole discussion about "I use this to invalidate an account" is not
necessary. Yes 99% of us are not affected by this issue, let us let it
rest then. Please? -- REW]

--
John Goerzen          | Running Debian GNU/Linux (www.debian.org)
Custom Programming    |
jgoerzen@complete.org |

>  * Invalidate the home directory.
> -- REW]
Note. This was not intended as a separate method to lock someone
out. It was intended IN ADDITION TO the other things: * in the
password field and an invalid shell. This should make sure that
the .rhosts files are not writable by the user, and that you know
what''s in them.

					Roger.