Disable shell escapes?

[Wastrel-zz]

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.

[LydiaMarieWilliamson]

"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.

[Wastrel-zz]

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>.

[Wastrel-zz]

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>.

[Wastrel-zz]

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>.

[LydiaMarieWilliamson]

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.)

[Wastrel-zz]

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: ***@***.***>