linux security - Nov 1996 - denial of service attack on login

Hi,

I''ve been writing a login application to utilize the features of both
PAM
and libpwdb. Not surprisingly, this has meant looking at some old code..

The following denial of service attack seems to work quite nicely on my
ancient Red Hat 3.0.3 system with the standard login application. Perhaps
this is not a problem with 4.0? Does anyone know about other distributions?

	joe$ nvi /var/log/wtmp

	[ Now no-one else can log in ]

This is a problem with advisory locking. The fact that anyone can create an
exclusive lock on a file they can only read! Is this behavior appropriate?

My copy of the POSIX book (D. Lewin, O''Reilly & Assoc.
''94) is a little
vague as to the "correctness" of this behavior. Perhaps someone can
provide
a better explanation?

Regards

Andrew
--
        Linux-PAM: http://parc.power.net/morgan/Linux-PAM/index.html
          libpwdb: http://parc.power.net/morgan/libpwdb/index.html

Once upon a time, Andrew G. Morgan wrote
> The following denial of service attack seems to work quite nicely on my
> ancient Red Hat 3.0.3 system with the standard login application. Perhaps
> this is not a problem with 4.0? Does anyone know about other distributions?
>
> 	joe$ nvi /var/log/wtmp
>
> 	[ Now no-one else can log in ]
This doesn''t seem to happen on my system - RedHat 3.0.3 + shadow
passwords.  My /bin/login comes from shadow-960810-1.  Maybe the
shadow passowrd suite doesn''t try to lock wtmp?
--
Chris Adams - cadams@ro.com
System Administrator - Renaissance Internet Services

Hmm, I can imagine utmp being locked this way, but is it worth it for wtmp?
All login does is add an entry to the end...

Linux lacks the updwtmp{,x}() calls which SVR4 provides as a packaged way to
update wtmp.  My local login code when on Linux just does (basically):

    if ((fd = open(_PATH_WTMP, O_WRONLY|O_APPEND, 0)) >= 0) {
      (void)write(fd, (char *)ut, sizeof(struct utmp));
      (void)close(fd);
    }

and I''ve seen no problems so far (we don''t care about the
order of the writes,
and the worst that can happen is a couple of corrup wtmp entries).

Of course this "denial of service" doesn''t stop someone
connecting by rcmd or
rexec, so it can be detected and fixed.

[mod: You can''t assume that everybody is running rcmd/rexec. There
are good, security related, reasons for not running those.... -- REW]

 -- Jon

On Tue, 26 Nov 1996, Andrew G. Morgan wrote:
> The following denial of service attack seems to work quite nicely on my
> ancient Red Hat 3.0.3 system with the standard login application. Perhaps
> this is not a problem with 4.0? Does anyone know about other distributions?
>
> 	joe$ nvi /var/log/wtmp
It locks people out of Debian 1.2 as well.

         +----------------------------------------------------+
         | Technical Support Engineer, Cyclades Corporation   |
         | 800/88-CYCLADES (882-9252) or (510)770-9727, x258  |
         | High Performance Multiport Serial Cards & Routers  |
         | Unsolicited mail ads subject to a $25 handling fee |
         +----------------------------------------------------+

> > The following denial of service attack seems to work quite nicely on
my
> > ancient Red Hat 3.0.3 system with the standard login application.
Perhaps
> > this is not a problem with 4.0? Does anyone know about other
distributions?
> >
> > 	joe$ nvi /var/log/wtmp
> >
> > 	[ Now no-one else can log in ]
>
It doesn''t work on my (slightly) modified slackware 3.1 installation
either.  Just for reference.


Http://softcon.com offers web pages for a reasonable rate, and will even
create pages for you at *very* fair rates.  Check us out today if
you''re
looking for a home for your web pages.

Chris Adams:
> > 	joe$ nvi /var/log/wtmp
> >
> > 	[ Now no-one else can log in ]
>
> This doesn''t seem to happen on my system - RedHat 3.0.3 + shadow
> passwords.  My /bin/login comes from shadow-960810-1.  Maybe the
> shadow passowrd suite doesn''t try to lock wtmp?
Yes.  It shouldn''t be necessary - the O_APPEND open() flag should be
enough to guarantee atomic writes at end of file (it''s a kernel bug
if it doesn''t).  Original *BSD login sources don''t lock wtmp
either,
but util-linux does.  Perhaps O_APPEND didn''t work right on old
kernels?  Remember util-linux login was ported to Linux 0.12 :-).

Marek

[I presume I''ll just get flamed or a terse answer in response to this,
attributed to ignorance (in some form or other)]

On Tue, 26 Nov 1996, Andrew G. Morgan wrote:
> The following denial of service attack seems to work quite nicely on my
> ancient Red Hat 3.0.3 system with the standard login application. Perhaps
> this is not a problem with 4.0? Does anyone know about other distributions?
>
>       joe$ nvi /var/log/wtmp
>
>       [ Now no-one else can log in ]
Now that we''ve determined that this problem exists in just about every
popular, current distribution, what can I do or where do I go for my
best bet at a (temporary, at least) solution?  Any additional
information on what is/isn''t fixed would be appricated. ... eg
regarding
wheather said fix addresses the problem of needing a lock on wtmp and
the ability of others to prevent that or a specific program like login
which has been told it doesnt need to lock the file.

[mod: I''d suggest that you grab your closest login sources. Easiest
would be to grab those that are for your system. Recompile them, and
verify that they are the same as what you already have. Then find the
part that locks the wtmp file and delete it. -- REW]

Thanks in advace...
mike

On Tue, 26 Nov 1996, Andrew G. Morgan wrote:
> The following denial of service attack seems to work quite nicely on my
> ancient Red Hat 3.0.3 system with the standard login application. Perhaps
> this is not a problem with 4.0? Does anyone know about other distributions?
>
> 	joe$ nvi /var/log/wtmp
>
> 	[ Now no-one else can log in ]
Doesn''t work on RedHat 4.0 on sparc.

[mod: Figures. Andrews introduction mentioned that he was looking at
old code for the implementation of the PAM project. So you''d guess
that they wouldn''t make the same mistake there as in the
"old"
code....  (PAM is included in Red Hat 4.0) -- REW]

--
/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I   andy@linux.org.pl     I
+-------------------+--------+-----+-------------+-------------------------+
| http://melkor.mimuw.edu.pl/~andy | IRC: Emin | PGP key available         |
\--------------------------------------------------------------------------/