Date: Sat, 8 Dec 2007 23:59:13 -0500
Reply-To: "Richard A. DeVenezia" <rdevenezia@WILDBLUE.NET>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "Richard A. DeVenezia" <rdevenezia@WILDBLUE.NET>
Organization: Internet News Service
Subject: Re: Update: SAS/InrNet Application Dispatcher Problem
Alan Churchill wrote:
> I am shocked that SAS/IntrNet permits an X command. This is not a
> small security hole but a massive one. If this is the case, then I
> would seriously question why. A simple textbox would then open the
> server to compromise or am I missing something?
> Alan Churchill
It all depends on the AppSrv options.
All broker inputs are normally tweaked via AppSrv option
However there is a appsrv_unsafe() that lets the developer use the raw
Supposing some really dumb developer did an unsafe coding consisting of
and inputX was unsafe and had the value
All Your Base Are Belong To Us"; X "Some nasty OS command
Then there is a massive issue at hand.
Typically the X command is disabled via the SAS session startup option
If this is _not_ the current default pushed out by the SAS service creation
wizards, then I am surprised.
So again, whether or not it is allowed is based on the SAS command line and
configuration file used to start the code containing the APPSRV invocation.
XCMD can not be turned on once the session is running. I don't know if the
option setting is 'protected' from arbitrary memory modifications that could
be accomplished via CALL POKE.
When NOXCMD is active, attempts to use a PIPE fileref will fail with
ERROR: Insufficient authorization to access PIPE.
ERROR: Error in the FILENAME statement.
There are still security issues of concern for code submitted in the APPSRV
environment. Two that come to mind are:
- component objects (javaobj in particular -- appropriate security policies
must be in place for the Vm being used) and
- CALL MODULE routines that interface directly with OS shared objects or
Richard A. DeVenezia