linux security - Sep 1998 - /bin/login problem

I would be surprised if someone hasn''t encountered this already, but I
haven''t found any discussion of the nature of this problem.  I run
RehHat
5.0.  If a user makes a mistake in the login process such as the
following:

login:  mistake
password: xxx
Login incorrect!

login:  username
password xxxx

bash$

a ps will show, among other things,

2333 /bin/login --mistake.

Since some users accidentally type their password at the login prompt,
this is a concern.

Is this a well known problem and what should I do to fix it.

Thanks.

Eric Dedrick
dedrick@physics.purdue.edu

Eric Dedrick wrote:
[...]
> login:  mistake
[...]
> a ps will show, among other things,
>
> 2333 /bin/login --mistake.
>
> Since some users accidentally type their password at the login prompt,
> this is a concern.
Some people are writing linux security and suggesting that login could
rewrite its argv to fix this. However even if the string is just
momentarlily visible, it should be considered a serious problem.

What we need to do is change the interface between getty and login.
But backward compatibility is also an issue.

For example we could do the following:

An adapted login can rewrite its argv as soon as possible. This to
remain compatible with getty''s that don''t know about the newer
interface.

If a new login finds "no_such_user" as its argument, it reads the
login name from an environment variable instead of from the argument
vector.

A getty needs to be configurable to do the new or the old stuff.




Anybody have a few spare hours on his hands?


					Roger.


--
| The secret of success is sincerity.  Once you can |  R.E.Wolff@BitWizard.nl
| fake that, you''ve got it made.  -- Jean Giraudoux |       T:
+31-15-2137555
-We write Linux device drivers for any device you may have! Call for a quote-

Rogier Wolff:
>
> Eric Dedrick wrote:
> [...]
> > login:  mistake
> [...]
> > a ps will show, among other things,
> >
> > 2333 /bin/login --mistake.
> >
> > Since some users accidentally type their password at the login prompt,
> > this is a concern.
>
> Some people are writing linux security and suggesting that login could
> rewrite its argv to fix this. However even if the string is just
> momentarlily visible, it should be considered a serious problem.
>
> What we need to do is change the interface between getty and login.
> But backward compatibility is also an issue.
SYSV4 getty (actually, the tty port monitor) selects the terminal
for readability, but does not actually read the login name. It then
execs the login program, after setting the TTYPROMPT environment
variable to notify the login program that the username is available
on stdin.

See my logdaemon utilities.

	Wietse

Brandon S. Allbery KF8NH wrote:
> In message <199809042121.XAA07939@cave.BitWizard.nl>, Rogier Wolff
writes:
> +-----
> | If a new login finds "no_such_user" as its argument, it reads
the
> | login name from an environment variable instead of from the argument
> | vector.
> +--->8
>
> That won''t help:  consider `ps aexwww''.  I would suggest
instead that the
> user name be passed on an additional fd; e.g.:
>
> 	login -I fd
> 		login reads a user name from file descriptor `fd'', then
> 		proceeds as if the user name had been specified as an
> 		argument.
>
> Again, getty must support this mode of operation.
>
Ok. Many people are mailing me about the "e" option to ps, that is
supposed to show the environment. (It somehow doesn''t work on my
version of ps. Forget about it, I don''t care that it doesn''t
work)

The environment is not accessible to other users.
   wolff@cave% cat /proc/1/environ
   cat: /proc/1/environ: Permission denied

Of course, instead of "no_such_user" something that looks like an
option is much better. (the phrase "engage brain before pressing send"
comes to mind :-)

Passing the string through a pipe works (I didn''t find that
"obvious":
The sending end of the pipe was written to by the same process, which
just exec-ed the reading program, and the writing end of the pipe is
closed by the time the read is performed)


#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main (int argc, char **argv)
{
  char buf[32];
  int p[2];
  int n, fd;

  if ((argc > 2) && (strcmp (argv[1] , "-i") == 0)) {
    fd = atoi (argv[2]);
    printf ("fd = %d\n", fd);
    n = read (fd, buf, 30);
    if (n < 0) {
      perror ("read");
      exit (1);
    }
    close (fd);
    buf[n] = 0;
    printf ("n=%d, buf=''%s''\n", n, buf);
    exit (0);
  } else {

    pipe (p);
    write (p[1], "this is a test", 14);
    close (p[1]);
    sprintf (buf, "%d", p[0]);
    execl ("./pass", "pass", "-i", buf, NULL);
    perror ("exec");
  }
  exit (0);
}

Regards,

			Roger.


> --
> brandon s. allbery	[os/2][linux][solaris][japh]	 allbery@kf8nh.apk.net
> system administrator	     [WAY too many hats]	   allbery@ece.cmu.edu
> electrical and computer engineering					 KF8NH
> carnegie mellon university
>
>

--
| The secret of success is sincerity.  Once you can |  R.E.Wolff@BitWizard.nl
| fake that, you''ve got it made.  -- Jean Giraudoux |       T:
+31-15-2137555
-We write Linux device drivers for any device you may have! Call for a quote-

Wietse Venema wrote:
> Rogier Wolff:
> > Passing the string through a pipe works (I didn''t find that
"obvious":
> > The sending end of the pipe was written to by the same process, which
> > just exec-ed the reading program, and the writing end of the pipe is
> > closed by the time the read is performed)
>
> It seems much simpler to me to select the terminal for readability
> (i.e. until someone hits the ENTER key) and to notify the login
> program that it can find the name on STDIN instead of finding it
> on the command line.
>
> The TTYPROMPT environment variable used by SYSV4 does not pass
> sensitive info via the environment; it is just a flag to notify
> the login program that the login name is available on STDIN. All
> this requires minimal change to the login progam: a getenv() call
> and setting a flag to force reading STDIN upon program startup.
>
> Yes, this means that you lose all those cutesy features of my agetty
> program. But login/getty code runs as root and is extremely security
> sensitive. Keep it simple, I''d say.
>
> 	Wietse
>
One of the classical "getty" features that you loose this way is
the autobauding that classical getty''s perform. (i.e. read a
character, and change the baudrate whenever it''s "bad")

				Roger.

--
| The secret of success is sincerity. Once you can |R.E.Wolff@BitWizard.nl
| fake that, you''ve got it made. -- Jean Giraudoux | phone:
+31-15-2137555
We write Linux device drivers for any device you may have! fax: ..-2138217

Wietse Venema:
> [ having getty select the tty for readability without actually
> reading the login name from stdin]
> Yes, this means that you lose all those cutesy features of my agetty
> program [...]
Rogier Wolff:
> One of the classical "getty" features that you loose this way is 
> the autobauding that classical getty''s perform. (i.e. read a
> character, and change the baudrate whenever it''s "bad")
True, however with today''s speed-buffering modems this behavior
can be undesirable. At least I haven''t needed speed switching in
my agetty program since I hooked up a ZyXEL modem in 1991 or so.

One also loses detection of parity, erase and kill characters.
Loss of parity detection can be a problem with 7-bit terminal
settings. So it seems best to preserve getty functionality.

Does LINUX have the moral equivalent of the TIOCSTI ioctl() call
(simulate tty input)? If so, that could be used by (a)getty to
stuff the login name back after reading it, so that /bin/login can
pick it up from STDIN.

[mod: Yes. -- REW]

	Wietse


From mail@mail.redhat.com Tue Sep 1 18:29:29 1998
Received: (qmail 12653 invoked from network); 1 Sep 1998 22:28:49 -0000
Received: from mail.redhat.com (199.183.24.239)
  by mail2.redhat.com with SMTP; 1 Sep 1998 22:28:49 -0000
Received: from rosie.BitWizard.nl (root@3dyn229.delft.casema.net
[195.96.104.229])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA22416
	for <linux-security@redhat.com>; Tue, 1 Sep 1998 18:29:29 -0400
Received: from cave.BitWizard.nl (wolff@cave.BitWizard.nl [130.161.127.248])
	by rosie.BitWizard.nl (8.8.5/8.8.5) with ESMTP id AAA17671
	for <linux-security@redhat.com>; Wed, 2 Sep 1998 00:28:28 +0200
Received: (from wolff@localhost)
	by cave.BitWizard.nl (8.8.8/8.8.8) id AAA03338
	for linux-security@redhat.com; Wed, 2 Sep 1998 00:28:25 +0200
Received: from dutepp0.et.tudelft.nl
	by rosie.BitWizard.nl (fetchmail-4.2.9 POP3 run by wolff)
Approved: R.E.Wolff@BitWizard.nl
	for <wolff@localhost> (single-drop); Tue Sep  1 08:50:38 1998
Received: from ferryman.ocn.nl (root@ferryman.ocn.nl [193.78.195.1])
	by dutepp0.et.tudelft.nl (8.8.8/8.8.8/CARDIT) with SMTP id EAA23808
	for <wolff@dutepp0.et.tudelft.nl>; Tue, 1 Sep 1998 04:00:22 +0200 (MET
DST)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by
ferryman.ocn.nl (8.6.13/8.6.9) with SMTP id DAA11271 for
<r.e.wolff@BitWizard.nl>; Tue, 1 Sep 1998 03:47:38 +0200
Received: (qmail 10595 invoked by uid 501); 1 Sep 1998 01:48:49 -0000
Received: (qmail 20687 invoked from network); 31 Aug 1998 20:51:31 -0000
Received: from mail.redhat.com (199.183.24.239)
  by mail2.redhat.com with SMTP; 31 Aug 1998 20:51:31 -0000
Received: from jvelders.tn.tudelft.nl (root@jvelders.tn.tudelft.nl
[130.161.48.129])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA16400;
	Mon, 31 Aug 1998 16:52:17 -0400
Received: from localhost (jpv@localhost [127.0.0.1]) by jvelders.tn.tudelft.nl
(8.8.7/8.8.3) with SMTP id WAA05802; Mon, 31 Aug 1998 22:50:13 +0200
Date: Mon, 31 Aug 1998 22:50:11 +0200 (CEST)
From: Jan-Philip Velders <jpv@jvelders.tn.tudelft.nl>
X-Sender: jpv@jp-gp.vsi.nl
Reply-To: Jan-Philip Velders <jpv@jvelders.tn.tudelft.nl>
To: redhat-announce-list@redhat.com, linux-security@redhat.com
Subject: StackGuard-protected Linux and a New StackGuard Compiler (fwd)
Message-ID: <Pine.LNX.3.96.980831224827.5795B-100000@jp-gp.vsi.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-moderate: yes

Hi all,

perhaps this is something of interest to all of us RedHat users ?

Later Crispin added:
| In response to many comments pointing out a glaring omission (grovel
| grovel) the SOURCE CODE for StackGuard is now on line, both as a complete
| tar ball and as a source patch to gcc 2.7.2.3, available here:
|
|     http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/compiler.html

Greetings,
Jan-Philip Velders
<jpv@jvelders.tn.tudelft.nl>

_---------- Forwarded message ----------
_Date: Thu, 27 Aug 1998 22:26:54 -0700
_From: Crispin Cowan <crispin@CSE.OGI.EDU>
_To: BUGTRAQ@NETSPACE.ORG
_Subject: StackGuard-protected Linux and a New StackGuard Compiler

StackGuard is a compiler to protect programs against stack smashing
attacks.  When stack smashing exploits are deployed against
StackGuard-protected programs, the protected program halts and logs the
attack attempt in syslog, rather than yield control to the attacker''s
code.

This post is to announce a new release of StackGuard, providing better
performance, and support for shared libraries.  We have re-compiled the
entire set of programs and libraries provided in the Red Hat 5.1
distribution.  In addition to providing the compiler, we are also
providing these protected programs and libraries in the form of binary
RPMs on our server:

        http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

These 526 RPMs are drop-in replacements for the RPMs provided by
Red Hat, except that stack smashing is no longer an alternative means
of getting into the box when you forget the root password :-) There are
a few other errata covered in the README.SG file.

Note that StackGuard-protected programs are inter-operable with
un-protected shared libraries, and StackGuard-protected libraries are
inter-operable with un-protected programs.  This is a mixed blessing:
on one hand, it means that if you are concerned with glibc
vulnerabilities, you need only install the StackGuard-protected glibc
RPM.  On the other hand, if you are concerned with all shared library
vulnerabilities, the unprotected libraries will still function with
your new StackGuard-protected programs, and so you must be careful to
install all libraries used by all programs that you wish to protect.

The source code used for the re-build is the source code provided by
ftp.redhat.com as of July 13, 1998.  There were a small number of
changes that we had to make to the source to successfully re-build it,
documented in README.SG.

The StackGuard compiler itself is an enhancement to gcc 2.7.2.3, and
for the most part is a drop-in replacement for gcc.  The one major
caveat is that StackGuard protection must be turned OFF to build the
Linux kernel.  This is because the kernel knows what a function
activation record looks like to do context switching, and StackGuard
changes the format of an activation record to do the integrity check.

The support for shared libraries and the enhanced performance are
enabled by an enhancement originally proposed by der Mouse, to the
effect that a null next to a value is not possible to overflow
undetected, because string ops terminate on null.  However, some string
operations actually do copy through nulls, such as gets().  We have
enhanced der Mouse''s technique so that the integrity word is a
combination of Null, CR, LF, and -1, which should cover the range of
termination symbols for C string operations.

A paper describing StackGuard appeared at the 1998 USENIX Security
Conference.  The paper is also on our web page.

Naturally, we would appreciate feedback on either security or
functionality problems with any of the RPMs that we have provided.

Crispin
-----
 Crispin Cowan, Research Assistant Professor of Computer Science, OGI
    StackGuard: protect your software against Stack Smashing Attack
       http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/

                 Support Justice:  Boycott Windows 98