Date:         Sun, 9 Dec 2007 18:02:04 -0700
Reply-To:     Alan Churchill <savian001@GMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Alan Churchill <savian001@GMAIL.COM>
Subject:      Re: Update: SAS/InrNet Application Dispatcher Problem
Comments: To: paul@WUBIOS.WUSTL.EDU
In-Reply-To:  <20071209165933.ttj5x9o0rqos0gc8@secure.biostat.wustl.edu>
Content-Type: text/plain; charset="iso-8859-1"

Paul,

Up to a point. SAS should ship IntrNet with a minimal surface area and then
allow people to open it up similar to IIS. If X is allowed by default, I
don't think that is a sustainable position.

Alan

Alan Churchill
Savian
www.savian.net



-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Paul
Thompson
Sent: Sunday, December 09, 2007 4:00 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Update: SAS/InrNet Application Dispatcher Problem

Quoting "Richard A. DeVenezia" <rdevenezia@WILDBLUE.NET>:

To my view, this is like saying that if you shoot yourself in the
head, it might not be a good idea.  Yep, you sure can put yourself in
a world of hurt by building an x command that can be accessed from
users on the web.

My solution: Do not do that.  Not a good idea.  Do not set up an X
command that can be accessed by users on the web.


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