|
Richard,
I clarified my initial concern with Don Henderson and he indicated that the
attack I proposed would not work. Ok, round 1 to SAS/IntrNet. However, I
still think that the X command should be disabled by default in SAS/IntrNet.
I never put anything past a clever person and some time. Allowing X just
presents loads of opportunities.
Alan
Alan Churchill
Savian
www.savian.net
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Richard
A. DeVenezia
Sent: Saturday, December 08, 2007 9:59 PM
To: SAS-L@LISTSERV.UGA.EDU
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
>
> 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/
| 
