The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #8 1989-02-08 (1 file, 3461 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/108.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Security Digest Volume 1 Issue 8

subject(s):

            /bin/passwd and ulimit 0
            lock
            Re: lock(1)
            Re:  Consequences of ulimit 0 bug
            Re:  lock(1) nonsense
            Re: find-script (V1 #4) and ulimit (V1 #5)
            Re: do not run fingerd as root
            Reducing security risks in public domain software

------------------------------------------------------------------------

Date: Wed,  8 Feb 89 15:46:46 PST
From: Jeff Beadles <uunet!RELAY.CS.NET!jeff%quark.gwd.tek.com>
Subject: /bin/passwd and ulimit 0

It seems that one of the easiest ways to fix the problem, is to do
something like the following in the source to /bin/passwd:

        rlp.rlim_cur = RLIM_INFINITY;
        rlp.rlim_max = RLIM_INFINITY;

        if ( setrlimit(RLIMIT_FSIZE,&rlp)) {
                perror("setrlimit");
                exit(1);


for those with source, this is one of the easiest way to fix it.  By the
way, BSD 4.3 appears to have already fixed this.

------------------------------------------------------------------------

Date: Wed, 8 Feb 89 18:58:24 -0800
From: uunet!okeeffe.Berkeley.EDU!bostic (Keith Bostic)
Subject: lock

Lock has been fixed for forever.  Here it is.

[It has been sent as the next digest after this one. - neil]

------------------------------------------------------------------------

Date: Wed, 8 Feb 89 21:51:03 PST
From: Peter Shipley <uunet!lll-crg.llnl.gov!wuthel!shipley>
Subject: Re: lock(1)

>> A point to note: when you're fixing this, just comment out
>> the code which checks against "masterp". *DO NOT* simply change
>> the magic password to "something only you know", unless you are
>> absolutely sure that both the source *and the binary* are unreadable
>> to others.
>
>Back in school, our lock program would always take the root
>password to unlock it, and if the user said "lock me", his/her
>account's password was used rather than prompting for a new one.
>This seems like a much more reasonable approach...
>

But how do you know I am running your version of lock and not my own
version that has the "look & feel" of yours.  All I have to do is lock
enough terminals to frustrate enough user to call you to unlock them
and voila! I gots de' superuser password...

------------------------------------------------------------------------

Date: Wed, 8 Feb 89 10:29:55 MST
From: ames!ncar.UCAR.EDU!boulder!cadnetix.COM!rusty (Rusty)
Subject: Re:  Consequences of ulimit 0 bug

Peter da Silva talks about using ulimit <small number> instead of 0
to get root access.  A really "smart" user, rather than randomly
trying to ruin the passwd file, would attempt to figure out how long
to make his password to get the truncation to occur at the 'desired'
location.  This, of course, assumes that the passwd file is readable.

------------------------------------------------------------------------

Date: Thu, 9 Feb 89 11:50:21 EST
From: Christopher Lott <uunet!cis.ohio-state.edu!cml>
Subject: Re:  lock(1) nonsense

The problem with always allowing a lock program to accept the root
passwd follows.  We found that the root passwd is useful to break a lock
running on an idle terminal (the user locked the terminal and left).

However, consider the person who writes a highly similar lock program
which also accepts the root passwd - but logs it.  The sysadmin doesn't
even know that it happened, if done skillfully enough.

Lock programs around here (OSU) no longer accept root passwd as a
default, although they can be told to do so.  Such locks are nuked
by having an operator log into the workstation in question (on suns)
via rlogin as root.

------------------------------------------------------------------------

Date: Sat, 11 Feb 89 20:19:44 +0100
From: Svante Lindahl <uunet!mcvax!front.se!Svante.Lindahl>
Subject: Re: find-script (V1 #4) and ulimit (V1 #5)

The script for checking for new or modified suid programs (V1 #4) should
check if the programs ctime has changed. Otherwise a suid program could
be changed, and its mtime reset with utimes the sys-call (utime on
SysV). This can be achieved by including -c as an option to ls.

The problem with "ulimit 0; passwd" reported in V1 #5 can be exploited
on SunOS 3.x as well. Use csh and its builtin command "limit" instead
of ulimit (i.e "limit filesize 0"). Other BSD-based systems (including
SunOS 4.0) might have the same hole.

------------------------------------------------------------------------

Date: Sat, 11 Feb 89 20:16:14 +0100
From: Svante Lindahl <uunet!mcvax!front.se!Svante.Lindahl>
Subject: Re: do not run fingerd as root

In V1 #5 Mike Spitzer writes that my suggested fix to finger (make
sure that .plan and .project are regular files) is not sufficient:

> Unix allows you to create hard links to files that you don't own and
> can't read.  So, if you:
>
>       cd ~
>       ln ../someuser/unreadable-file .plan
>       finger me@localhost
>
> You'll still get the file if fingerd is running as root.  The .plan is
> a still a normal file so the restrictions suggested above won't stop
> you.  You'll will be able to read any file in a readable directory on
> the same filesystem as your home directory.

Aaaargghh! I was going to say that finger should also check that .plan
and .project are owned by the person being fingered, but I couldn't
come up with a reason why this would be necessary.
Now, can I have my fingerd run as root, or is there still more to
this? (No, I don't *have* to have my fingerd run as root).

------------------------------------------------------------------------

Date: Tue, 14 Feb 89 12:13:04 CDT
From: Chris Rusbridge <uunet!munnari!max.sait.oz.au!cccar>
Subject: Reducing security risks in public domain software

Many, if not most UNIX sites rely heavily on freely available
software, often picked up via anonymous FTP from one of several sites.
This software is often quite crucial to many operations (eg sendmail).
How do we know it does what it is expected to do?

Note I am not asking whether there are bugs, nor whether there are
design errors. But is the software I pick up the same software the
author created?

An obvious hacker attack is to modify the source of some major package
such as sendmail, rn etc to introduce some loophole which can be
exploited by the hacker. We the users then cooperate with the hacker
by picking up the package and actively distributing it. I am sure most
of us run similar software from root occasionally, and often install
it SUID root.

There are techniques for authenticating files, so that one can be sure
that the file that arrives is the same as that sent. The most well
known are the digital signature techniques. My understanding of these
techniques is as follows.

The author has previously distributed by a secure route a public key.
This could be in some reference library, where the hacker would find
it difficult to place a substitute without detection. The author has a
corresponding private key. The author encrypts a short message
associated with the package (for example "The checksum of this package
is !@#$%^%^&&**"), using the private key. Users decrypt the message
using the public key, and can then use the message to verify the
file is as sent.

Of course this technique will fail where the hacker has access to the
author's source files, and has modified them in situ. Then the author
also cooperates with the hacker in both distributing and
authenticating the hack.

With the rash of recent security holes indicating that most systems on
the Internet could have been easily broken into, these problems are a
serious worry. We here in Australia are embarking on a major
networking upgrade, which will make life much easier for the hacker.
We are facing similar problems in the VMS world.

Are there any standard mechanisms for combatting this problem? Any
RFCs? Any action at all?

------------------------------------------------------------------------

        End of Security Digest Volume 1 Issue 8
        **********************

END OF DOCUMENT