LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2007, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
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
Comments: To: sas-l@uga.edu

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 > > Alan Churchill > Savian > www.savian.net

It all depends on the AppSrv options.

All broker inputs are normally tweaked via AppSrv option UNSAFE='&"%;'''

However there is a appsrv_unsafe() that lets the developer use the raw input.

Supposing some really dumb developer did an unsafe coding consisting of newdata="&inputX";

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

-- Richard A. DeVenezia http://www.devenezia.com/


Back to: Top of message | Previous page | Main SAS-L page