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 #12 1990-04-23 (1 file, 6776 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Mon, 23 Apr 90 02:50:43 PDT
Subject: Security Digest V2 #12

Security Digest Volume 2 Issue 12


            compress, crypt, and CBW-like codebusters
            Re: crypt(compress())
            Re: Uutry in HDB

The unix security mailing list is by invitation only and contains
sensitive material which SHOULD NOT BE REVEALED to non-members.
If you must keep copies on-line, please encrypt them at the very least.

PLEASE POST TO:                              [email protected]
PLEASE SEND REQUESTS TO:             [email protected]

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


[ To those of you that noticed some missing postings about the Yellow
  Pages bugs, they have been shuffled to the next digest, because I am
  in the process of restructuring the list.  Read on ..... - neil ]

Date: Sun, 22 Apr 90 23:31:33 PDT
From: neil (Neil Gorsuch)

[ Following is a copy of a usenet posting that I just sent out to
news.sysadmin and  I apologize for including most of it,
but I feel that the members of the security list deserve as much
information as possible about the upcoming changes to the security
list, and this posting contains a lot of useful information.  I will
make further comments in []'s within it.  Remember, the stuff outside
of []'s is directed to the news.sysadmin lynch mob 8-). - neil ]

Contrary to popular belief, I applaud the creation of and
hope that it does well.  I will be doing my part by posting quite a
bit of stuff there.  I am setting up a very paranoid 8-) internet
gateway that I feel will be of interest, and will post a lot of
methodology and even source code of modified network programs
regarding that.  Anyone that wants an nntp feed of, give
me a call in a couple of weeks.  If you want a uucp feed of and are willing to poll zardoz, call me now and I will
add a number of uucp feeds of that group.  If you want a mail feed of, I will even add a few of those, as long as you are an
internet site, or are willing to poll zardoz.  In fact, I might even
be amenable to setting up a mail/news gateway for it, if someone tells
me which software works well for that (email or phone the answer
please, I don't read this news group very often).

[ The almost 8-) full details of the internet gateway will of course
be released to the security list first, so that anything that I miss
can be found by the list members before I let the world know anything
about my system's defenses - neil ]

ANYTHING BUT THAT.  There have been some long delays in answering list
membership requests, and I haven't gotten around to having the
security-request alias send back an automatic acknowledgement of
receipt.  The former is being rectified by the changes revealed below,
and the latter will be rectified at some point (sooner if someone
sends me a nice awk script to find the best return address from a mail
header 8-).

[ Please send me any awk or perl scripts that you have - neil ]

I do not believe in "security through obscurity" but prefer widely
available security discussions regarding methods, tips, procedures,
and other matters, as long as they don't touch on security holes that
REASONABLE AMOUNT OF TIME.  The vendors ARE contacted by CERT and ARE
probably on the security list.

Please don't post newly found security holes to the world at large
first.  Send them to CERT ([email protected]) and to the security
list ([email protected]) first.  Relax 8-), they will still be
disseminated to the world at large as explained below.  You have to
realize that some sites are at a much higher risk from crackers
(casual or dedicated), and that the security list changes I am about
to describe will still allow the world at large access to information
regarding fixing security holes in a reasonable fashion.  There has to
be some compromise between the ideal world where all information is
freely available to all, and a world where the law enforcement
agencies and the dedicated crackers and the lawyers and their lawsuits
dictate computer usage.

Some people seem to have gotten the wrong impression of my goals for
the security list.  It originally was started as a discussion forum
and early warning system for newly found security holes, including
NON-FIXED ones.  It has also become a relatively noise-free discussion
forum for unix security matters.  I am now changing the list somewhat
to accomodate both goals, as follows:

1. The (bulk of) the security list will be much easier to join, and
will continue to have the relatively noise-free discussions of
security topics that it currently enjoys, as well as receiving delayed
postings regarding new security holes that are fixable by binary
license sites and more detailed information regarding the security
holes than the world at large will receive.  The typical member (and I
will make reasonable exceptions) is a system administrator of an
internet connected system or of a very large system.  To join, email a
request to [email protected] or to
uunet!zardoz!uninet!security-request.  The more information supplied,
the better.  You can even mention news.sysadmin, now that I have
responded to my detractors 8-).

[ The delay from hole knowlege to larger list posting will be 2 - 4
weeks, enough time for people to find fixes, but short enough that the
larger list members will still get notification way ahead of everyone
else.  If you feel a different delay is appropriate, please tell me
why by phone or email to "neil" - neil ]

2. A small portion of the security list will receive postings
regarding UNFIXED security holes and very detailed COOKBOOK style
instructions on utilizing security holes.  These people will be the
pool of people that help to solve the UNFIXED security holes, or that
administer very large internet sites or other sites that are at a
substantially increased risk.  In fact, I will keep on tightening it
until postings there do not leak quickly, if at all, to the
"professional" hacker network.  It will not be a closed list, contact
me if you want on it, but you'd better be prepared to really justify
your inclusion.  It would be much better if you can get someone
already on it (you'll have to find someone you know 8-) to recomend
you.  The "core" will participate in the same discussions that the
bulk of the list will, the only difference will be in how NON-FIXED
security holes and security hole COOKBOOKS are treated.

[ I will announce the members in a few weeks (to the members only, I
don't want anyone else to know which spool directories to try to get
at).  If you haven't received anything by then, please send mail to
"neil", NOT 8-) security-request explaining why you should be on the
smaller list.  A lot of people that I know personally are already
slated to be on it.  I will almost certainly use CERT as a
filter/reference also (I'll call you guys tomorrow). - neil ]

I will probably (I may check with my lawyers first before making the
final decision on this policy) post the details for FIXING new
security holes to, with a delay from the time that they
appear in the larger security list.  I will certainly post some of the
security tips and methods discussed on the larger security list to

[ I don't believe in letting lawyers help me make decisions until I'm
actually in a lawsuit 8-).  I am thinking of a 3 week delay here.
Anyone who is uncomfortable with this whole idea, please contact me.
I will of course honor any requests by finders of holes to not spread
them outside of the core list. - neil ]

In article <[email protected]> [email protected] (Dave Ratcliffe) writes:
>In article <[email protected]>, [email protected] (John Gilmore) writes:
>>                                                          Someone
>> masquerading as "[email protected]" forged an rmgroup with Subject:
>> "you've got to be kidding", Message-ID:  <[email protected]>, and no other
>> identifying information.
>Possibly the person who origonated that message is afraid that
> will enable administrators to swap info that will keep him
>from playing his little games. If so, more power to it.

[ I hope that nobody on this list thought for a second that that was
me, and that nobody on this list was the person that pulled that
stunt.  If anyone knows who did it, please tell me.  You can't stop
popular movements like even if you try, and I quite
frankly don't want to see it stopped anyway, it will do much more good
than harm (I hope 8-). - neil ]


Date: Sat, 14 Apr 90 04:24:11 PDT
From: uunet!paralogics!shaw (Guy Shaw)
Subject: compress, crypt, and CBW-like codebusters

In Volume 2, issue 11, two people pointed out an unfortunate error in
my posting about crypt and compress:

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

I *hate* it when I do that.  I'm sorry.  I did originally understand
Mr. Mueller to be talking about crypt(compress()), and I wanted to
point out that a fixed magic number is even easier to look for than
statistical profiles.

Charles Green overlooked my blunder (thank you) and addressed my concern.

  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

Ok, so you can make it a little harder. The first 2 bytes are the
magic number, the 3rd byte is number of bits and block-compress flag;
they can be stripped off.  Here is a sample of the first 16 bytes of
12 compressed, saved USENET news articles (comp/lang/c for 1989, one
month each):

  1F9D9046 E4BC6903 228C1C81 6D808481
  1F9D9046 E4BC6903 A2CD9B3A 73CA0069
  1F9D9046 E4BC6903 428D9839 40CC9471
  1F9D9046 E4BC6903 A24E1D37 65E88408
  1F9D9046 E4BC6903 A24E1D37 65E88418
  1F9D9046 E4BC6903 A24E1D37 65E884A0
  1F9D9046 E4BC6903 A24E1D37 65E884A8
  1F9D9046 E4BC6903 A24E1D37 65E88468
  1F9D9046 E4BC6903 A24E1D37 65E88418
  1F9D9046 E4BC6903 A24E1D37 65E88468
  1F9D9046 E4BC6903 A24E1D37 65E88418
  1F9D9046 E4BC6903 A24E1D37 65E884B8

The first 8 bytes are identical, and 9 out of 12 of these files are the same
for the first 15 characters.  This isn't an artificial example; I really did
pick this off the top of my head.  I am cheating, in a way, though, because
all these files start with 'From '.  Security digest, as it is sent now, is a
lot worse; they are all the same in the fist 32 characters, and most are the
same in the first 36 characters, because the all come from the same place.

Ok. I'm still cheating by taking advantage of the fact that these
files start with common information.  But, in the real world, there is
a lot of that going on, especially in published digests with the same
announcement string up front, issue after issue.  Let's make it
harder.  Send your "secure" (ha!)  messages with a line of about 50
characters of random junk in front.  Now, we are getting to the fun
stuff.  My SOID[1] still acts up when I contemplate using this scheme.
Not just any bit patterns constitute a valid compressed file.  I
haven't done measurements, but I think it would not be too expensive,
by cryptanalytic standards, to run trial decompress on the first n
characters of a candidate, just too see if it blows up.  A file
constructed from the 3 bytes of magic followed by random bits ought to
make decompress die quickly (i.e. cheaply).

I think that if this were adopted as a common method for "secure"
communication, it would lull some people into a false sense of
security.  The way I look at it, the burden of proof rests with anyone
who would propose that this is secure, and I do not have to prove that
it is insecure.  Although I have shown, casually, by counter-example
that you can't just use crypt(compress()) naively, because we are
creatures of regular habits.  And, I didn't even have to try hard.

Compress was not designed with security in mind.  Someone can probably show
that, with the proper precautions, crypt(compress()) makes life harder for
crackers.  But, this is still just a palliative.  In the long run, if this
method comes into widespread use, *and* has some measure of success, it will
delay the widespread use of stronger encryption methods - and that's the best
case scenario.

Use stronger encryption methods.  Accept no substitutes (or transpositions :-).
[1] SOID: Originally,   "Sense Of Impending Doom",
          in this case, "Sense Of Impending Decryption"


Date: 18-Apr-90 23:37:17 CST (Wed)
From: uunet!!doug (Doug Davis
Subject: Re: crypt(compress())

Basicly if you just crypt a compressed file you are not providing
much security, the person breaking in is now sure of the first
5 "positions" of your rotor.  This is because of compresses
magic numbers, bit sizes, etc.  Knowing that I *absolutely* know
some of the positions the next set could be figured out by study
of how the compression algorithm works.  The last time I did this
(about three years or so ago) it took about a day to crack a ~30k
compressed file using cbw, calculator, and lots of scratch paper.

Someone also asked if the string of dashes in the security digest
would make it easier to crack it if it was crypted, absolutely,
any reoccuring string of bytes will weaken the structure.

Also if I was presently engaged in "trapping" issues of the digest
from someones account and they started showing up crypted. I could generate
a very good keyword list from the stolen back issues. Chances are
I could get the HEADERS in no time.  The rest would become trivial in
very short order.


Date: Sat, 14 Apr 90 13:58:50 -0400
From: uunet!att!erebus!wcs
Subject: Re: Uutry in HDB

In Digest 2.11,  Bud Hovell <uunet!whizz!bbh> writes
        > [HDB replaces passwd with ???]
        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.
Be careful doing this - you may break Uutry for users!  What happens
is that one user runs "Uutry foovax", leaving the file /tmp/foovax mode 600.
Another user also wants to run "Uutry foovax", but can't because
/tmp/foovax is unreadable/unwriteable.  Before we got System V R3.*
sticky directories, the second user could at least rm /tmp/foovax, but
now that's impossible because it's owned by the first user.

So if you do a modification like this, make sure you use a
uniquely-named tmpfile, such as /tmp/foovax.$$


        End of Security Digest Volume 2 Issue 12