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 #10 1990-03-30 (1 file, 21276 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/210.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Fri, 30 Mar 90 02:17:48 PST
Subject: Security Digest V2 #10

Security Digest Volume 2 Issue 10

subject(s):

            POSSIBLE LIST CHANGES
            Internet Intruder Warning
            Re: Annex boxes
            Re: Annex boxes
            Re: Annex Boxes
            Re: Annex Boxes
            annex
            lattelnet break-ins
            SunOS pty's (the real problem) (long)
            answering machines vs. call back modems
            How to make answering machines deliver ransom messages
            SunOS 4.0.3 UUCICO problems, WIDE open
            Re: CBW
            crypt/CBW
            Re: crypt/CBW
            crackers and passwords
            Re:  More hacker signs - probably the same ones
            Fwd:
            archiving security
            password checking program wanted
            Possible problem with Intergraph Soft-PC
            Potential problem with Intergraph PC Emulator
            I just had the oddest phone call...
            YP passwd bugs - SunOS 4.0.3
            Re: * Xterm Security hole [X Windows Ver. 11, Release  3 and 4]
            Re: Xterm Security hole [X Windows Ver. 11, Release  3 and 4]
             fixes/6

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, 30 Mar 90 00:55:58 PST
From: neil (Neil Gorsuch)
Subject: POSSIBLE LIST CHANGES

[ Because of certain recent events, I am considering some major changes
  to the security list, including a possible paring down of the list
  membership.  Also, uninet.cpd.com itself will join the internet as
  soon as I have time to hook it up (the hardware and leased line have
  been sitting around for over a month now).  That will also play a part
  in the changes I am contemplating. - neil ]

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

Date: Mon, 19 Mar 90 15:42:52 EST
From: "J. Paul Holbrook" <uunet!CERT.SEI.CMU.EDU!ph>
Subject: Internet Intruder Warning

                            CERT Advisory
                            March 19, 1990
                      Internet Intruder Warning

There have been a number of media reports stemming from a March 19 New York
Times article entitled 'Computer System Intruder Plucks Passwords and
Avoids Detection.'  The article referred to a program that attempts to
get into computers around the Internet.

At this point, the Computer Emergency Response Team Coordination
Center (CERT/CC) does not have hard evidence that there is such a
program.  What we have seen are several persistent attempts on systems
using known security vulnerabilities.  All of these vulnerabilities
have been previously reported.  Some national news agencies have
referred to a 'virus' on the Internet; the information we have now
indicates that this is NOT true.  What we have seen and can confirm is
an intruder making persistent attempts to get into Internet systems.

It is possible that a program may be discovered.  However, all the
techniques used in these attempts have also been used, in the past, by
intruders probing systems manually.

As of the morning of March 19, we know of several systems that have
been broken into and several dozen more attempts made on Thursday and
Friday, March 15 and 16.

Systems administrators should be aware that many systems around the
Internet may have these vulnerabilities, and intruders know how to
exploit them.  To avoid security breaches in the future, we recommend
that all system administrators check for the kinds of problems noted
in this message.

The rest of this advisory describes problems with system
configurations that we have seen intruders using.  In particular, the
intruders attempted to exploit problems in Berkeley BSD derived UNIX
systems and have attacked DEC VMS systems.  In the advisory below,
points 1 through 12 deal with Unix, points 13 and 14 deal with the VMS
attacks.

If you have questions about a particular problem, please get
in touch with your vendor.

The CERT makes copies of past advisories available via anonymous FTP
(see the end of this message).  Administrators may wish to review
these as well.

We've had reports of intruders attempting to exploit the following
areas:

1) Use TFTP (Trivial File Transfer Protocol) to steal password files.

   To test your system for this vulnerability, connect to your system
using TFTP and try 'get /etc/motd'.  If you can do this, anyone else
can get your password file as well.  To avoid this problem, disable
tftpd.

   In conjunction with this, encourage your users to choose passwords
that are difficult to guess (e.g. words that are not contained in any
dictionary of words of any language; no proper nouns, including names
of "famous" real or imaginary characters; no acronyms that are common
to computer professionals; no simple variations of first or last
names, etc.)  Furthermore, inform your users not to leave any clear
text username/password information in files on any system.

   If an intruder can get a password file, he/she will usually take it
to another machine and run password guessing programs on it. These
programs involve large dictionary searches and run quickly even on slow
machines.  The experience of many sites is that most systems that do
not put any controls on the types of passwords used probably have at
least one password that can be guessed.

2) Exploit accounts without passwords or known passwords (accounts
with vendor supplied default passwords are favorites).  Also uses
finger to get account names and then tries simple passwords.

   Scan your password file for extra UID 0 accounts, accounts with no
password, or new entries in the password file.  Always change vendor
supplied default passwords when you install new system software.

3) Exploit holes in sendmail.

   Make sure you are running the latest sendmail from your vendor.
BSD 5.61 fixes all known holes that the intruder is using.

4) Exploit bugs in old versions of FTP; exploit mis-configured
   anonymous FTP

   Make sure you are running the most recent version of FTP which is
the Berkeley version 4.163 of Nov.  8 1988.  Check with your vendor
for information on configuration upgrades.  Also check
your anonymous FTP configuration.  It is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.).  Note especially that you should not use your
system's standard password file as the password file for FTP.

5) Exploit the fingerd hole used by the Morris Internet worm.

   Make sure you're running a recent version of finger.  Numerous
Berkeley BSD derived versions of UNIX were vulnerable.

Some other things to check for:

6) Check user's .rhosts files and the /etc/hosts.equiv files for systems
outside your domain.  Make sure all hosts in these files are
authorized and that the files are not world-writable.

7) Examine all the files that are run by cron and at.  We've seen
intruders leave back doors in files run from cron or submitted to at.
These techniques can let the intruder back on the system even after
you've kicked him/her off.  Also, verify that all files/programs
referenced (directly or indirectly) by the cron and at jobs, and the
job files themselves, are not world-writable.

8) If your machine supports uucp, check the L.cmds file to see if
they've added extra commands and that it is owned by root (not by uucp!)
and world-readable.  Also, the L.sys file should not be world-readable
or world-writable.

9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
entries.  Some alias files include an alias named 'uudecode'; if this
alias exists on your system, and you are not explicitly using it, then
it should be removed.

10) Look for hidden files (files that start with a period and are
normally not shown by ls) with odd names and/or setuid capabilities,
as these can be used to "hide" information or privileged (setuid root)
programs, including /bin/sh.  Names such as '..  ' (dot dot space
space), '...', and .xx have been used, as have ordinary looking names
such as '.mail'.  Places to look include especially /tmp, /usr/tmp,
and hidden directories (frequently within users' home directories).

11) Check the integrity of critical system programs such as su, login,
and telnet.  Use a known, good copy of the program, such as the
original distribution media and compare it with the program you are
running.

12) Older versions of systems often have security vulnerabilities that
are well known to intruders.  One of the best defenses against
problems is to upgrade to the latest version of your vendor's system.

VMS SYSTEM ATTACKS:

13) The intruder exploits system default passwords that have not been
changed since installation.  Make sure to change all default passwords
when the software is installed.  The intruder also guesses simple user
passwords.  See point 1 above for suggestions on choosing good
passwords.

14) If the intruder gets into a system, often the programs
loginout.exe and show.exe are modified.  Check these programs against
the files found in your distribution media.

If you believe that your system has been compromised, contact CERT via
telephone or e-mail.

J. Paul Holbrook
Computer Emergency Response Team (CERT)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
           7:30a.m.-6:00p.m. EST, on call for emergencies
            other hours.

Past advisories and other information are available for anonymous ftp
from cert.sei.cmu.edu (128.237.253.5).

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

Date: Sun, 11 Mar 90 21:16:02 -0800
From: uunet!ucsd.edu!brian (Brian Kantor)
Subject: Re: Annex boxes

In the anonymous FTP area of UCSD.EDU you will find a set of diffs to
apply to the Xylogics/Annex 4.1 erpcd source that makes for a little
bit more flexible security control policy.

What we have done is add a third case to the security switch.  The
original software allows one to deny or allow access based on addresses
(some or all of which may be wildcarded).  We have added a third case
that demands a login and password before allowing access.  That way we
allow dial-up access to many of our campus hosts, deny dial-up access
to other hosts and certain networks, and demand that the user supply a
login and password before he may gain access to the rest.  The means
that all Internet access from UCSD is (in theory, anyway) validated: a
user cannot access the internet without having logged on either to a
campus host which has access, or logged on to the Annex.  It also saves
us from having to issue dial-in logins and passwords for every student
with a modem - as they can access the couple of dozen machines on which
classwork is done directly.

For a quick hack it's quite acceptable.

The Annex code uses the same password mechanism as normal Unix systems
do, which allows us to use all of the normal Unix tools to manage the
authorization file, and which, by the same token, opens us up to the
same attacks.  I think it's good enough, at least for now.

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

Date: Mon, 12 Mar 90 19:46:32 PST
From: uunet!oce.orst.edu!pvo (Paul O'Neill)
Subject: Re: Annex boxes

Equally disturbing is the ability to telnet *into* an annex from the
internet and then back out again.  Very useful for someone trying to
cover their tracks.  This is what the "modified telnet" cracker was
doing about 6 months ago.  We traced him to our annex, then back to a
cisco on the east coast, then .....  "rats, he's logged off already."
No accounting records.  To catch someone doing this you must be
notified immediately of an incoming telnet to your annex (I know of no
valid reason to be telneting *into* an annex) and start tracing back
immediately.  I don't administer our annexes, and don't understand why
we can't turn off incoming telnets, but we can't.

So I wrote this little perl script.  It is run by cron every minute.
It sends mail to appropriate people if someone is telneting in, and
automatically does the first level of traceback (via `finger' and
`rusers').  This data is included in the mail message.

(Notice that you don't have to log into an annex and do a "who"
command.  It's much quicker to just "finger @annex".

(So far it's only caught CERT personal!!)

------------------------------------------
#!/usr/bin/perl

#       fannex
#       11 mar 90
#       finger annex for incoming internet login

#       Paul V. O'Neill
#       Coastal Imaging Lab
#       OSU, Corvallis, OR 97331


$SEC_HONCHO = 'root@homeck.podunk.edu';   ###### CONFIG FOR YOUR SITE #####
@ANNEXES = ('annex5', 'annex10');         ###### CONFIG FOR YOUR SITE #####

for(@ANNEXES) {

    @x = split(/\n/, `finger @$_`);
    $annexid = shift @x;
    $header = shift @x;
    $offadd = index($header, 'Address');
    $i = 0;
    for(@x) {
        $i++;
        chop;
        $add = sprintf("%-16s", substr($_, $offadd, 16));
#        print  "$add\n";
        if( $add =~ /\d*\.\d*\.\d*\.\d*/ ) {
########## COMMENT OUT THE NEXT 2 LINES FOR TESTING ##############
            open(MAIL, "| /usr/ucb/mail -s annex $SEC_HONCHO");
            select(MAIL);
            print "$annexid\n";
            print "$header\n";
            print "$_\n";
            print "$x[$i]\n\n";
            do who_fing();
            do who_ru();
            close(MAIL);
        }
    }
}

sub who_fing
{
    $at = '@';
    @users = `finger @$add`;
    $hostname = `/usr/local/bin/hname $add`;
    $hostname =~ /= (.*)$/;
    $host = $1;
    print  "@users\n";
    print  "$hostname\n";
    1;
}


sub who_ru
{
    @users2 = `rusers -l $host`;
    print  @users2;
}

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

Date: Tue, 13 Mar 90 12:54:34 EST
From: uunet!cs.purdue.edu!trinkle
Subject: Re: Annex Boxes

     If you are running Annex-UX R4.1 (and possibly earlier versions
as well), you only need to set the annex parameter "enable_security"
to Y.  With security enabled, if you telnet to the annex and then
select the "cli" rotary, it will request a username and a password
before you are allowed CLI access.

     Note that this does not restrict access on any of the serial
lines (coming IN through the serial line) unless they have one of
"cli_security", "connect_security", or "port_server_security" turned
on.  If you are using a serial line rotary and telnet TO the annex to
get access to the serial rotary, there may be some restrictions.  We
do not use this locally and cannot conveniently test it.

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

Date: Thu, 15 Mar 90 18:51:18 PST
From: uunet!oce.orst.edu!pvo (Paul O'Neill)
Subject: Re: Annex Boxes

Yikes!!  I haven't gotten so much mail in ages.

OK -- Most folks can and do easily lock up annexes to incoming telnets.

HOWEVER --
1) Some folks want or need incoming telnet access and want to run "fannex".

2) If you have been attacked from a poorly administered annex at another
   sight, you will want to run "fannex" pointing it at *that* annex, not one
   of your own, to catch the cracker on his next attempt.

It has been pointed out to me that fannex requires a very recent version
of perl (3.0 patchlevel 12). (patchlevel 15 is current)

Here is a version that runs at 3.0 patchlevel 8 and maybe lower:

Also -- here is the source to hname.  Needed for IP address -> host name
resolution and the 'rusers -l' call.  This is an extremely handy tool to
have on hand.  Basically an nslookup reverse-pointer query without all the
hairball syntax.

Here is a typical mail message from fannex:
    -----------------------------------------------------------------------
>From root@homeck.podunk.edu Thu Mar 15 18:30:05 1990
To: root@homeck.podunk.edu
Subject: annex

[badannex@HARVARD.EDU]
Port What User             Location          When         Idle  Address
 v1  CLI  ---              ---               9:29pm             128.193.64.35


[128.193.64.35]
Login       Name              TTY Idle    When    Where
pvo      Paul O'Neill          co      Thu 15:32

128.193.64.35 = sapphire.OCE.ORST.EDU

pvo      sapphire.OCE:console  Mar 15 15:32

    --------------------------------------------------------------------
        [ ooopps -- busted !! :-) ]
    --------------------------------------------------------------------------

# This is a shell archive.  Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by sapphire!pvo on Thu Mar 15 18:36:26 PST 1990
# Contents:  fannex hname.c

echo x - fannex
sed 's/^@//' > "fannex" <<'@//E*O*F fannex//'
#!/usr/bin/perl

#       fannex
#       11 mar 90
#       finger annex for incoming internet login

#       Paul V. O'Neill
#       Coastal Imaging Lab
#       OSU, Corvallis, OR 97331

# 15 may 90
# indirect the '@' for older perls

$SEC_HONCHO = 'root@homeck.podunk.edu';   ###### CONFIG FOR YOUR SITE #####
@@ANNEXES = ('annex5', 'badannex@harvard.edu'); ##### CONFIG FOR YOUR SITE #####
$at = '@';
for(@ANNEXES) {

    @x = split(/\n/, `finger $at$_`);
    $annexid = shift @x;
    $header = shift @x;
    $offadd = index($header, 'Address');
    $i = 0;
    for(@x) {
        $i++;
        chop;
        $add = sprintf("%-16s", substr($_, $offadd, 16));
#        print  "$add\n";
        if( $add =~ /\d*\.\d*\.\d*\.\d*/ ) {
########## COMMENT OUT THE NEXT 2 LINES FOR TESTING##############
            open(MAIL, "| /usr/ucb/mail -s annex $SEC_HONCHO");
            select(MAIL);
            print "$annexid\n";
            print "$header\n";
            print "$_\n";
            print "$x[$i]\n\n";
            do who_fing();
            do who_ru();
            close(MAIL);
        }
    }
}

sub who_fing
{
    $at = '@';
    @users = `finger $at$add`;
    $hostname = `/usr/local/bin/hname $add`; #### wants hname in /usr/local/bin
    $hostname =~ /= (.*)$/;
    $host = $1;
    print  "@users\n";
    print  "$hostname\n";
    1;
}


sub who_ru
{
    @users2 = `rusers -l $host`;
    print  @users2;
}
@//E*O*F fannex//
chmod u=rw,g=rw,o=r fannex

echo x - hname.c
sed 's/^@//' > "hname.c" <<'@//E*O*F hname.c//'
#include <ctype.h>
#include <stdio.h>
#include <sys/types.h>
#include <netdb.h>
#include <sys/socket.h>

main(argc, argv)
char **argv;
{
        int i;
        if (argc == 1)
        {
                char string[80];

                while (! feof(stdin))
                {
                        printf("> ");
                        fflush(stdout);
                        lookup(gets(string));
                }
        }
        else
                for (i=1; i<argc; i++)
                        lookup(argv[i]);
}

lookup(string)
char *string;
{
        struct hostent *hp, *gethostbyaddr();
        long            addr, inet_addr();

        if (! string || ! isdigit(string[0]))
                return;
        addr = inet_addr(string);
        hp = gethostbyaddr(&addr, sizeof(addr), AF_INET);
        if (hp == (struct hostent *)NULL)
                printf("%s not found\n", string);
        else
                printf("%s = %s\n", string, hp->h_name);
}

@//E*O*F hname.c//
chmod u=rw,g=r,o=r hname.c

exit 0

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

Date: Wed, 7 Mar 90 22:13:50 EST
From: a.e.mossberg <uunet!mthvax.CS.Miami.EDU!aem>
Subject: lattelnet break-ins

Up until several days ago I was running a lattelnet service on our
Microvax II, which allowed people who signed on to a DECserver (either
via a hard-wired terminal or modem) to connect to an arbitrary TCP/IP
host (subject of course to network accessibility). Apparently someone
was using the service to break in to MOSAIC-PLUS.AF.MIL through my machine,
because I got a call from its system administrator and a officer from
Defense Intelligence Agency. The lattelnet service (which comes with
the Ultrix operating system beginning, I think, with version 2.2) has
no capability for password security, or restricting which hosts someone
can connect to.  After requests from our DEC software coordinator, we
were able to get a patched version of /usr/ucb/telnet, which logged
the port and DECserver identification of lattelnet connections. Repeated
abuse of the service has prompted me to disable it.

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

Date: Mon, 26 Feb 90 15:23:12 EST
From: Viktor Dukhovni <uunet!math.Princeton.EDU!viktor>
Subject: SunOS pty's (the real problem) (long)

        A number of posters to this list have pointed out a security hole
associated with SunOS pty's and background processes waiting to read them.

        And indeed I was quite surprised that to be able to read input
from idle pty's after someone connects.

        The reason for my surprise is that this is not caused
permissions of the pty itself.  Users ought to be able to open pty
master/slave pairs, but it should always be the case that the open on
the master side shuts down any streams associated with the slave side
hanging around from previous sessions, a read on a PTY after the
master is closed and reopened should return EIO.  ( Thus one should
always open the master first! )

        Granted  shelltool etc.,  ought to fchown(slave,user,tty)  and
fchmod(slave,0660),  this would allow only "biff" and "talk" access to the
terminal and the user to change the mode to disable either or both.  I have
modified the shelltool/cmdtool/tektool here to run setuid and chown the tty
to the user in question make the utmp entry as "root" and then revoke
the privs before forking the user shell.  This allows us to have a more 644
/etc/utmp file,  closing the utmp hole the right way!  I have sent my fixes
to sun,  they said they are working on something similar,  don't know
when they will release a working setuid window system.

        No messing around with permissions will be able to close the PTY
driver hole,  since the "cracker" can telnet to a port,  leave a background
job running and log out.  This will be much harder to exploit under POSIX
style terminal sessions due out in 4.1,  so Fixed in 4.1 :-)
        Apart from the ability to read other user's input,  a much more
serious problem enables one to *generate* input on all tty's psuedo
or otherwise.   This problem is common to all Berkeley derived terminal
drivers.  And causes a serious security hole on DecStations,  Suns,  Berkeley
vaxen,  etc.  There is no *simple* fix.  Again POSIX sessions to the rescue
fixed in BSD4.4

        In the interim we all have to live with cheese cloth for security
the terminal drivers,  let's keep those fingers crossed...

        A related problem in the PTY driver was the "half-remote" pty's
left behind by cmd-tools under 4.0,  this caused hanging telnet sessions
or one's that exited at the first character typed (depending on the user's
setting of "filec").

        I will include the 4.0 note below,  though it recommends a fix
for the half-remote problem,  the real solution should be to shut down
the slave side completely inside ptcopen().

Included-From: auspex!guy@uunet.uu.net (Guy Harris)

If you get a pseudo-tty into the state where it acts as if "every
character typed is a ^D", or "it runs billions of 'ls'es", or something
like that, or get it into a state where it isn't in "raw" or "no-echo"
mode but doesn't echo what you type, under 4.0, it's probably because it's
gotten into an invalid "half-remote mode" state.

Basically, "cmdtool" puts it into "remote mode", which is described (to
some degree) in PTY(4).  If you ran something from the "cmdtool" in the
background, and left it around after you quit from the "cmdtool", it holds
the "slave" side of the pty in remote mode, but not the master side.

The "remote" mode explains the seeming "raw, no-echo" state; the "every
character typed is a ^D" stuff seems to come from the bizarre stuff the C
shell does when you do "set filec", and the "billions of 'ls'es" are just
the C shell's response to an end-of-file (^D) when not at the end of the
line - it's showing you the options for the file name you're trying to
complete.

There is a fix; I've mentioned it to Sun.  (For those of you with source
and an adventurous spirit, you want to make the pseudo-tty
master/controller open routine "ptcopen" send an M_CTL streams message
with an MC_DOCANON code upstream on the slave side if it's open and has a
stream; check out the code in "ptcioctl" that handles a TIOCREMOTE "ioctl"
with a zero argument.  I've not tried this, but I think it should fix it;
if it blows up and scribbles "I am a duck" all over your root file system,
don't ask me about it.)

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

Date: Thu, 15 Feb 90 10:03:45 PST
From: Ritchey Ruff <uunet!turing.CS.ORST.EDU!ruffwork>
Subject: answering machines vs. call back modems

In risks 9.68 Denis Coskun  <dcoskun%alias@csri.utoronto.ca>
tells how to use an answering machine as a phone message relay
(I include the two messages below).
A computer security issue about this is it could possibly be used to
defeat a modem callback security system.  If the machine records
touch tones it will probably record low baud rate modem tones
(300 or 1200 baud).

The following is a portion of the entire V9.I68 RISKS Digest:

In RISKS-7.69 Vince Manis tells us that his General Electric
answering machine has only 256 possible access codes for remote
message retrieval.  I have the same machine.  Valid combinations
are 3 consecutive touch tones of the form [0-7][0-7][0-3].

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 (for example, if the code is
a triplet composed of just the numbers 1 and 2 then the string
1211122212 contains all eight triplets)."

The shortest string of digits that I was able to generate for
defeating my answering machine was 452 digits:

000100200301101201302102202303103203304004104204305005105205
306006106206307007107207311121131221231321331401411421431501
511521531601611621631701711721732223233240241242243250251252
253260261262263270271272273330034034134234335035135235336036
136236337037137237344044144244345045145245346046146246347047
147247354054154254355055155255356056156256357057157257364064
164264365065165265366066166266367067167267307407417427437507
51752753760761762763770771772773

DTMF decoding chips are required to recognize a tone as short
as 50 milliseconds with an interdigit interval of another 50
milliseconds, making a total of 100 ms for each digit.  So the
whole 452 digit string could be dialed within 45.2 seconds
using a demon dialer.  Since my answering machine will wait a
minute or more while you leave a message, it could be cracked
with just one phone call.

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?

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.

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

Date: Fri, 9 Feb 90 20:22:57 est
dcoskun@alias (Denis Coskun)   <dcoskun%alias@csri.utoronto.ca>
Subject: How to make answering machines deliver ransom messages

I discovered a security weakness that would allow you to trick
answering machines with remote message retrieval into making phone
calls and delivering untraceable ransom messages!

Here's how:

Dial someone's answering machine and leave a message with the format:
1.  14 seconds of nonsense talking (to keep the tape running)
2.  dial, say, 555-1234 using touch tones (which will be recorded)
3.  a few more seconds of random talking
4.  finally your ransom message

Now dial the security code (which you discovered as described in my
companion article) to get the answering machine to play back the
messages.  As soon as you hear the start of your nonsense message,
hang up.  The machine will continue playing the messages, oblivious
to the fact that no one is listening.  The telephone exchange will
supply dial tone to the answering machine's line 12 seconds after
you hang up (12 seconds at my exchange).  Two seconds later, the
answering machine will play the recorded touch tones 555-1234,
effectively dialing that number.  A few seconds later, the person
at 555-1234 answers and your message is delivered!  And it cannot
be traced to you.

Of course, you would call back the answering machine and clean
up the evidence.

I believe that the technique will work on all answering machines
with remote message retrieval provided that:

1. You have the security code (see my other posting about how good
   these are).

2. The exchange will supply dial tone to the callee after the
   caller hangs up.  This is true on all modern switches.

3. The phone line of the answering machine permits touch tone
   dialing.  This is a way to secure your answering machine:
   switch to pulse dialing only service.

4. The machine and its tape reproduce touch tones with enough
   fidelity.  Mine do.

5. The machine will ignore dial tone.  There are no guaranteed
   electrical changes on the line when a caller hangs up, so
   watching for dial tone would be the only reliable indicator,
   which my machine ignores.

6. The machine will record touch tones.  Mine will record
   everything (except that the 3 digit security code gets it to
   play back the messages).  The security hole could be plugged if
   the machine would stop recording as soon as it got any touch tone.

7. The machine will play all touch tones recorded on its tape.
   I did have some trouble here since the machine cannot tell if
   a tone is coming from the tape or from the caller on the line.
   During playback, my machine will interpret a "1" as a command to
   fast forward and "3" to fast reverse, and thus disrupt the
   dialing if these digits are part of the number.

A more likely hazard than untraceable ransom messages is the relaying
of long distance messages that are charged to some innocent answering
machine owner, or harassing the owner by having him billed for
random toll calls (long distance, overseas, 976, 900, etc.).

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

Date: Fri, 2 Mar 90 15:37:53 EDT
From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
Subject: SunOS 4.0.3 UUCICO problems, WIDE open

It appears (at least at my site) that the uucico distributed with SunOS 4.0.3
is a little wide open.  Me, as a normal user, executed the command:
        /usr/lib/uucp/uucico -r1 -ssysname -x5
and it proceded to show me the debug output from the call, INCLUDING the phone
number, login name, and password used, on the remote machine!  On standard
Berkeley UUCP's (with 4.2 and 4.3) it doesn't allow non-root to use the -x
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 ????).

With SUNs way of doing things, anyone who has access to your SUN can execute
the uucico command, grab the output from the debug portion, and then have
another number and login to try to break.  Maybe this isn't as big a problem
as I feel it is.  What are your opinions?

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

Date: Sun, 4 Mar 90 14:14:32 EST
From: John Robert LoVerso <uunet!Xylogics.COM!loverso>
Subject: Re: CBW

> Unfortunately, they also know about the "Code Breakers Workbench",

CBW will not be of much help if the crypt'd file was compressed first.

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

Date: 12 Mar 90 09:59:04+0100
From: uunet!iis!prl
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.

A good implementation of DES, including CBC file encryption
was distributed on the Usenet newsgroup comp.sources.unix, v18i007 (was
this numbering mere coincidence? :-) and v18i008. It was written
by Antti Louko (alo@kampi.hut.fi) at Helsinki Technical University,
and was distributed from Australia so that most sites in the non-US part
of the world recieved it without it going through the US.

Throughput is about 6Kbytes/sec on a Sun 3/280 with Fujitsu Eagle disks.
It is relatively compact; 24Kbytes on a Sun 3.

It can be FTP'd from kampi.hut.fi (128.214.3.9) and can be obtained
from most Usenet archive servers.

The code is freely redistributable, but bears the following Copyright
notice:

``Copyright 1989 Antti Louko. All Rights Reserved.

``This is a DES implementation written by Antti Louko
(alo@kampi.hut.fi). It is based on DES description found in D.E.R.
Denning's book Cryptography and Data Security.  At this time you may
use this program for non-commercial use. If you modify the program,
you must add a comment in the modified file indicating who modified
it. For commercial purposes please contact me [Antti Louko - prl].

``If you find bugs or otherwise modify this program, please send
changes back to me [Antti Louko - prl].''

The library code for Antti Louko's DES has also been designed to ``drop
in'' to Kerberos and the X11R4 XDMCP encrypted authentication protocol.

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

Date: Mon, 12 Mar 90 02:15:09 PST
From: uunet!paralogics!shaw (Guy Shaw)
Subject: Re: 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..

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.

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

Date: Mon, 5 Mar 90 01:51:31 -0500
From: der Mouse  <uunet!Larry.McRCIM.McGill.EDU!mouse>
Subject: crackers and passwords

>> 3) Crackers have copies of *very* fast password code.

How fast does that mean, by the way?  I sped up crypt(3) by about an
order of magnitude simply by doing an efficient implementation of the
algorithm instead of a straightforward and dumb one.  Of course, my
version (particularly the VAX assembly version) is not as easy to read,
but that's the price one pays....

> Would using shadow password files help in this regard?

> Shadow password files would be a major improvement and go a long way
> towards protecting passwords.  If the hackers [sic] can't get your
> password file, they certainly can't run the fast password code to
> break accounts.  (Well, they can run it, but it won't help!)

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.)

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

Date: Tue, 13 Mar 90 17:25:53 EST
From: uunet!bu-it.bu.edu!budd (Phil Budne)
Subject: Re:  More hacker signs - probably the same ones

>I would immediately check every program the /etc/rc* files run at boot
>for a trojan horse (get known good copies off of a tape and do a cmp.)

I'd also check crontab and scripts run therefrom.  I've seen
auto-trojans there as well!!

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

Date: Tue, 13 Mar 90 17:21:21 -0800 (PST)
From: Barry Lustig <uunet!ads.com!barry%confusion>
Subject: Fwd:

So much for security.

[ As I stated in the volume 2 issue 6 digest that went out 14-feb-90,
  I spoke to Steve Simmons and he agreed not to make the security list
  publically accessable in any way. - neil ]

        ---------- Forwarded message begins here ----------

We are currently archiving three mailing lists: the old Andrew Bert
security digest, the new Neil Gorsuch security digest, and Bjorn
Satedevas systems administration mailing list.
The material is available for anonymous ftp from terminator.cc.umich.edu.
Look in the directory ~ftp/unix/sysadmin.  At some point anon uucp access
will be offered, but no date has been set.

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

Date: Fri, 16 Mar 90 09:40:54 PST
From: neil (Neil Gorsuch)
Subject: archiving security

[ Because of numerous internet computer breakins over the last six
months or so, I ask that you PLEASE PLEASE PLEASE don't archive this
list.  I would prefer that you plug any listed holes and then DUMP THE
DIGEST(S).  If you must archive the list, make sure that the system it
is archived on has ALL known security holes fixed, and for good
measure disable every network service that isn't absolutely essential.
And USE SHADOW PASSWORDS, they're an easy way to prevent someone with
an account on your system and an IBM PC at home to crack root.  I
can't emphasize enough that the complete list archives details many
security holes that have not been fixed on a signifigant number of
systems. - neil ]

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

Date: Tue, 20 Mar 90 15:34:28 -0500
From: uunet!orion.mc.duke.edu!bet (Bennett Todd)
Subject: password checking program wanted

I just got a note from someone telling me that a cracker had run through
my machine on the way to theirs, using a login with an easily guessable
password. I've changed that one, but I'm sure there may be more. Does
anyone have a program I can use to scan /etc/passwd for easily guessable
passwords?

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

Date: Mon, 19 Mar 90 13:06:02 MST
From: <uunet!ctycal!ingoldsb>
Subject: Possible problem with Intergraph Soft-PC

Subject: Potential problem with Intergraph PC Emulator

Intergraph Unix sites may want to examine the things that can be done with
SoftPC, the MS-DOS emulator.  It may be necessary to remove SoftPC from the
pull-down menu or at least restrict it's use to trusted people.

SoftPC allows a Unix directory to be mapped as the D: disk.  Normal Unix
protections may not be enforced as to directory access.  I won't elucidate,
but any system manager who runs SoftPC should experiment a little and
convince himself why and how this can be very dangerous.

[ The point of this list is so that we can elucidate, please do - neil ]

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

Date: Mon, 26 Mar 90 14:28:41 CST
From: uunet!pex.eecs.nwu.edu!phil (William LeFebvre)
Subject: I just had the oddest phone call...

It may be nothing, but I thought I should share it with you anyway.
Someone called my office and said that he wanted to know the number to
call to access the computers.  I asked him who he was.  I didn't
recognize the name.  I asked him what computer he wanted to connect to
and he said "well, a unix computer".  I said "which one?"  He said "I
don't really know."  I said, "if you don't know what computer you want
to connect to, then what good will dialing up do you?"  This was
answered with silence.  After an uncomfortably long period of silence,
I asked if he was still there.  He hung up without saying anything
more.

Maybe he really was confused.  Maybe not....  Maybe he was trying to
get a number out of me when he had no business using it.   Maybe.

Moral: don't just give out your dialup numbers to anybody.  Know who
you're giving them to.  I think in the future I may insist that
someone come by my office to get the number, unless I *know* who they
are and I know that they can't come by for some reason.

This is by no means a complete way to protect yourself, but it is, I
think, a step in the right direction.

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

Date: Tue, 27 Mar 90 09:43:27 PST
From: uunet!tc.fluke.com!deb (Deb Lilly)
Subject: YP passwd bugs - SunOS 4.0.3

Two serious problems exist under SunOS 4.0.3 with the Yellow Pages passwd map.

Sun Bug ID # 1033972

/bin/yppasswd leaves YP passwd map world writable

Description:
        When a user runs yppasswd to change the password on an account in
        the Yellow Pages, the YP passwd map is recreated with mode 666
        (world writable).  This is a serious security problem.

Fix:    Add commands to /var/yp/Makefile on the YP master server to set
        the mode on the /var/yp/DOMAINNAME files for the maps passwd.byname,
        passwd.byuid, and publickey.byname:

        chmod 644 $(YPDBDIR)/$(DOM)/MAP.pag $(YPDBDIR)/$(DOM)/MAP.dir; \

        (Substitute each map name for "MAP" in the above command.)

Concurrent /bin/yppasswd sessions trash the YP passwd map.

Description:
        When multiple users change their passwords simultaneously, the
        yellow pages passwd map is updated concurrently, apparently with
        no file locking.  This can trash the YP passwd map.

        The *source* file for the passwd map is *not* affected.  When this
        problem occurs, it is easy to recreate good passwd maps on the YP
        master server:

                cd /var/yp
                rm passwd.time
                make passwd

        However, there is no fix yet to avoid the problem.  This bug has
        been duplicated by Sun under SunOS 4.1 and is still under
        investigation by Sun Engineering.

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

Date: Tue, 13 Mar 90 10:24:03 -0800
From: uunet!aerospace.aero.org!strauss
Subject: Re: * Xterm Security hole [X Windows Ver. 11, Release  3 and 4]

MIT just released fix-6 which corrects xterm so that it doesn't allow logging
to be turned on with an escape sequence.  It is very nice to see these things
fixed quickly for a change.  Good work X Consortium!

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

Date: Tue, 13 Mar 90 13:32:06 -0500
From: uunet!wayback.cs.cornell.edu!parmelee (Larry Parmelee)
Subject: Re: Xterm Security hole [X Windows Ver. 11, Release  3 and 4]

[ This is the last message in this digest - neil ]

The X Consortium has now released an official patch for the xterm
security hole reported earlier in the week, and they've apparently
included a few other bug fixes as well.  You probably should apply
this patch instead of my original patch.

Related to the security hole, they have added 3 pre-processor flags
that control various aspects of the hole:

        ALLOWLOGFILEONOFF - If defined, allow the escape sequences
                which turn logging on and off.
        ALLOWLOGFILECHANGES - If defined, allow the escape sequences
                which change the logfile name.
        ALLOWLOGFILEEXEC - If defined, allows a logfile name beginning
                with a "|" to form a pipelined command.

By default these will all be undefined.

Defining "ALLOWLOGFILECHANGES" may allow an attacker to overwrite
a user's files.  If "ALLOWLOGFILEEXEC" is also defined, the attacker
can at least lay a booby-trap for the user (assuming "ALLOWLOGFILEONOFF"
is not defined), such that something nasty can happen at a much later
time if/when the user happens to turn on logging in the xterm window.
Of course, if all three are defined, the attacker can lay a booby-trap
and trigger it immediately.

Defining "ALLOWLOGFILEONOFF" and "ALLOWLOGFILEEXEC" but leaving
"ALLOWLOGFILECHANGES" undefined is probably  reasonably safe- The
attacker can turn logging on and off all he wishes, but can
not specify a new log file name, hence cannot overwrite random files,
nor specify commands.  However, having "ALLOWLOGFILEEXEC" defined
allows users to log their xterm activity to a pipeline:
        xterm -l -lf '| SomeCommand'
and if this is done,  rapidly turing logging on and off may have some
other side effects.

Lastly, defining only "ALLOWLOGFILEONOFF" seems harmless enough,
and may be useful under some circumstances.

The X Consortium patch follows below.
-Larry Parmelee
parmelee@cs.cornell.edu


Date: Tue, 13 Mar 90 11:35:06 EST
Message-Id: <9003131635.AA14970@expo.lcs.mit.edu>
From: Xstuff service <xstuff@expo.lcs.mit.edu>
Subject:  fixes/6
In-Reply-To: Request from parmelee@wayback.cs.cornell.edu (larry parmelee) dated Tue Mar 13 11:30:04 EST 1990
To: parmelee@cs.cornell.edu

This patch fixes a security hole in xterm that has been there since X.V10R4.
To apply it, cd to the top of the X tree and apply with "patch -p0" and
remake in mit/clients/xterm.

*** /tmp/,RCSt1a24884   Mon Mar 12 11:27:20 1990
--- mit/clients/xterm/Imakefile Mon Mar 12 11:25:46 1990
***************
*** 34,39 ****
--- 34,40 ----
  #endif

     MAIN_DEFINES = -DUTMP $(TTYGROUPDEF) $(PUCCPTYDDEF)
+    MISC_DEFINES = /* -DALLOWLOGFILEEXEC */

            SRCS1 = button.c charproc.c cursor.c data.c input.c \
                  main.c menu.c misc.c screen.c scrollbar.c tabs.c \
***************
*** 50,64 ****
         DEPLIBS2 =
         PROGRAMS = xterm resize

  #ifdef CrayArchitecture
!      TERMCAPLIB = -lcurses
  #else
!      TERMCAPLIB = -ltermcap
  #endif

  AllTarget($(PROGRAMS))

  SpecialObjectRule(main.o, ,$(MAIN_DEFINES))

  NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB))
  InstallProgramWithFlags(xterm, $(BINDIR), $(INSTUIDFLAGS))
--- 51,75 ----
         DEPLIBS2 =
         PROGRAMS = xterm resize

+ #ifndef TermcapLibrary
+ #if SystemV && !defined(MacIIArchitecture)
  #ifdef CrayArchitecture
! #define TermcapLibrary -lcurses               /* special case of system v */
  #else
! #define TermcapLibrary -ltermlib      /* usually in here */
  #endif
+ #else
+ #define TermcapLibrary -ltermcap      /* bsd puts it here */
+ #endif
+ #endif

+      TERMCAPLIB = TermcapLibrary
+
  AllTarget($(PROGRAMS))

  SpecialObjectRule(main.o, ,$(MAIN_DEFINES))
+ SpecialObjectRule(misc.o, ,$(MISC_DEFINES))
+ SpecialObjectRule(charproc.o, ,$(MISC_DEFINES))

  NormalProgramTarget(xterm,$(OBJS1),$(DEPLIBS1),XawClientLibs,$(TERMCAPLIB) $(PTYLIB))
  InstallProgramWithFlags(xterm, $(BINDIR), $(INSTUIDFLAGS))
*** /tmp/,RCSt1a24650   Mon Mar 12 11:11:45 1990
--- mit/clients/xterm/button.c  Mon Mar  5 11:47:01 1990
***************
*** 1,5 ****
  /*
!  *    $XConsortium: button.c,v 1.49 89/12/10 20:45:17 jim Exp $
   */


--- 1,5 ----
  /*
!  *    $XConsortium: button.c,v 1.50 90/03/05 11:46:57 keith Exp $
   */


***************
*** 35,41 ****
                                J. Gettys.
  */
  #ifndef lint
! static char rcs_id[] = "$XConsortium: button.c,v 1.49 89/12/10 20:45:17 jim Exp $";
  #endif        /* lint */

  #include "ptyx.h"             /* Xlib headers included here. */
--- 35,41 ----
                                J. Gettys.
  */
  #ifndef lint
! static char rcs_id[] = "$XConsortium: button.c,v 1.50 90/03/05 11:46:57 keith Exp $";
  #endif        /* lint */

  #include "ptyx.h"             /* Xlib headers included here. */
***************
*** 489,497 ****
            PointToRowCol(event->xbutton.y, event->xbutton.x, &row, &col);
        }
        ExtendExtend (row, col);
-
        lastButtonUpTime = event->xbutton.time;
-       /* Only do select stuff if non-null select */
        if (startSRow != endSRow || startSCol != endSCol) {
                if (replyToEmacs) {
                        if (rawRow == startSRow && rawCol == startSCol
--- 489,495 ----
***************
*** 514,525 ****
                        }
                        TrackText(0, 0, 0, 0);
                }
                SaltTextAway(startSRow, startSCol, endSRow, endSCol,
                             params, num_params);
!       } else DisownSelection(term);
!
!       /* TrackText(0, 0, 0, 0); */
!       eventMode = NORMAL;
  }

  #define Abs(x)                ((x) < 0 ? -(x) : (x))
--- 512,542 ----
                        }
                        TrackText(0, 0, 0, 0);
                }
+       }
+       SelectSet(event, params, num_params);
+       eventMode = NORMAL;
+ }
+
+ HandleSelectSet(w, event, params, num_params)
+ Widget w;
+ XEvent *event;
+ String *params;
+ Cardinal *num_params;
+ {
+       SelectSet (event, params, *num_params);
+ }
+
+ SelectSet (event, params, num_params)
+ XEvent        *event;
+ String        *params;
+ Cardinal    num_params;
+ {
+       /* Only do select stuff if non-null select */
+       if (startSRow != endSRow || startSCol != endSCol) {
                SaltTextAway(startSRow, startSCol, endSRow, endSCol,
                             params, num_params);
!       } else
!               DisownSelection(term);
  }

  #define Abs(x)                ((x) < 0 ? -(x) : (x))
*** /tmp/,RCSt1a24657   Mon Mar 12 11:11:48 1990
--- mit/clients/xterm/charproc.c        Mon Mar 12 10:30:27 1990
***************
*** 1,5 ****
  /*
!  * $XConsortium: charproc.c,v 1.121 89/12/15 19:07:43 jim Exp $
   */


--- 1,5 ----
  /*
!  * $XConsortium: charproc.c,v 1.123 90/03/12 10:30:21 jim Exp $
   */


***************
*** 149,155 ****
  #define       doinput()               (bcnt-- > 0 ? *bptr++ : in_put())

  #ifndef lint
! static char rcs_id[] = "$XConsortium: charproc.c,v 1.121 89/12/15 19:07:43 jim Exp $";
  #endif        /* lint */

  static int nparam;
--- 149,155 ----
  #define       doinput()               (bcnt-- > 0 ? *bptr++ : in_put())

  #ifndef lint
! static char rcs_id[] = "$XConsortium: charproc.c,v 1.123 90/03/12 10:30:21 jim Exp $";
  #endif        /* lint */

  static int nparam;
***************
*** 180,186 ****
  static void HandleKeymapChange();
  extern void HandleInsertSelection();
  extern void HandleSelectStart(), HandleKeyboardSelectStart();
! extern void HandleSelectExtend();
  extern void HandleSelectEnd(), HandleKeyboardSelectEnd();
  extern void HandleStartExtend(), HandleKeyboardStartExtend();
  static void HandleBell();
--- 180,186 ----
  static void HandleKeymapChange();
  extern void HandleInsertSelection();
  extern void HandleSelectStart(), HandleKeyboardSelectStart();
! extern void HandleSelectExtend(), HandleSelectSet();
  extern void HandleSelectEnd(), HandleKeyboardSelectEnd();
  extern void HandleStartExtend(), HandleKeyboardStartExtend();
  static void HandleBell();
***************
*** 250,255 ****
--- 250,256 ----
      { "select-start",   HandleSelectStart },
      { "select-extend",          HandleSelectExtend },
      { "select-end",     HandleSelectEnd },
+     { "select-set",     HandleSelectSet },
      { "select-cursor-start",    HandleKeyboardSelectStart },
      { "select-cursor-end",      HandleKeyboardSelectEnd },
      { "set-vt-font",    HandleSetFont },
***************
*** 1489,1498 ****
--- 1490,1508 ----
                        update_reversewrap();
                        break;
                case 46:                /* logging              */
+ #ifdef ALLOWLOGFILEONOFF
+                       /*
+                        * if this feature is enabled, logging may be
+                        * enabled and disabled via escape sequences.
+                        */
                        if(func == bitset)
                                StartLog(screen);
                        else
                                CloseLog(screen);
+ #else
+                       Bell();
+                       Bell();
+ #endif /* ALLOWLOGFILEONOFF */
                        break;
                case 47:                /* alternate buffer             */
                        if(func == bitset)
***************
*** 1687,1696 ****
--- 1697,1708 ----
                        update_reversewrap();
                        break;
                case 46:                /* logging              */
+ #ifdef ALLOWLOGFILEONOFF
                        if(screen->save_modes[14])
                                StartLog(screen);
                        else
                                CloseLog(screen);
+ #endif /* ALLOWLOGFILEONOFF */
                        /* update_logging done by StartLog and CloseLog */
                        break;
                case 47:                /* alternate buffer             */
*** /tmp/,RCSt1a24743   Mon Mar 12 11:12:09 1990
--- mit/clients/xterm/misc.c    Mon Mar 12 10:30:22 1990
***************
*** 1,5 ****
  /*
!  *    $XConsortium: misc.c,v 1.62 89/12/10 20:44:41 jim Exp $
   */


--- 1,5 ----
  /*
!  *    $XConsortium: misc.c,v 1.65 90/03/12 10:30:17 jim Exp $
   */


***************
*** 58,64 ****
  static void DoSpecialLeaveNotify();

  #ifndef lint
! static char rcs_id[] = "$XConsortium: misc.c,v 1.62 89/12/10 20:44:41 jim Exp $";
  #endif        /* lint */

  xevents()
--- 58,64 ----
  static void DoSpecialLeaveNotify();

  #ifndef lint
! static char rcs_id[] = "$XConsortium: misc.c,v 1.65 90/03/12 10:30:17 jim Exp $";
  #endif        /* lint */

  xevents()
***************
*** 388,393 ****
--- 388,394 ----
        register int i;
        static char *log_default;
        char *malloc(), *rindex();
+ #ifdef ALLOWLOGFILEEXEC
        void logpipe();
  #ifdef SYSV
        /* SYSV has another pointer which should be part of the
***************
*** 395,400 ****
--- 396,402 ----
        */
        unsigned char *old_bufend;
  #endif        /* SYSV */
+ #endif /* ALLOWLOGFILEEXEC */

        if(screen->logging || (screen->inhibit & I_LOG))
                return;
***************
*** 408,413 ****
--- 410,421 ----
                strcpy(screen->logfile, log_default);
        }
        if(*screen->logfile == '|') {   /* exec command */
+ #ifdef ALLOWLOGFILEEXEC
+               /*
+                * Warning, enabling this "feature" allows arbitrary programs
+                * to be run.  If ALLOWLOGFILECHANGES is enabled, this can be
+                * done through escape sequences....  You have been warned.
+                */
                int p[2];
                static char *shell;

***************
*** 454,459 ****
--- 462,472 ----
                close(p[0]);
                screen->logfd = p[1];
                signal(SIGPIPE, logpipe);
+ #else
+               Bell();
+               Bell();
+               return;
+ #endif
        } else {
                if(access(screen->logfile, F_OK) == 0) {
                        if(access(screen->logfile, W_OK) < 0)
***************
*** 500,505 ****
--- 513,519 ----
        screen->logstart = screen->TekEmu ? Tbuffer : buffer;
  }

+ #ifdef ALLOWLOGFILEEXEC
  void logpipe()
  {
        register TScreen *screen = &term->screen;
***************
*** 510,516 ****
--- 524,532 ----
        if(screen->logging)
                CloseLog(screen);
  }
+ #endif /* ALLOWLOGFILEEXEC */

+
  do_osc(func)
  int (*func)();
  {
***************
*** 518,523 ****
--- 534,540 ----
        register int mode, c;
        register char *cp;
        char buf[512];
+       char *bufend = &buf[(sizeof buf) - 1];  /* leave room for null */
        extern char *malloc();
        Bool okay = True;

***************
*** 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;
--- 548,554 ----
                mode = 10 * mode + (c - '0');
        if (c != ';') okay = False;
        cp = buf;
!       while(isprint((c = (*func)()) & 0x7f) && cp < bufend)
                *cp++ = c;
        if (c != 7) okay = False;
        *cp = 0;
***************
*** 550,555 ****
--- 567,577 ----
                break;

         case 46:       /* new log file */
+ #ifdef ALLOWLOGFILECHANGES
+               /*
+                * Warning, enabling this feature allows people to overwrite
+                * arbitrary files accessible to the person running xterm.
+                */
                if((cp = malloc((unsigned)strlen(buf) + 1)) == NULL)
                        break;
                strcpy(cp, buf);
***************
*** 556,561 ****
--- 578,587 ----
                if(screen->logfile)
                        free(screen->logfile);
                screen->logfile = cp;
+ #else
+               Bell();
+               Bell();
+ #endif
                break;

        case 50:


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

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

END OF DOCUMENT