Question about TIOCSTI (permissions)

[Kenny McCormack]

Under Linux (x86).

I've written a small C program to "fake" keystrokes, using TIOCSTI.
The operative line of code is:

ioctl(fd,TIOCSTI,"X");

(running as non-root) It works fine if fd refers to the current tty, but
fails (with "Operation not permitted") if fd refers to some other tty EVEN
IF THE OTHER TTY IS OWNED BY ME. That is, the open() on the other tty
succeeds, but the subsequent ioctl() fails. This seems odd to me.

FWIW, I was testing under screen - where the other tty was another screen
window. I'm not sure if that is relevant or not.

Running as root, it seems to work OK on any tty (although I haven't tested
extensively to see exactly what does and doesn't work).

So, what is the "defined" behavior?

P.S. I suspect this may have something to do with process groups, but I
don't understand process groups (never have - it always seemed an unnecessary
concept to me) well enough to know.

--
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.

[Richard Kettlewell]

gaz...@shell.xmission.com (Kenny McCormack) writes:
> I've written a small C program to "fake" keystrokes, using TIOCSTI.
> The operative line of code is:
>
> ioctl(fd,TIOCSTI,"X");
>
> (running as non-root) It works fine if fd refers to the current tty, but
> fails (with "Operation not permitted") if fd refers to some other tty EVEN
> IF THE OTHER TTY IS OWNED BY ME. That is, the open() on the other tty
> succeeds, but the subsequent ioctl() fails. This seems odd to me.
>
> FWIW, I was testing under screen - where the other tty was another screen
> window. I'm not sure if that is relevant or not.
>
> Running as root, it seems to work OK on any tty (although I haven't tested
> extensively to see exactly what does and doesn't work).

In Linux, the calling process must either have CAP_SYS_ADMIN (which
usually equates to being root) or fd must refer to the process’s
controlling terminal.

> So, what is the "defined" behavior?

That depends what you mean by “defined”. I’m not aware of a formal
standard that defines this ioctl. The earliest I can find it is Bill
Joy adding it to BSD in 1980; it doesn’t seem to be present in
comparably old AT&T code. I expect that Linux just copies the semantics
of that version.

Without knowing what was in the mind of the designer, I would guess the
intention behind the restriction is to prevent privilege escalation by
other processes with the same terminal.

> P.S. I suspect this may have something to do with process groups, but
> I don't understand process groups (never have - it always seemed an
> unnecessary concept to me) well enough to know.

They are part of the means by which shell job control works; each job is
a process group.

--
http://www.greenend.org.uk/rjk/

[Kenny McCormack]

In article <87eheam...@araminta.anjou.terraraq.org.uk>,
Richard Kettlewell <r...@greenend.org.uk> wrote:
...

>In Linux, the calling process must either have CAP_SYS_ADMIN (which
>usually equates to being root) or fd must refer to the process’s
>controlling terminal.

Thanks. Sorted. I ended up writing a setuid program so that non-priv'd
users could do it.

BTW, what is the security problem here? How could one "escalate"?

P.S. I get what you're saying - that it is the way it is pretty much
because that's the way Bill Joy wrote it way back when...

--
- Since the shootings on Friday, the ultra-defensive [maybe wrongly
- hyphenated, but that would be fitting] Roy "News" LIEberman has posted
- at least 90 times, and almost every single post is about his obsessive
- knee-jerk loonball [wacko] gun politics. How much longer before the
- authorities [police] finally disable the trip wires and confiscate the
- arsenal in his St. Louie hovel?

So true. So true.

[William Ahern]

Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <87eheam...@araminta.anjou.terraraq.org.uk>,
> Richard Kettlewell <r...@greenend.org.uk> wrote:
> ...
> >In Linux, the calling process must either have CAP_SYS_ADMIN (which

> >usually equates to being root) or fd must refer to the process???s

> >controlling terminal.

> Thanks. Sorted. I ended up writing a setuid program so that non-priv'd
> users could do it.

> BTW, what is the security problem here? How could one "escalate"?

If any program you ran could write to any of your terminals, then they could
write to any of the terminals in which you've su'd or sudo'd.

IIUC, with the current behavior only programs you've executed from the same
terminal could do that. Or if the shell changes the controlling tty when
executing other programs, then none of those programs could that it. Or a
wrapper or the program itself could do that as a measure to sandbox itself.

[William Ahern]

Some references:

(discussion of pconsole utility)
http://web.archiveorange.com/archive/v/hqjSuafkgQMigbjYVewz

(1988 usenix paper)
https://www.cs.columbia.edu/~smb/papers/sessext.pdf

Controlling TTYs: A Unix Horror Story, Daniel J. Bernstein, Draft 1,
1991-10-06
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/bernstein-on-ttys/cttys.html

[Nicolas George]

William Ahern , dans le message
<4da14a-...@wilbur.25thandClement.com>, a �crit�:

> IIUC, with the current behavior only programs you've executed from the same
> terminal could do that.

Or any program that can ptrace() a terminal emulator.

[Scott Lurndal]

gaz...@shell.xmission.com (Kenny McCormack) writes:
>In article <87eheam...@araminta.anjou.terraraq.org.uk>,
>Richard Kettlewell <r...@greenend.org.uk> wrote:
>...
>>In Linux, the calling process must either have CAP_SYS_ADMIN (which
>>usually equates to being root) or fd must refer to the process’s
>>controlling terminal.
>
>Thanks. Sorted. I ended up writing a setuid program so that non-priv'd
>users could do it.
>
>BTW, what is the security problem here? How could one "escalate"?

If you can inject commands into someone other users (e.g. a root user)
terminal, you can do pretty much anything you want.

Did this back on the PDP-8 with TSS/8.24, it was quite annoying when
someone did it to you (e.g. inject ^B-s which terminated the login session).

scott

[Barry Margolin]

In article <R9ybt.46434$mE2....@fe20.iad>,

Me too! I discovered a privilege-escalation attack in the BASIC
interpreter. It implemented some functions with a byte-code operator
that executed raw machine code in the byte-compiled file. So I created
a .BAC file with a PRINT statement, then patched it to replace the PRINT
byte-code with the EXEC byte-code. This way I could execute any
arbitrary machine code within a BASIC program.

The bug was that the interpreter ran in privileged mode. There was
probably a reason it needed this, but I don't remember it (maybe so it
could access more memory). But this meant that I could perform the
system calls that wrote to another terminal or even log someone else out.

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Scott Lurndal]

Barry Margolin <bar...@alum.mit.edu> writes:
>In article <R9ybt.46434$mE2....@fe20.iad>,
> sc...@slp53.sl.home (Scott Lurndal) wrote:
>
>> gaz...@shell.xmission.com (Kenny McCormack) writes:
>> >In article <87eheam...@araminta.anjou.terraraq.org.uk>,
>> >Richard Kettlewell <r...@greenend.org.uk> wrote:
>> >...
>> >>In Linux, the calling process must either have CAP_SYS_ADMIN (which
>> >>usually equates to being root) or fd must refer to the process’s
>> >>controlling terminal.
>> >
>> >Thanks. Sorted. I ended up writing a setuid program so that non-priv'd
>> >users could do it.
>> >
>> >BTW, what is the security problem here? How could one "escalate"?
>>
>> If you can inject commands into someone other users (e.g. a root user)
>> terminal, you can do pretty much anything you want.
>>
>> Did this back on the PDP-8 with TSS/8.24, it was quite annoying when
>> someone did it to you (e.g. inject ^B-s which terminated the login session).
>
>Me too! I discovered a privilege-escalation attack in the BASIC
>interpreter.

I found a similar attack in the HP-3000 BASIC interpreter, which was
installed with the PH (Process Handling) capability. One could call
the system intrinsics directly from BASIC, so one could manipulate
the priority other users jobs amongst other things. Once the operators
figured out how we were doing it, they subtracted the PH cap from BASIC.

Early VMS allowed one to DEBUG an executable installed with enhanced
capabilities (such as Change Mode to Kernel), which was extremely
dangerous (albeit useful).

scott

[William Ahern]

Nicolas George <nicolas$geo...@salle-s.org> wrote:
> William Ahern , dans le message

> <4da14a-...@wilbur.25thandClement.com>, a écrit :

> > IIUC, with the current behavior only programs you've executed from the
> > same terminal could do that.

> Or any program that can ptrace() a terminal emulator.

OS X has taken the annoying but understandable approach of requiring
privileges to trace. I'm not sure about the mechanics of it, though; it
could just be theater.

On Linux prctl(PR_SET_DUMABLE, 0) is overloaded to allow unprivileged
processes to protect themselves from tracing, although that's also annoying
as it prevents core dumps, making debugging unnecessarily burdensome. Ubuntu
Linux uses a kernel which, by default, only allows tracing of descendant
processes.

It's a shame these solutions are so ad hoc and unportable.

[Kenny McCormack]

In article <u0b14a-...@wilbur.25thandClement.com>,
William Ahern <wil...@wilbur.25thandClement.com> wrote:
...

>> IIUC, with the current behavior only programs you've executed from the
>> same terminal could do that. Or if the shell changes the controlling tty

I was in the process of composing one of my (all too common on the modern
Usenet) "You [*] are totally missing the point" responses, ...

[*] "you" meaning most of the later responders on this thread, not you,
William, specifically.

... When it occurred to me that the issue here is that in the olden days,
people's terminals (i.e., their /dev/...tty device) were generally world
writable - because back in those olden times, the "write" program actually
opened up and wrote to the user's terminal device. And the "mesg" utility
worked by actually changing the perms on said device. And the default
setting for "mesg" was "y". None of these things are (in any significant
sense) true today.

But in that environment, where anybody could (usually, i.e., if you had
"mesg y" in effect) open up your terminal device, then clearly it doesn't
make sense to allow anyone who can open up your tty to be able to force
keystrokes into it. And, as the first response on this thread noted, the
semantics of TIOCSTI were set way back then, in those earlier times, and
haven't been updated (much) since then.

In conclusion, I would suggest that the right way to do this is to:
A) Require read/write access on the tty (which seems to be the case).
B) (Optionally) also require that the tty be owned by you ("you" being the
one issuing the TIOCSTI call).

Together, that ought to remove the requirement of being root.

--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

[Richard Kettlewell]

gaz...@shell.xmission.com (Kenny McCormack) writes:

> In conclusion, I would suggest that the right way to do this is to:
> A) Require read/write access on the tty (which seems to be the case).
> B) (Optionally) also require that the tty be owned by you ("you" being the
> one issuing the TIOCSTI call).
>
> Together, that ought to remove the requirement of being root.

Better still, just remove TIOCSTI.

--
http://www.greenend.org.uk/rjk/

[Kenny McCormack]

In article <87haiuz...@araminta.anjou.terraraq.org.uk>,

Heh heh. Funny stuff.

If programming ever doesn't work out for you, you can always try stand-up
comedy.

Good show, old chap.

[Richard Kettlewell]

gaz...@shell.xmission.com (Kenny McCormack) writes:
> Richard Kettlewell <r...@greenend.org.uk> wrote:
>>gaz...@shell.xmission.com (Kenny McCormack) writes:

>>> In conclusion, I would suggest that the right way to do this is to:
>>> A) Require read/write access on the tty (which seems to be the case).
>>> B) (Optionally) also require that the tty be owned by you ("you" being the
>>> one issuing the TIOCSTI call).
>>>
>>> Together, that ought to remove the requirement of being root.
>>
>>Better still, just remove TIOCSTI.
>
> Heh heh. Funny stuff.
>
> If programming ever doesn't work out for you, you can always try stand-up
> comedy.
>
> Good show, old chap.

Neither your proposal nor the current behaviour actually solve the
(inferred [1]) problem, which is that a process that by some means has
an open FD on a terminal can fake input to a higher-privilege process
reading from it.

Mine does l-)

[1] with reasonable certainty; there was a CVE a few years ago.

--
http://www.greenend.org.uk/rjk/

[Nobody]

On Thu, 25 Apr 2013 12:27:07 +0000, Kenny McCormack wrote:

>>Better still, just remove TIOCSTI.
>
> Heh heh. Funny stuff.

It's a perfectly reasonable suggestion.

An echo-back feature is a security vulnerability, whether in the tty
driver or the terminal itself.