Disable shell escapes? #13
Comments
|
"I don't understand the code well enough to look for this feature and change it." I do. The function protct() - which is mostly disabled in this repository's version of fork (as well as in the C code of the other "zork" repositories on GitHub, including mine), as well as in the "PROTCT" function contained in the Fortran versions of Zork in the various "zork-fortran" archives on GitHub (including mine) - is the function meant for use in this way. The comments adjoining the function definition say so. To check for protection levels, if could be turned into a system-dependent function to obtain or check against the current user / protection level, which could then be used at various points where you wish to limit accessibility. In both the Fortran version and the 1991 C translation (as well as in the version 3.2 Fortran version), it is only used once in the initialization routine as a stub, with the original programmers' recommendation having been to use it as an "office hours" check. The issue of accessibility to your SSH is essentially equivalent to the issue of accessibibility to business systems on business time, so it should be treated in an analogous way. |
|
Thank you. I should have updated my post.
I *think* I found a way around the issue. I had to make a front end for zork that prevents the user from getting to a shell. I did it by having every user run his own game in his own directory with no shell ...
Here is my script:
#[Intro]
read -p "Press a key to start."
cd /usr/games/zork
if [[ ! -e ./$USER ]]
then
mkdir $USER
cp zork $USER
cp dtextc.dat $USER
cd $USER
else
cd $USER
fi
PATH=/usr/games/zork/$USER
SHELL=/bin/false
/usr/games/zork/$USER/zork
. /home/gameplayer/.bashrc # return $USER to the gameplayer shell upon normal exit from the game
Here is what happens when the user tries to access a shell:
You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
!
!
!cmd
sh: 1: cmd: not found
!bash
sh: 1: bash: not found
!sh
sh: 1: sh: not found
!false
ls
I don't understand that.
what?
I don't understand that.
hello
Nice weather we've been having lately. ## Is this built into the game?
quit
Your score would be 0 [total of 585 points], in 4 moves.
This gives you the rank of Beginner.
Do you wish to leave the game?
n
w
You are in a forest, with trees in all directions around you.
!false
bash
I don't understand that.
!bash
sh: 1: bash: not found
^CConnection closed by foreign host.
Connection to iwastrel.com closed.
That seems to work. If you see any flaws, please tell me.
Eric
http://iWastrel.com
…________________________________
From: LydiaMarieWilliamson ***@***.***>
Sent: Saturday, October 9, 2021 7:58 PM
To: devshane/zork ***@***.***>
Cc: Wastrel ***@***.***>; Author ***@***.***>
Subject: Re: [devshane/zork] Disable shell escapes? (#13)
"I don't understand the code well enough to look for this feature and change it."
I do. The function protct() - which is mostly disabled in this repository's version of fork (as well as in the C code of the other "zork" repositories on GitHub, including mine), as well as in the "PROTCT" function contained in the Fortran versions of Zork in the various "zork-fortran" archives on GitHub (including mine) is mostly disabled - is the function meant for use in this way. The comments adjoining the function say so.
To check for protection levels, if could be turned into a system-dependent function to obtain or check against the current user / protection level, which could then be used at various points where you wish to limit accessibility. In both the Fortran version and the 1991 C translation (as well as in the version 3.2 Fortran version), it is only used once in the initialization routine as a stub, with the original programmers' recommendation having been to use it as an "office hours" check. The issue of accessibility to your SSH is essentially equivalent to the issue of accessibibility to business systems on business time, so it should be treated in an analogous way.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#13 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUIWIRKEIK3W5326DMXIFDUGDQMPANCNFSM4PR6BJ3A>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
There are indeed flaws, such as echoing environmental variables:
!echo $PATH
/usr/games/zork/honeybunch
!echo $SHELL
/bin/false
!echo $HOME
/home/gameplayer
and
!echo *
dsave.dat dsavec.dat dtextc.dat hello zork
It looks like someone could execute a forkbomb though...
Eric
http://iWastrel.com
…________________________________
From: LydiaMarieWilliamson ***@***.***>
Sent: Saturday, October 9, 2021 7:58 PM
To: devshane/zork ***@***.***>
Cc: Wastrel ***@***.***>; Author ***@***.***>
Subject: Re: [devshane/zork] Disable shell escapes? (#13)
"I don't understand the code well enough to look for this feature and change it."
I do. The function protct() - which is mostly disabled in this repository's version of fork (as well as in the C code of the other "zork" repositories on GitHub, including mine), as well as in the "PROTCT" function contained in the Fortran versions of Zork in the various "zork-fortran" archives on GitHub (including mine) is mostly disabled - is the function meant for use in this way. The comments adjoining the function say so.
To check for protection levels, if could be turned into a system-dependent function to obtain or check against the current user / protection level, which could then be used at various points where you wish to limit accessibility. In both the Fortran version and the 1991 C translation (as well as in the version 3.2 Fortran version), it is only used once in the initialization routine as a stub, with the original programmers' recommendation having been to use it as an "office hours" check. The issue of accessibility to your SSH is essentially equivalent to the issue of accessibibility to business systems on business time, so it should be treated in an analogous way.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#13 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUIWIRKEIK3W5326DMXIFDUGDQMPANCNFSM4PR6BJ3A>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Welcome to Dungeon. This version created 11-MAR-91.
You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
!:(){:|:&};:
sh: 1: Syntax error: Bad function name
Nope. (Yes, I did try it.)
"The issue of accessibility to your SSH is essentially equivalent to the issue of accessibibility to business systems on business time, so it should be treated in an analogous way."
I have little understanding of what that means... but I plan to keep ssh access open 24/7/365 so I will do nothing about accessibility.
Eric
http://iWastrel.com
…________________________________
From: LydiaMarieWilliamson ***@***.***>
Sent: Saturday, October 9, 2021 7:58 PM
To: devshane/zork ***@***.***>
Cc: Wastrel ***@***.***>; Author ***@***.***>
Subject: Re: [devshane/zork] Disable shell escapes? (#13)
"I don't understand the code well enough to look for this feature and change it."
I do. The function protct() - which is mostly disabled in this repository's version of fork (as well as in the C code of the other "zork" repositories on GitHub, including mine), as well as in the "PROTCT" function contained in the Fortran versions of Zork in the various "zork-fortran" archives on GitHub (including mine) is mostly disabled - is the function meant for use in this way. The comments adjoining the function say so.
To check for protection levels, if could be turned into a system-dependent function to obtain or check against the current user / protection level, which could then be used at various points where you wish to limit accessibility. In both the Fortran version and the 1991 C translation (as well as in the version 3.2 Fortran version), it is only used once in the initialization routine as a stub, with the original programmers' recommendation having been to use it as an "office hours" check. The issue of accessibility to your SSH is essentially equivalent to the issue of accessibibility to business systems on business time, so it should be treated in an analogous way.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#13 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUIWIRKEIK3W5326DMXIFDUGDQMPANCNFSM4PR6BJ3A>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
On Sat, 2021-10-09 at 20:18 -0700, Wastrel wrote:
Thank you. I should have updated my post.
I *think* I found a way around the issue.
I had to make a front end for zork that prevents the user from
getting to a shell. I did it by having every user run his own game in
his own directory with no shell ...
This is actually a point where the function protct() (or PROTCT() in
the Fortran version) would be used. In the C version in the file np.c
is:
// NO SHELL ESCAPE /+TAA+/
if (buffer[0] == '!') {
system(buffer + 1);
goto L5;
}
so the appropriate adjustment would be
if (buffer[0] == '!' && ... a check involving protct() ...) {
system(buffer + 1);
goto L5;
}
Inside the protct() function, itself, is where you'd want to insert the
various conditions or checks you're trying to do on the outside with
shell scripts.
In the Fortran version (at least in my copy, now), the corresponding
code in np.f (or np.for) is commented out and there are no shell
escapes at all.
In the original sources, a distinction was made between what type of
input device (if any) the user had; in order to control how the output
was "paged" or (more generally) broken up or parcelled out. It was
disabled, but kept around as unused legacy code. That's actually the
place where it would be most appropriate to put in networking-dependent
or windowing-dependent code, as well, generalizing the concept of
"terminal" to "network connection" or "window", and perhaps reusing
some of those legacy routines to that end. Note, for instance, that
"crows" and "coutput" are mostly unused. In a windowed input device,
that might be used to track the location of the output on a window and
the dimensions of the window.
There is no harm in using the system copy of the *.dat files. They are
read-only and both the C and Fortran programs are very stringent about
buffering - the Fortran version more so. In my copy of the C version of
Zork, you'll see that I retrofit part of the Fortran original back in,
made the input routine buffered again, rather than character-based, and
separated back out the "story" database from the "index" database - as
they are in the Fortran version. The access to the story database are
in the dsub.c and dsub.f files and is confined to the routine GetRec()
in both the C and Fortran versions. The file is accessed as a stream
(which you can do in Fortran now, but not in Fortran 77). Nonetheless,
items are buffered.
In the modified version of both the Fortran and C code and the original
version of the Fortran code, the record-retrieval is inside a loop,
because an output may span multiple records, so it could overshoot the
message boundary, if the file is corrupted. But, there is an end-of-
file check in the routines, both original and modified. In the 1991
translation of the C code, access was character-based as a stream, so
the loop was a one-character-at-a-time read routine. But, it also had
an end-of-file test.
I set up a decompiler routine in the modified sources (readit.c and
readit.f), so you can view the contents of the story and index files. I
also wrote a re-compiler (writeit.c and writeit.f), but haven't yet
added them to the source files.
Version 4 of the Fortran source, by the way, has a story and index file
compiler. It keeps the story and index database files separate, as does
version 3, and uses fixed-length buffering, like version 3; not
streaming, as I do now. When I get more time, I will add version 4 to
my copy of the Zork source and try to finish linking up the github
history-streams of all the versions I have. (My copy of "zork" is
currently mirrored in the "C1991" directory of my copy of "zork-
fortran", and is identical to the newer C translation in "C2021" under
zork-fortran, but they haven't yet been merged.)
|
|
Dear Lydia,
Thank you for your continued interest. I don't have the code to modify, I have no need for the code, and changing it may be beyond my ability, anyway. My rather clumsy solution works. It's not possible for a user to escape to a shell or execute anything that requires a shell.
I think the thread should be closed. Nobody uses my ssh connection anyway. Nobody wants to play text games. And I have moved on to other things.
Eric
http://iWastrel.com
________________________________
From: LydiaMarieWilliamson ***@***.***>
Sent: Thursday, December 23, 2021 7:52 PM
To: devshane/zork ***@***.***>
Cc: Wastrel ***@***.***>; Author ***@***.***>
Subject: Re: [devshane/zork] Disable shell escapes? (#13)
On Sat, 2021-10-09 at 20:18 -0700, Wastrel wrote:
Thank you. I should have updated my post.
I *think* I found a way around the issue.
I had to make a front end for zork that prevents the user from
getting to a shell. I did it by having every user run his own game in
his own directory with no shell ...
This is actually a point where the function protct() (or PROTCT() in
the Fortran version) would be used. In the C version in the file np.c
is:
// NO SHELL ESCAPE /+TAA+/
if (buffer[0] == '!') {
system(buffer + 1);
goto L5;
}
so the appropriate adjustment would be
if (buffer[0] == '!' && ... a check involving protct() ...) {
system(buffer + 1);
goto L5;
}
Inside the protct() function, itself, is where you'd want to insert the
various conditions or checks you're trying to do on the outside with
shell scripts.
In the Fortran version (at least in my copy, now), the corresponding
code in np.f (or np.for) is commented out and there are no shell
escapes at all.
In the original sources, a distinction was made between what type of
input device (if any) the user had; in order to control how the output
was "paged" or (more generally) broken up or parcelled out. It was
disabled, but kept around as unused legacy code. That's actually the
place where it would be most appropriate to put in networking-dependent
or windowing-dependent code, as well, generalizing the concept of
"terminal" to "network connection" or "window", and perhaps reusing
some of those legacy routines to that end. Note, for instance, that
"crows" and "coutput" are mostly unused. In a windowed input device,
that might be used to track the location of the output on a window and
the dimensions of the window.
There is no harm in using the system copy of the *.dat files. They are
read-only and both the C and Fortran programs are very stringent about
buffering - the Fortran version more so. In my copy of the C version of
Zork, you'll see that I retrofit part of the Fortran original back in,
made the input routine buffered again, rather than character-based, and
separated back out the "story" database from the "index" database - as
they are in the Fortran version. The access to the story database are
in the dsub.c and dsub.f files and is confined to the routine GetRec()
in both the C and Fortran versions. The file is accessed as a stream
(which you can do in Fortran now, but not in Fortran 77). Nonetheless,
items are buffered.
In the modified version of both the Fortran and C code and the original
version of the Fortran code, the record-retrieval is inside a loop,
because an output may span multiple records, so it could overshoot the
message boundary, if the file is corrupted. But, there is an end-of-
file check in the routines, both original and modified. In the 1991
translation of the C code, access was character-based as a stream, so
the loop was a one-character-at-a-time read routine. But, it also had
an end-of-file test.
I set up a decompiler routine in the modified sources (readit.c and
readit.f), so you can view the contents of the story and index files. I
also wrote a re-compiler (writeit.c and writeit.f), but haven't yet
added them to the source files.
Version 4 of the Fortran source, by the way, has a story and index file
compiler. It keeps the story and index database files separate, as does
version 3, and uses fixed-length buffering, like version 3; not
streaming, as I do now. When I get more time, I will add version 4 to
my copy of the Zork source and try to finish linking up the github
history-streams of all the versions I have. (My copy of "zork" is
currently mirrored in the "C1991" directory of my copy of "zork-
fortran", and is identical to the newer C translation in "C2021" under
zork-fortran, but they haven't yet been merged.)
—
Reply to this email directly, view it on GitHub<#13 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUIWIUAOFPVDH7R7CVTWXTUSPG6XANCNFSM4PR6BJ3A>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am adding this to my ssh server, but I don't want players to be able to execute arbitrary commands. I've got it mostly solved by a script that sets a very limited path and sets the shell to /bin/false, EXCEPT the !echo command can still be executed. It is possible to echo text to either of the .dat files, or create new files. I don't like that. I doubt if echo can be used to create an executable virus file etc. but I still don't like it. Do you have any ideas? I don't understand the code well enough to look for this feature and change it.
The text was updated successfully, but these errors were encountered: