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 #2 1989-01-23 (1 file, 3015 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Mon, 23 Jan 89 06:24:15 PST


Date: Fri, 13 Jan 89 23:09:06 EST
From: Jon Rochlis
Subject: Re: Yellow Pages Bug

On a releated note, there probably quite serious problems with YP even
forgeting about yppasswd and that flavor of attack.  I don't know much
about YP's implementation and haven't used Suns in about a year and
half, but spoofing the YP server shouldn't be difficult at all.  What
happens if I flood a target machine with YP responses for a
/etc/passwd yp lookup for root (or some random username with uid = 0)
including a password string I know (or no password).  Odds are my
packets will get there first (and in quantity) and any reply from the
real YP server will be lost.  Presto I'm in.

The attack is only slightly more difficult if YP uses source IP
addresses and/or low number ports
for authentication: then I need root someplace or a PC on the net or
something like that, but we should assume that is trivial to come by
in this day and age.  Faking the IP addresses is trivial.  (And I can
do it from anywhere on the Internet.)


Date: Sun, 15 Jan 89 10:56:47-0800
From: uunet!okeeffe.Berkeley.EDU!bostic (Keith Bostic)
Subject: Tightening security on SunOS 4.0 'fastfind'

If you just run the find program as a pseudo-user with no permissions, only
those directories that users have not protected will be added to the database.
To simply not add files because they reside on a mount point that has users
on it isn't useful.


Date: Sun, 15 Jan 89 11:01:48 PST
From: uunet!maxwell.mmwb.ucsf.EDU!rodgers
Subject: Moderated security list

I am very pleased to find that you are now moderating the list.  However, I
would strongly suggest that there be a header on each collected issue, with
a volume number and issue number on it, to facilitate filing the information
away, and to facilitate making references to earlier material.  A good
example is offered by the moderated list known as SunSpots, for Sun users.


Date: 16 Jan 89  9:45 +0100
From: "Hannes P. Lubich" <uunet!RELAY.CS.NET!>
Subject: Re: Yellow Pages Bug

reading the recent moderated zardoz list mailings I'm getting sick and
tired of this "I have found this bug that is the most dangerous at all
but I won't show you" attitude that was expressed in both the passwd/chfn
and the YP related postings from Germany. What drives me absolutely crazy
it that the author seem to have detailed knowledge but does at lot of
information hiding, especially when it comes to a detailed description of
the problem and (possibly) propagation of fixes.

[I appreciate the sentiment, but previous and current postings have
in many cases revealed security bugs including break-in methods.]


Date: Mon, 16 Jan 89 17:34:03 est
From: uunet!prcrs!paul (Paul Hite)
Subject: Yet Another Sendmail Bug

A bug exists in sendmail that allows any user to remove any file and mail
it somewhere.  The only restriction is that the user must know the pathname
of the file.

Below are the results of an Ultrix test.  I got identical results with
HP-UX.  This bug can be used to forge mail.  Sendmail offers several ways
to forge mail, but this bug can be used for much more than just forging
mail.  Here we use a queue file to "snatch" a target file:

Script started on Sun Jan 15 12:46:56 1989
<21> ls q*
<22> grep secret q*

All queue files have names that match "qf*".  The queue file contains many
lines, but the "D" line identifies the target file.  Sendmail will be root
as it eats the target.  No file permissions can save the target file from
this attack.  Now let's remove the target and receive it via mail:

<23> ls -lg /etc/deep.secret
-r--------  1 root     system        125 Jan 15 12:42 /etc/deep.secret
<24> /usr/lib/sendmail -q -oQ.
<25> ls -lg /etc/deep.secret
ls: "/etc/deep.secret": No such file or directory

I used root only to create the deep.secret file.  This test was done as "paul".
/etc/deep.secret has been delivered to my mailbox.  Any user can do this to
any file.

<26> prmail | tail
Date: Tue, 3 Jan 89 12:51:44 -0100
From: paul (Paul Hite)
To: paul
Subject: test sendmail bug

This is the contents of the deep.secret file.  Only root may see this file.
secret 2
secret 3
end of secret file deep.secret

script done on Sun Jan 15 13:01:20 1989

Some thoughts on closing this hole: The -oQ option is the culprit.  I suggest
simply losing the -oQ option.  This is really just another debugging feature.
If we must have a -oQ option then is should be available only to root.  Or
perhaps the directory specified should be owned by root.  The -oQ option
must be removed or restricted in some way.  This hole is more than just a
way to read protected files.  By targeting files like /etc/passwd,
/{vmunix,hp-ux}, etc it is possible to do considerable damage.

This is apparently old news to some people.  If fact, Ning Zhang tells
me that it was common knowledge at his University in the People's
Republic of China several years ago!  Still, it was news to me.  Folks,
if there are other bugs out there, please speak up.  Let's get these bugs
out in the open.


Date: Mon, 16 Jan 89 17:46:26 est
From: uunet!prcrs!paul (Paul Hite)
Subject: trapdoor in lock

Here is a message that I picked off Usenet awhile ago:

>  No kidding.  The 4.1BSD [I think] `lock' had a hardcoded magic
>  unlock password ("hasta la vista"), and ^Z would stop it as
The Ultrix "lock" doesn't respond to ^Z, but it does have the "hasta la vista"
password compiled in.

Previous messages in the thread pointed out that lock programs can be
blow off and spoofed.  Still, "hasta la vista"?


Date: Tue, 17 Jan 89 00:25:47 EST
From: uunet!attcan!utzoo!henry
Subject: atoi replacement

> - Never use atoi.  Instead, come up with a new routine (mine is called
> SToN) that accepts a string and a pointer to an int...

Please don't reinvent the wheel unnecessarily.  Look up the strtol()
function in System V, which has been adopted pretty much straight by
the ANSI C people.