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 #9 1990-03-11 (1 file, 7849 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Sun, 11 Mar 90 02:15:05 PST
Subject: Security Digest V2 #9

Security Digest Volume 2 Issue 9


            Proper email addressing of postings
            * Annex info
            Welcome Banners
            interesting usenet news groups
            Contest announcement
            group ids
            group ids
            * Xterm Security hole [X Windows Ver. 11, Release  3 and 4]

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:                    

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


Date: Sun, 4 Mar 90 23:36:49 PST
From: neil (Neil Gorsuch)
Subject: Proper email addressing of postings

[ Please don't try to second-guess the posting addresses.  The proper
  addresses are "" for normal postings and
  "" for emergency postings.  The
  emergency postings go out to the whole list as a mail expander/reflector
  without any intervention on my part and with no delay (immediately).
  When you send stuff to ...-sendit there is no record kept in the
  official archives, only in the logs on all entry/exit points - neil ]


Date: Tue, 06 Mar 90 22:24:57 EST
From: Gene Spafford <uunet!!spaf>
Subject: * Annex info

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

Thus, having an Annex box (or other terminal server) with unrestricted
conection privileges should be viewed as "rude" in our shared
environment, as well as unwise.  If some major site gets hacked into
through such a server, it might also be considered by corporate
lawyers to be "actionable" -- i.e., civil lawsuits.

On the theory that people out there don't know how to restrict their
Annex boxes, I asked one of our site gurus, Richard Watterson, to
provide an explanation of how we keep our Annex traffic "at home".

Take it away, Richard:

>> If you have a newer version of the Annex erpcd code (like what they
>> ship with the annexII's), you may restrict annex users to certain
>> networks.  You can do this by setting connect_security to Y on the
>> annex, and setting up the proper entries in the file
>> /etc/acp_restrict.   Normally you would want to restrict access to
>> only those hosts on local network(s).  Here is an example acp_restrict
>> file that restricts annex annex01 to accessing only hosts on the
>> 128.10 and 128.211 networks:
>> annex01~ 128.10.*, 128.211.*
>> *:*
>> or to restrict all annexes on network 128.10 to accessing only 128.10
>> and 128.211 networks:
>> 128.10.*~ 128.10.*, 128.211.*
>> *:*
>> The first line reads "all annexes on the 128.10 network (* is wildcard)
>> can access (~ means allowed access to) all hosts on networks 128.10
>> and 128.211".  The second reads no annex anywhere can access (: means
>> don't allow access to what follows) anything anywhere.  This second
>> line will be consulted only if the request is not matched on the first
>> line.
>> If you have an old version of the annex code then you will have to
>> change the source as it did not support wildcards in the
>> /etc/acp_restrict file.  Here is the segment that needs to be changed:
>> ----------------------------------------------------------------------------
>>      /*  Check whether or not this is a restricted host for this Annex  */
>> #ifdef PURDUE_CS
>>      /* Just verify net */
>>      if (((rinet & ntohl(0xffff0000)) == ntohl(0x800a0000)) ||
>>                     /*include hosts on this network ^^^^^^^^ 128.10*/
>>          (rinet & ntohl(0xffff0000)) == ntohl(0x80d30000))
>>                                /* and this network ^^^^^^^^ 128.211 */
>> #else /* !PURDUE_CS */
>>      if(available(linet, rinet))             /* if OK, authorize and log */
>> #endif /* ! PURDUE_CS */
>>      {
>>          (void)annex_to_net_authorize(Acp, REQ_GRANTED);
>>          log_message(linet, logid, port, service, EVENT_LOGIN, String);
>>      }
>>      else                                    /* else reject and log */
>>      {
>> #ifdef PURDUE_CS
>>          outputstring(Acp,"\nSorry, only CS hosts allowed\n\n");
>> #endif /* PURDUE_CS */
>>          (void)annex_to_net_authorize(Acp, REQ_DENIED);
>>          log_message(linet, logid, port, service, EVENT_REJECT, String);
>>      }
>>      /*  terminate (exit()) this session  */
>> ----------------------------------------------------------------------------
>> The PURDUE_CS ifdef delimits the new code.

Questions about this can be directed to


Date: 2 Mar 90 21:14:52 GMT
From: uunet!NIC.DDN.MIL!SCC
Subject: Welcome Banners

[ This is from DDN Security Bulletin 90-04 - neil ]


1.  The Defense Communications Agency/Data Systems Management
Division (DDO) is in the process of fielding a patch to all
Defense Data Network (DDN) Terminal Access Controllers (TACs)
that will remove the DDN "Welcome" banners.  This is being
accomplished as a security measure for the following
principle reasons:

   a.  To terminate the identification of the system as belonging to
the DDN/MILNET, and to terminate the identification of the type of
operating system or software in use on the system.  All too often
intruders stumble by chance upon a MILNET host because the system is
identified in the banner as being "defense" and/or "For Official Use
Only".  Intruders can also use software or operating system
information from the banner to facilitate an intrusion.  Therefore,
it is best not to identify a system at all in its banner.

   b.  A court recently threw out a suit against a computer system
intruder because the logon prompt was preceded with "Welcome to...".

2.  Request Host Administrators and other addressees, in favor of
tighter security, take an active role in getting their
commands/units/organizations to change existing logon banners to
make certain that the identity of their data systems is not displayed,
and to halt the use of "Welcome".


Date: Mon, 5 Mar 90 09:17:45 PST
From: neil (Neil Gorsuch)
Subject: interesting usenet news groups

[ There are currently some very interesting discussions in the usenet news
  group comp.dcom.telecom about hackers and justice department seizures.
  Check it out 8-). - neil ]


Date: Tue, 06 Mar 90 15:49:12 EST
From: Gene Spafford <uunet!!spaf>
Subject: Contest announcement

The National Center for Computer Crime Data notes with interest the
considerable controversy engendered by the trial and guilty verdict in
the case of Robert T. Morris.  In order to expand and focus the
conversation, we announce the "If I were the Robert Morris case judge"
essay contest.  We will award $100 to the best essay of 250 words or
less suggesting the appropriate sentence for Mr. Morris.

Security Magazine has agreed to publish the winning essay in its May
issue.  Contestants need not be familiar with the federal guidelines
for sentencing, but should assume, for the purpose of their essay,
that the judge can impose any sanctions he or she thinks reasonable.
All essays must be received by the National Center for Computer Crime
Data, 1222-B 17th Avenue, Santa Cruz, CA, 95062 by March 28, 1990.

J.J. Buck BloomBecker, Esq.

[The real sentencing for Mr. Morris will be May 4.
I am not affiliated in any way with the NCCCD  --spaf]


Date: Thu, 08 Mar 90 21:52:26 -0500
From: uunet!!pezely
Subject: group ids

There was a lot of messages about PC NFS security problems in the last
Security Digest.  I don't know about PC NFS, but here's a problem along
similar lines.

One problem I've seen on a Sun client workstation is having group id
mismatches with what the client says and what the server says.

On one client, the two group id's of `staff' and `other' were switched.
I was a member of the `staff' group, but not the `other' group.  Suddenly,
I could access stuff from the client which I may not have been supposed to
see and couldn't normally see from the server.  It didn't matter since I
had root priv's anyway, but you get the idea.

My point is, what's to stop a client from playing around with /etc/group ?
I don't know how far this could go, but is a potential problem.

This was on a Sparcstation running SunOS 4.0.3 with the 3/180 server running
the same version.


Date: Sat, 10 Mar 90 03:31:24 EST
From: Seth Robertson <uunet!!seth>
Subject: group ids

>My point is, what's to stop a client from playing around with /etc/group ?
>I don't know how far this could go, but is a potential problem.

There is nothing to stop a client.  You should probably make sure that
people cannot become root on the clients to change things, but what
I do for /etc/passwd, /etc/group and a few other files is to keep a
generic client version in a directory on my server and use rdist or
rcp to distribute them out to the various clients.

NOTE: If you do this, be very, very sure that you do not accidently
distribute the generic password file to the server.  It might be
slightly annoying if you had to manually regenerate your entire
password file :-)


Date: Tue, 6 Mar 90 13:32:54 EST
From: "Scott E. Schwartz" <uunet!!schwartz>
Subject: crypt/CBW

|       1) Hackers know about this list and have placed a "premium" on getting
|       copies of the list mailings.  If you have old copies on disk, encrypt
|       them so that if someone does break in, they can't get them.

Unfortunately, they also know about the "Code Breakers Workbench",
available by ftp from uunet.  The unix crypt command is very very very
easy to break, especially given lengthy traffic with standard headers
like this list has.   It really is time for a DES based crypt(1).
(Ironically, we recently caught some intruders and had occasion to
use cbw to decrypt files that _they_ thought were safely encoded.  It
cuts both ways, I guess.)


Date: 5 Mar 90 13:55:06 PST (Mon)
From: elroy!zorch.SF-Bay.ORG!scott (Scott Hazen Mueller)
Subject: crypt/CBW

I was always under the impression that what CBW did was iterate to a
decryption by relying on typical frequency counts and presenting the user
with sample output for various keys.  If this 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?  not to mention the saved disk space..


Date: Mon, 05 Mar 90 09:04:01 -0500
From: Matt Bishop <uunet!!bishop>
Subject: crypt/CBW

   If anyone wants it, there is an implementation of DES with all four
modes recommended in FIPS 81 (ECB, CBC, CFB, OFB) available for anonymous
ftp from (login anonymous password your-id).  Source
is ~ftp/pub/cdes.c and the manual page is ~ftp/pub/cdes.1.  THIS DOES NOT
   One fudge: CFB and OFB require the size of the parameter to be a multiple
of 8.  This is because it's hard to do 5-bit CFB, and I wrote this thing
as a one-day hack when some $%^@&$* broke into our machine.  If anyone wants
to add that, please send me the mods! (As Scott pointed out, crypt(1) just
doesn't cut it.)
   A warning: no warranty, etc.  So check the encryption before tossing the
plaintext.  If you find a problem, let me know; I don't know of any, but ....
Also, if you lose your key, you're on your own; the NSA may -- MAY -- know how
to recover a key from a known plaintext, or ciphertext only, attack, but I
sure don't!


Date: Fri, 9 Mar 90 15:49:28 -0500
From: uunet!!parmelee (Larry Parmelee)
Subject: * Xterm Security hole [X Windows Ver. 11, Release  3 and 4]

[ This is the last message because of it's length, if you don't use X
windows, you're done with this digest - neil ]

The xterm terminal emulator provided as part of X windows has a rather
bad security hole.  This problem exists in X version 11, both releases
3 and 4, and possibly other versions as well.

This problem was originally found by Hakon W Lie
<>, whose report found its way to me via
a mutual acquaintance.  I have worked out a source-code patch to close
the hole in X11 release 4, a similiar patch should work for release 3.

To the best of my knowledge, this bug has not been used in a
malicious or harmful way by anyone, but the potential is frightening.

The xterm emulator has a feature that allows a user to keep a logfile
of what's been typed in the xterm window.  The feature also allows
a command to be specified as the logfile, in which case what would
normally be written to the logfile is instead  written to the input
of the given command (standard UNIX-style pipeline setup).  The
security hole arises because the xterm emulator defines some escape
sequences which can be sent to the xterm window to control the
logging feature: turning logging on or off and changing the logfile
name.  These escape sequences could conceivably be embedded in a mail
message, and the message sent to a victim.  If the victim displays the
message in an xterm window (for example by running mail from within
an xterm window), the escape sequences will effectively cause the
victim to run whatever commands the attacker wishes.  The victim will
probably be unaware of the attack, since the escape sequences are not
displayed in the xterm window.

The following is a test file; the control codes that would make let this
make use of the bug have been changed into harmless characters, namely the
ascii "esc" code "^[" has been replaced by "$" and the ascii "bel" code
"^G" has been replaced by "%".

-------File:  xterm.test1 ---- Cut  here-----
Set log file name

Turn Logging ON
Well,. what now?
testing one two three

Turn Logging Off

set a new logfile (a command, actually)
$]46;|/bin/mail `whoami` < /tmp/foobar%

Turn logging on, i.e. execute that command!

Turn Logging Off

set logfile name back to something harmless
-------File:  xterm.test1 ---- END

If you're on a UNIX system, you can test your xterm by saving the above
text in a  file and using the "tr" command to restore the proper control
        tr '$%' '\033\007' < xterm.test1

If the above command is run in an xterm window, the effect will be to
set the log file name to "/tmp/foobar", then turn logging on.  The next
few lines  will be written to "/tmp/foobar",  then logging is turned
off.  Then, a new log file name is given: since the "filename" begins
with a vertical  bar "|", it's actually a command.  When logging is
again turned on, the command "/bin/mail `whoami` < /tmp/foobar" will be
executed, which will have the effect of mailing the "/tmp/foobar" file
to the current user.  Logging is then turned off and the logfile name
reset to something harmless, so that turning logging on again at some
future time will have no unexpected  effect.

The following patch closes the hole by disabling the xterm code that
interprets the escape sequences dealing with the logging feature.  It
does this by enclosing the code in "#ifdef <a presumably undefined symbol>"
"#endif" pairs.  You may  wish to actually delete the enclosed code,
or use a different undefined symbol name, especially if you keep the
X sources in publically accessable areas.  It's probably not a good
idea to give wandering eyes any unnecessary  hints.

This patch also adds a length check to prevent overflowing  a buffer
when interpreting escape sequences to change the title bar name or
the Icon name on the xterm window.

*** /tmp/,RCSt1a16140   Fri Mar  9 13:27:25 1990
--- mit/clients/xterm/charproc.c        Wed Mar  7 11:36:22 1990
*** 1488,1493 ****
--- 1488,1494 ----
                        (*func)(&term->flags, REVERSEWRAP);
+ #ifdef SecurityHole
                case 46:                /* logging              */
                        if(func == bitset)
*** 1494,1499 ****
--- 1495,1501 ----
+ #endif
                case 47:                /* alternate buffer             */
                        if(func == bitset)
*** 1567,1575 ****
--- 1569,1579 ----
                case 45:                /* reverse wraparound   */
                        screen->save_modes[13] = term->flags & REVERSEWRAP;
+ #ifdef SecurityHole
                case 46:                /* logging              */
                        screen->save_modes[14] = screen->logging;
+ #endif
                case 47:                /* alternate buffer             */
                        screen->save_modes[15] = screen->alternate;
*** 1686,1691 ****
--- 1690,1696 ----
                        term->flags |= screen->save_modes[13] & REVERSEWRAP;
+ #ifdef SecurityHole
                case 46:                /* logging              */
*** 1693,1698 ****
--- 1698,1704 ----
                        /* update_logging done by StartLog and CloseLog */
+ #endif
                case 47:                /* alternate buffer             */
*** /tmp/,RCSt1a16143   Fri Mar  9 13:27:51 1990
--- mit/clients/xterm/misc.c    Wed Mar  7 13:16:29 1990
*** 531,537 ****
                mode = 10 * mode + (c - '0');
        if (c != ';') okay = False;
        cp = buf;
!       while(isprint((c = (*func)()) & 0x7f))
                *cp++ = c;
        if (c != 7) okay = False;
        *cp = 0;
--- 531,537 ----
                mode = 10 * mode + (c - '0');
        if (c != ';') okay = False;
        cp = buf;
!       while(isprint((c = (*func)()) & 0x7f) && cp < &buf[sizeof buf - 1])
                *cp++ = c;
        if (c != 7) okay = False;
        *cp = 0;
*** 549,554 ****
--- 549,555 ----

+ #ifdef SecurityHole
         case 46:       /* new log file */
                if((cp = malloc((unsigned)strlen(buf) + 1)) == NULL)
*** 557,562 ****
--- 558,564 ----
                screen->logfile = cp;
+ #endif

        case 50:
                SetVTFont (fontMenu_fontescape, True, buf, NULL);


        End of Security Digest Volume 2 Issue 9