[TUHS] shell escapes in utilities

[TUHS] shell escapes in utilities

[ron minnich]

I got to wondering, based on the sendmail discussions, how many shell
escapes have appeared over the years?

uucp
sendmail
xdvi : "The "allowShell" option enables the shell escape in PostScript specials"

There must be a lot of them, however.

[TUHS] Re: shell escapes in utilities

[Leah Neukirchen]

ron minnich <rminnich@gmail.com> writes:

> I got to wondering, based on the sendmail discussions, how many shell
> escapes have appeared over the years?
>
> uucp
> sendmail
> xdvi : "The "allowShell" option enables the shell escape in PostScript specials"

From the top of my head, where it can be disabled:

ghostscript (see above)
tex (write18)
ed/ex/vi
nethack

-- 
Leah Neukirchen  <leah@vuxu.org>  https://leahneukirchen.org/

[TUHS] Re: shell escapes in utilities

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

At 2023-08-01T13:38:55+0200, Leah Neukirchen wrote:
> > I got to wondering, based on the sendmail discussions, how many
> > shell escapes have appeared over the years?
> >
> > uucp
> > sendmail
> > xdvi : "The "allowShell" option enables the shell escape in PostScript specials"
> 
> From the top of my head, where it can be disabled:
> 
> ghostscript (see above)
> tex (write18)
> ed/ex/vi
> nethack

And the *roffs of course.  nroff/troff/groff, with the `sy` (system(3))
and `pi` (popen(3)) requests.  pic(1) as well ("sh").

groff has, since version 1.12 in 1999, disabled these features by
default; the '-U' ("unsafe") command-line option reënables them.  It
added some additional unsafe requests for arbitrary stream I/O, `open`,
`opena` (open with append), and `pso` (`so` for pipeline output).

I recently learned of a limitation in the way AT&T and GNU *roffs, at
least, construct the string `sy` passes passes to system(3), which makes
certain things impossible.  Unfortunately it forecloses useful
applications, not any particularly malicious ones.

    There is a problem with trying to embed true newlines into the
    arguments of a `sy` request.  The C++ function that GNU troff uses
    to assemble the command string (character by character) _does not
    recognize C/C++ string literal escape sequences_.  This means that
    you _cannot_ embed "\n" in `sy`'s arguments and have it survive, as
    a newline character, into the command string passed to the standard
    C library's system(3) function.  ("A\nB" gets encoded as 'A', '\\',
    'n', 'B', not 'A', '\n', 'B'.) Unfortunately, this appears to be
    AT&T troff-compatible behavior.  But it means that you _cannot_
    portably construct multi-line replacement text for sed's 's'
    command.  (Other sed commands like 'a', 'c', and 'i' will be
    similarly affected.)  See Savannah #64071.

AT&T troff obviously wasn't written in C++, so this would appear to be
an instance of independent oversight.  (Where James Clark had gripes
about AT&T troff behavior, he left them in source code comments.)

I aim to fix this.  If I can write an arbitrary shell command, then I
darn well ought to be able to embed an arbitrary sed script in that
shell command (without needing a GNU sed extension to embed newlines).

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: shell escapes in utilities

[Dave Horsfall]

Not quite a Shell escape but possibly just as dangerous: EX/VI had/has the 
ability to embed EX commands within a file to be run when opened e.g. "se 
ts=4 sw=4" etc; no doubt EMACS has the same "feature".

It would also recognise the EXINIT environment variable.

-- Dave

[TUHS] Re: shell escapes in utilities

[arnold]

Dave Horsfall <dave@horsfall.org> wrote:

> Not quite a Shell escape but possibly just as dangerous: EX/VI had/has the 
> ability to embed EX commands within a file to be run when opened e.g. "se 
> ts=4 sw=4" etc; no doubt EMACS has the same "feature".
>
> It would also recognise the EXINIT environment variable.
>
> -- Dave

These are called "modelines".  In modern vim they have to be in the
first 4 or last 4 lines of a file (or so) and vim is careful about
what it will run from a modeline.

I *think* other vi versions have an option to enable modelines in
the .exrc file, which is off by default, but I no longer remember
the details.

Arnold

[TUHS] Re: shell escapes in utilities

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Looking at sources on TUHS, it looks like ed had it as early as V5:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/ed1.s

On Mon, Jul 31, 2023, 10:48 PM ron minnich <rminnich@gmail.com> wrote:

> I got to wondering, based on the sendmail discussions, how many shell
> escapes have appeared over the years?
>
> uucp
> sendmail
> xdvi : "The "allowShell" option enables the shell escape in PostScript
> specials"
>
> There must be a lot of them, however.
>

[-- Attachment #2: Type: text/html, Size: 1075 bytes --]

[TUHS] Re: shell escapes in utilities

[ron minnich]

I'm ok with things like ed, I'm more thinking of situations where
people would (e.g.) use xdvi to view a file, and Bad Things Happened.
I don't think ed counts, unless we're that worried about scripts.

at least for me, the xdvi thing was a real shock.

On Tue, Aug 1, 2023 at 7:29 AM Skip Tavakkolian <fariborz.t@gmail.com> wrote:
>
> Looking at sources on TUHS, it looks like ed had it as early as V5:
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/ed1.s
>
> On Mon, Jul 31, 2023, 10:48 PM ron minnich <rminnich@gmail.com> wrote:
>>
>> I got to wondering, based on the sendmail discussions, how many shell
>> escapes have appeared over the years?
>>
>> uucp
>> sendmail
>> xdvi : "The "allowShell" option enables the shell escape in PostScript specials"
>>
>> There must be a lot of them, however.

[TUHS] Re: shell escapes in utilities

[Ron Natalie]

The Sendmail WIZ bug was but one of the security disasters from shell 
escapes.    I remember IBM sending me an early RS/6000.    Booted the 
thing up but had no clue what root or any other password was.
So, I set to work hacking on it.   Now this thing had a physical key on 
the front.   Off, On, and a Wrench symbol.   OK, let’s try the wrench.   
  Boots up some sort of maintenance program.   After playing around with 
it a bit I find a help option.    This starts up a paginator (more or pg 
or something).    Sure enough you can shell escape otu of that.   
Instant root shell.    Now it’s trivial to change the root password and 
reboot in normal mode.

Yep, the need for shell escapes largely went away with windowing and job 
control.

[TUHS] Re: shell escapes in utilities

[Niklas Karlsson]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

Den tis 1 aug. 2023 kl 20:43 skrev Ron Natalie <ron@ronnatalie.com>:

>
> I remember IBM sending me an early RS/6000.    Booted the
> thing up but had no clue what root or any other password was.
> So, I set to work hacking on it.   Now this thing had a physical key on
> the front.   Off, On, and a Wrench symbol.   OK, let’s try the wrench.
>   Boots up some sort of maintenance program.   After playing around with
> it a bit I find a help option.    This starts up a paginator (more or pg
> or something).    Sure enough you can shell escape otu of that.
> Instant root shell.    Now it’s trivial to change the root password and
> reboot in normal mode.
>

To be fair, local root exploits are a bit of a different animal from
remote ones. Even now, if you have physical access to your average *nix
box, you can likely gain root. Sure, there are ways and means of
preventing that, but IME it's really only people doing really secret
spook stuff that bother with those. Even engineering outfits with big
secrets to protect usually don't bother.

What you did with that RS/6000 sounds roughly equivalent to booting a
modern Linux box in single-user mode, where you can also set the root
password to anything you like.

Niklas

[-- Attachment #2: Type: text/html, Size: 1651 bytes --]

[TUHS] Re: shell escapes in utilities

[Steffen Nurpmeso]

Niklas Karlsson wrote in
 <CAK6BEgegH3TeE4ETM489s70jV4xDFzEJF1EV7u2QPkHEr4pCFA@mail.gmail.com>:
 |Den tis 1 aug. 2023 kl 20:43 skrev Ron Natalie <ron@ronnatalie.com>:
 |> I remember IBM sending me an early RS/6000.    Booted the
 |> thing up but had no clue what root or any other password was.
 |> So, I set to work hacking on it.   Now this thing had a physical key on
 |> the front.   Off, On, and a Wrench symbol.   OK, let’s try the wrench.
 |>   Boots up some sort of maintenance program.   After playing around with
 |> it a bit I find a help option.    This starts up a paginator (more or pg
 |> or something).    Sure enough you can shell escape otu of that.
 |> Instant root shell.    Now it’s trivial to change the root password and
 |> reboot in normal mode.
 |
 |To be fair, local root exploits are a bit of a different animal from
 |remote ones. Even now, if you have physical access to your average *nix
 |box, you can likely gain root. Sure, there are ways and means of

I find this a provocative statement even in the silly saison.
I would assume that despite EFI firmware snooping key presses when
entering the disk key on cold boot, or other sort of nifty spying
(the famous USB sticks that "turn into keyboards and send key
presses" (as root?) cross my mind), i would think that you have
a hard time as a normal user to become root.  On this box; even
though you are not further separated via "ip netns exec .. unshare
.." etc.; some SETUID programs exist

  $ find /sbin /bin /usr/sbin /usr/bin -perm /4000
  /sbin/unix_chkpwd
  /bin/ping
  /bin/umount
  /bin/mount
  /bin/ksu
  /usr/bin/fusermount
  /usr/bin/crontab
  /usr/bin/doas
  /usr/bin/slock
  /usr/bin/traceroute
  /usr/bin/newuidmap
  /usr/bin/newgidmap
  /usr/bin/passwd
  /usr/bin/newgrp
  /usr/bin/expiry
  /usr/bin/chsh
  /usr/bin/chfn
  /usr/bin/chage
  /usr/bin/su

 |preventing that, but IME it's really only people doing really secret
 |spook stuff that bother with those. Even engineering outfits with big
 |secrets to protect usually don't bother.
 |
 |What you did with that RS/6000 sounds roughly equivalent to booting a
 |modern Linux box in single-user mode, where you can also set the root
 |password to anything you like.

Not here.

 |Niklas

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: shell escapes in utilities

[Ron Natalie]

Even without shell escapes there are fun and cames with abusing setuid 
(but accessible) programs.
Things like opening all the available file descriptors, closing 
stdin/out/err before invocation, doing things to overrun buffers, etc…

[TUHS] Re: shell escapes in utilities

[Steffen Nurpmeso]

Ron Natalie wrote in
 <em4ad243a6-02bf-4d7e-924a-3fe4a00e2c06@a70c2ae8.com>:
 |Even without shell escapes there are fun and cames with abusing setuid 
 |(but accessible) programs.
 |Things like opening all the available file descriptors, closing 
 |stdin/out/err before invocation, doing things to overrun buffers, etc…

Of course.  Even experienced programmers still make errors, or
kernel bugs introduce problems which even such a programmer did
not take into account.  (Like that isatty(3) uses "a" IOCTL, and
a Linux bug caused local root exploit of any SETUID program that
uses C stdio's stdout (testing ISO C's "whether output shall be
line or fully buffered"), as seen earlier this year i think.)

This is for my convenience, one could "overlayfs them away".
..And my user account has a number of capabilities, starting X,
accessing audio and video, starting QEMU instances, changing files
under /x/{src,iso,os,doc} etc.

  $ groups
  audio video cdrom input kvm _icmp users steffen ports doc backups shared media vm code

And brute forcing/attacking the encfs ~/.sic where keys are stored
to access more one could.

At least, via the ACPI that Linux thankfully supports on this box,
all (other) encfs are unloaded, and (all) X displays are locked
(via slock, requiring password to unlock) when the display is
closed.

And all keys are removed from all SSH agents, even though this is
hard because even root cannot simply signal this as would be
possible with gnupg based agents.  Ie.

  act 'pkill -HUP gpg-agent >/dev/null 2>&1 &'
  inc

vs

  for a in /tmp/ssh-*/agent.*; do
    [ -e "$a" ] || continue
    act "SSH_AUTH_SOCK=\"$a\" ssh-add -D </dev/null >/dev/null 2>&1 &"
    inc 1 2
  done

which prevents personal /tmp directories (or requires work).
(Asynchronousity of signals hopefully no attack vector / problem.)
No healing in sight for this.

On the server there is only

  # find /sbin /bin /usr/sbin /usr/bin -perm /4000
  /bin/bbsuid

but most daemons will not even be able to find that, or much in
their /dev/ etc.  Like my local web browser, which is, except for
armed perpetrators, the far biggest attack surface here.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: shell escapes in utilities

[Niklas Karlsson]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

Den tis 1 aug. 2023 kl 22:48 skrev Steffen Nurpmeso <steffen@sdaoden.eu>:

> Niklas Karlsson wrote in
>  |
>  |To be fair, local root exploits are a bit of a different animal from
>  |remote ones. Even now, if you have physical access to your average *nix
>  |box, you can likely gain root. Sure, there are ways and means of
>
> I find this a provocative statement even in the silly saison.
> I would assume that despite EFI firmware snooping key presses when
> entering the disk key on cold boot, or other sort of nifty spying
> (the famous USB sticks that "turn into keyboards and send key
> presses" (as root?) cross my mind), i would think that you have
> a hard time as a normal user to become root.  On this box; even
> though you are not further separated via "ip netns exec .. unshare
> .." etc.; some SETUID programs exist
>
>
[...]

I'm sorry, I'm having trouble parsing what you're saying here, other than
that a physically present user would have difficulty becoming root. But
yes, obviously an encrypted disk would present a major obstacle.


>
>  |preventing that, but IME it's really only people doing really secret
>  |spook stuff that bother with those. Even engineering outfits with big
>  |secrets to protect usually don't bother.
>  |
>  |What you did with that RS/6000 sounds roughly equivalent to booting a
>  |modern Linux box in single-user mode, where you can also set the root
>  |password to anything you like.
>
> Not here.
>

Very well, then your installation is a lot more ambitious than most I've
come across.

Niklas

[-- Attachment #2: Type: text/html, Size: 2191 bytes --]

[TUHS] Re: shell escapes in utilities

[Dave Horsfall]

On Tue, 1 Aug 2023, Niklas Karlsson wrote:

> What you did with that RS/6000 sounds roughly equivalent to booting a 
> modern Linux box in single-user mode, where you can also set the root 
> password to anything you like.

Not just Penguin boxes...

-- Dave

[TUHS] Re: shell escapes in utilities

[Grant Taylor via TUHS]

On 8/1/23 1:55 PM, Niklas Karlsson wrote:
> What you did with that RS/6000 sounds roughly equivalent to booting 
> a modern Linux box in single-user mode, where you can also set the 
> root password to anything you like.

I think that's *HIGHLY* dependent on the distribution.  Some systems 
make it harder than others to get into single user mode.  I feel like 
"sulogin" comes into play here.

The thing that I used to do is append "init=/bin/sh" to the GRUB boot 
line via the transient editor.  Drops you at a shell and bypasses almost 
all of the startup scripts.  Obviously there are ways to secure against 
this.  But, again, it depends on the distro.



Grant. . . .

[TUHS] Re: shell escapes in utilities

[Niklas Karlsson]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Den ons 2 aug. 2023 kl 05:01 skrev Grant Taylor via TUHS <tuhs@tuhs.org>:

> On 8/1/23 1:55 PM, Niklas Karlsson wrote:
> > What you did with that RS/6000 sounds roughly equivalent to booting
> > a modern Linux box in single-user mode, where you can also set the
> > root password to anything you like.
>
> I think that's *HIGHLY* dependent on the distribution.  Some systems
> make it harder than others to get into single user mode.  I feel like
> "sulogin" comes into play here.
>
> The thing that I used to do is append "init=/bin/sh" to the GRUB boot
> line via the transient editor.  Drops you at a shell and bypasses almost
> all of the startup scripts.  Obviously there are ways to secure against
> this.  But, again, it depends on the distro.
>

Sure. Like I said, there are ways and means to avoid this. Not going to
argue against that.

Niklas

[-- Attachment #2: Type: text/html, Size: 1266 bytes --]

[TUHS] Re: shell escapes in utilities

[Grant Taylor via TUHS]

On 8/1/23 1:43 PM, Ron Natalie wrote:
> Yep, the need for shell escapes largely went away with windowing and job 
> control.

Eh ... I don't know about that.

I routinely use :'<,'>!sort or some similar external filter program on 
lines in the file that I'm working with.

:'a,'b!base64 -d

Maybe I'm in the minority in doing such things.

My understanding is that those require shell escapes to function.



Grant. . . .

[TUHS] Re: shell escapes in utilities

[Rich Salz]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

> I routinely use :'<,'>!sort or some similar external filter program on
> lines in the file that I'm working with.
>

I don't think of that as a shell escape the way we seem to be using it.
Piping to a sub process is not the same as spawning and interactive
subshell.

>

[-- Attachment #2: Type: text/html, Size: 726 bytes --]

[TUHS] Re: shell escapes in utilities

[Grant Taylor via TUHS]

On 8/2/23 5:49 AM, Rich Salz wrote:
> I don't think of that as a shell escape the way we seem to be using it. 
> Piping to a sub process is not the same as spawning and interactive 
> subshell.

That's why I asked for clarification of what "shell escape" is in the 
context of this discussion.

I can tell you from a sudo point of view, having vim et al. use 
:'<,'>!sort is considered a shell escape in that the authorized program 
(/path/to/)vim is executing a sub-process.  It is possible to allow use 
of vim while preventing it from calling external processes via sudo.

I agree that :'<,'>!sort isn't something like breaking out of something 
intended to contain you.



-- 
Grant. . . .

[TUHS] Re: shell escapes in utilities

[Clem Cole]

[-- Attachment #1.1: Type: text/plain, Size: 1181 bytes --]

On Tue, Aug 1, 2023 at 10:59 PM Grant Taylor via TUHS <tuhs@tuhs.org> wrote:

> I routinely use :'<,'>!sort or some similar external filter program on
> lines in the file that I'm working with.
>
No doubt.  Pretty much the intended use. I've been doing that since I first
learned ed(1) and discovered I could do the same.   It always seemed
natural and handy [sort(1), tr(1), and fmt(1) are probably the filters I
use the most over the years -- as I pretty much have the switches for the
same burned into the ROMs in my fingers].  If I had grown up with GUI's, I
suspect I might have used cut/paste in some manner to do the same thing
(for me, a less natural sequence).

As Ron points out, in using more(1) on the RS/6000 in maintenance mode,
shell escape on a multi-tasking system opens up some interesting security
paths/unintended side effects.  Security is thought to get right.  So many
places where good ideas can bite you when abused.  It does not make it a
bad idea.   But you need to consider other uses that might not behave the
way you planned.

This brings us back to Roz's warning to Mike: "*Always Watching.*"
[image: AlwaysWatching.png]
ᐧ

[-- Attachment #1.2: Type: text/html, Size: 2873 bytes --]

[-- Attachment #2: AlwaysWatching.png --]
[-- Type: image/png, Size: 409883 bytes --]

[TUHS] Re: shell escapes in utilities

[Ori Bernstein]

On Tue, 1 Aug 2023 08:30:41 -0700, ron minnich <rminnich@gmail.com> wrote:

> I'm ok with things like ed, I'm more thinking of situations where
> people would (e.g.) use xdvi to view a file, and Bad Things Happened.
> I don't think ed counts, unless we're that worried about scripts.
> 

well, it's a problem when things (*cough*patch*cough*) shell out
to ed...

-- 
    Ori Bernstein

[TUHS] Re: shell escapes in utilities

[ron minnich]

yeah, good point.

On Tue, Sep 19, 2023 at 9:56 AM Ori Bernstein <ori@eigenstate.org> wrote:
>
> On Tue, 1 Aug 2023 08:30:41 -0700, ron minnich <rminnich@gmail.com> wrote:
>
> > I'm ok with things like ed, I'm more thinking of situations where
> > people would (e.g.) use xdvi to view a file, and Bad Things Happened.
> > I don't think ed counts, unless we're that worried about scripts.
> >
>
> well, it's a problem when things (*cough*patch*cough*) shell out
> to ed...
>
> --
>     Ori Bernstein

[TUHS] Re: shell escapes in utilities

[Phil Budne]

Both more and less!

[TUHS] Re: shell escapes in utilities

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

Ron

I never understood why sendmail needed it.  [Actually I never really
understand sendmail's need but that's another discussion and discussion
I've had with Ertc over the years]. But shell escape were pretty typical,
until Kulp's ^Z job control stuff and/or real window managers - it would
have sucked not to have had them.
Off the top of my head:

   - any editor (text or graphical)
   - things that controlled the screen like more(1) would have wanted to
   support something like this
   - programs that produced graphical output -- from *roff/tex and the
   like, to many/most of the CAD programs, or even Ghostscript I think.  You
   might want to dump out and suck back in something processed from another
   program, and the 'pipeline' was not always the easy/right way to do that.
   Classic example of calling on the PS/EPS tools from inside of troff.  This
   is why tools like xdvi and the like supported it.
   - long-running games where you did not want to lose your session
   - many things that supported remote job entry/execution - which was
   really common in the old days [hence UUCP, the PWB RJE tools, rsh and the
   like].  IICR there was a couple of versions of telnet/supdup that could do
   it.

Clem
ᐧ
ᐧ

On Tue, Aug 1, 2023 at 1:48 AM ron minnich <rminnich@gmail.com> wrote:

> I got to wondering, based on the sendmail discussions, how many shell
> escapes have appeared over the years?
>
> uucp
> sendmail
> xdvi : "The "allowShell" option enables the shell escape in PostScript
> specials"
>
> There must be a lot of them, however.
>

[-- Attachment #2: Type: text/html, Size: 2947 bytes --]

[TUHS] Re: shell escapes in utilities

[Grant Taylor via TUHS]

On 8/1/23 12:47 AM, ron minnich wrote:
> I got to wondering, based on the sendmail discussions, how many shell 
> escapes have appeared over the years?

Please clarify what you mean by "shell escape".  I think that there are 
a LOT of programs that can shell out and run arbitrary commands while in 
the program.

Sudo also uses this phrasing for references to things like this.

Then there are abuses of shell escapes used as vulnerability / vectors 
to attack things.



Grant. . . .