1 Aug
2023
1 Aug
'23
5:47 a.m.
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.
1 Aug
1 Aug
11:38 a.m.
ron minnich <rminnich(a)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(a)vuxu.org> https://leahneukirchen.org/
12:31 p.m.
At 2023-08-01T13:38:55+0200, Leah Neukirchen wrote:
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
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 
8:33 p.m.
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
8:40 p.m.
Dave Horsfall <dave(a)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
2:29 p.m.
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(a)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.
3:30 p.m.
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(a)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(a)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.
6:43 p.m.
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.
6:55 p.m.
Den tis 1 aug. 2023 kl 20:43 skrev Ron Natalie <ron(a)ronnatalie.com>om>:
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
8:48 p.m.
Niklas Karlsson wrote in
<CAK6BEgegH3TeE4ETM489s70jV4xDFzEJF1EV7u2QPkHEr4pCFA(a)mail.gmail.com>om>:
|Den tis 1 aug. 2023 kl 20:43 skrev Ron Natalie <ron(a)ronnatalie.com>om>:
|> 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)
9:11 p.m.
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…
9:52 p.m.
Ron Natalie wrote in
<em4ad243a6-02bf-4d7e-924a-3fe4a00e2c06(a)a70c2ae8.com>om>:
|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)
9:13 p.m.
Den tis 1 aug. 2023 kl 22:48 skrev Steffen Nurpmeso <steffen(a)sdaoden.eu>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
2 Aug
2 Aug
3:01 a.m.
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. . . .
3:42 a.m.
Den ons 2 aug. 2023 kl 05:01 skrev Grant Taylor via TUHS <tuhs(a)tuhs.org>rg>:
On 8/1/23 1:55 PM, Niklas Karlsson wrote:
Sure. Like I said, there are ways and means to avoid this. Not going to
argue against that.
Niklas
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.
2:59 a.m.
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. . . .
2:49 p.m.
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. . . .
2:20 p.m.
On Tue, Aug 1, 2023 at 10:59 PM Grant Taylor via TUHS <tuhs(a)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]
ᐧ
19 Sep
19 Sep
4:56 p.m.
On Tue, 1 Aug 2023 08:30:41 -0700, ron minnich <rminnich(a)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
5:04 p.m.
yeah, good point.
On Tue, Sep 19, 2023 at 9:56 AM Ori Bernstein <ori(a)eigenstate.org> wrote:
On Tue, 1 Aug 2023 08:30:41 -0700, ron minnich <rminnich(a)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 
3:37 p.m.
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(a)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.
3:37 p.m.
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. . . .
232
days inactive
281
days old
24 comments
14 participants
participants (14)
-
arnold＠skeeve.com -
Clem Cole -
Dave Horsfall -
G. Branden Robinson -
Grant Taylor -
Leah Neukirchen -
Niklas Karlsson -
Ori Bernstein -
Phil Budne -
Rich Salz -
ron minnich -
Ron Natalie -
Skip Tavakkolian -
Steffen Nurpmeso