The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #41 1989-11-28 (1 file, 1932 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Tue, 28 Nov 89 13:34:32 PST
Subject: Security Digest V1 #41

Security Digest Volume 1 Issue 41


            4.[23]BSD ftp bug (really sh bug)
            DIR EXEC on VM (VM/CMS)


Date: Sun, 26 Nov 89 18:45:54 EST
From: uunet!allegra!mp (Mark Plotnick)
Subject: 4.[23]BSD ftp bug (really sh bug)

/bin/sh, if called with argv[0][0]=='-', executes .profile in the
current directory, NOT $HOME/.profile as the man page claims.

The '!' command in the 4.[23]BSD ftp starts up a shell with argv[0][0]=='-'
if the shell is sh.  (On 4.2bsd, it only does this if the '!' command
is given no arguments, i.e., when an interactive subshell is wanted).
I tripped over this problem when someone accidentally dumped his
.profile into /usr/tmp; I typically cd to /usr/tmp before invoking ftp
when I'm going to be grabbing big files from the arpanet, and was
surprised when "!mkdir m" starting printing out strange messages!

This .profile behavior has been in every version of /bin/sh
I've seen, and I'm not sure how to fix it (my Algol is rusty, anyway).
But here's a suggested fix for ftp:

*** /tmp/,RCSt1000120   Sun Nov 26 15:21:57 1989
--- cmds.c      Sun Nov 26 15:20:43 1989
*** 1050,1056 ****
        char *argv[];
        int pid, (*old1)(), (*old2)();
!       char shellnam[40], *shell, *namep;
        union wait status;

        old1 = signal (SIGINT, SIG_IGN);
--- 1050,1056 ----
        char *argv[];
        int pid, (*old1)(), (*old2)();
!       char *shellnam, *shell;
        union wait status;

        old1 = signal (SIGINT, SIG_IGN);
*** 1063,1075 ****
                shell = getenv("SHELL");
                if (shell == NULL)
                        shell = "/bin/sh";
!               namep = rindex(shell,'/');
!               if (namep == NULL)
!                       namep = shell;
!               (void) strcpy(shellnam,"-");
!               (void) strcat(shellnam, ++namep);
!               if (strcmp(namep, "sh") != 0)
!                       shellnam[0] = '+';
                if (debug) {
                        printf ("%s\n", shell);
                        (void) fflush (stdout);
--- 1063,1073 ----
                shell = getenv("SHELL");
                if (shell == NULL)
                        shell = "/bin/sh";
!               shellnam = rindex(shell,'/');
!               if (shellnam == NULL)
!                       shellnam = shell;
!               else
!                       shellnam++;
                if (debug) {
                        printf ("%s\n", shell);
                        (void) fflush (stdout);


Date: Tue, 28 Nov 89 13:21:40 PST
From: neil (Neil Gorsuch)
Subject: DIR EXEC on VM (VM/CMS)

[ This is not strictly a unix problem, but is probably of interest to
a number of this list's readers.  It may be old news.  It was sent out
to the usenet news group comp.virus.  - neil ]

This is an emergency warning. As such it has been sent to several important
lists; please excuse the multiple cross-posting.

A dangerous REXX exec named DIR EXEC has been detected on our node, thanks
to a watchful recipient. This exec purports to be able produce a directory
listing of the user's disks in a MS/DOS (PC) format.

However, when the exec is run, it will produce the promised listing BUT it
will also send a copy of itself to all net addresses found in the user's
NAMES and NETLOG files.

This will, of course, swamp the BITNET network in a very short time if it
is allowed to run unchecked. Its behavior is, damagewise, identical to the
CHRISTMA EXEC which attacked both BITNET and VNET (IBM's corporate net)
approximately three years ago.

All system operators, postmasters and people in charge: if you find the DIR
EXEC in your system's RDR queue, flush immediately. The copy we detected has
the following characteristics:

DIR      EXEC     B1 V        116        167          1

The datestamp is not a reliable indicator; in two different copies found in
our RDR queue, the date was different.

Also, please post warnings on your systems, alerting your users about this

Thanks for your immediate attention to this urgent problem.


        End of Security Digest Volume 1 Issue 41