ASP page running command-line application using WScript.Shell.Exec: Fails because of insufficient pr

Hi folks,

I'm afraid that I feel a bit of a doofus not being able to figure this out
and I'm running short of combinations of words to feed into google and MSDN
that might render a solution.

To cut a long story short, I have an ASP web page that is running a
command-line application that I have written to perform various internal
operations across many computers. It fires up, starts a bunch of threads,
does some work and then writes its results out in XML to STDOUT. The
application is started with WScript.Shell.Exec() and the app's output is
then read with a .StdOut.ReadAll() to be parsed by the ASP page.

The ASP page is meant to be accessed on the web site (which is fine). The
executable should only be able to be executed by the ASP page, not by any
web site visitors.

And, it works. Sort of. The application is run, but it bails with all sorts
of privilege errors which the ASP application catches in the
StdOut.ReadAll(). Further investigation led me to discover that the threads
that the command line tool fires up to do its magic were not starting due to
insufficient privs.

After a few days of research into this, I ended up discovering a solution (a
really, really nasty one):

.... change the default application pool to use the local system account on
the identity tab.

Now I don't want to do this because it is nasty on so many levels from a
security point of view that I'd not be able to sleep at night. I wanted to
leave the main web site as its default secure Network Service. So I figured
that this would work:

1. Create a virtual directory mapped to a folder containing the command line
tools in the web site in question

2. Create a new application pool with the local system identity

3. Assign the virtual directory to the new application pool

I figured that this would mean that the main ASP pages (i.e., the actual
stuff served to clients) would be nice and safe, but when I wanted to
execute the command line tools, I could do so with elevated privs and thus
create threads, open files and do whatever my little C++ app wanted to do
without worries.

Unfortunately, this does not work.

Whilst the command line tool can still be executed, it fails initialising
its threads, events and windows sockets.

I recognise I probably look like an IIS idiot here and I've probably simply
misunderstood how all this stuff works and I would be enormously grateful
for any pointers that would lead me to a secure solution. I'm afraid I'm no
IIS expert, just a C++ programmer lost in IIS configuration and security.

As I mentioned, so far, the only solution I have that works is to flip the
DefaultAppPool to "Local System". I know that there is a way of doing what I
want without compromising the entire security of IIS. Reading
recommendations, documentation pointers or thoughts and ideas on what I'm
doing wrong or misunderstanding would put a cheshire cat sized smile on a
tired, coffee filled programmer :-)

Thanks!

--
"Does this smell like chloroform to you?"

Re: ASP page running command-line application using WScript.Shell.Exec: Fails because of insufficien

Hi,

By default Network Service doesn't have permissions to cmd.exe. I'm
wondering if Shell.Exec() requires access to cmd.exe at all?

Alternatively, is tehre any way you can convert your .exe to a COM dll? Or
even a CGI (you could call the CGI from within your ASP page by using
ServerHTTPXML library)?

Cheers
Ken

"Toby Simpson" wrote in message
news:uG47vTFWIHA.4904@TK2MSFTNGP06.phx.gbl...
> Hi folks,
>
> I'm afraid that I feel a bit of a doofus not being able to figure this out
> and I'm running short of combinations of words to feed into google and
> MSDN that might render a solution.
>
> To cut a long story short, I have an ASP web page that is running a
> command-line application that I have written to perform various internal
> operations across many computers. It fires up, starts a bunch of threads,
> does some work and then writes its results out in XML to STDOUT. The
> application is started with WScript.Shell.Exec() and the app's output is
> then read with a .StdOut.ReadAll() to be parsed by the ASP page.
>
> The ASP page is meant to be accessed on the web site (which is fine). The
> executable should only be able to be executed by the ASP page, not by any
> web site visitors.
>
> And, it works. Sort of. The application is run, but it bails with all
> sorts of privilege errors which the ASP application catches in the
> StdOut.ReadAll(). Further investigation led me to discover that the
> threads that the command line tool fires up to do its magic were not
> starting due to insufficient privs.
>
> After a few days of research into this, I ended up discovering a solution
> (a really, really nasty one):
>
> ... change the default application pool to use the local system account on
> the identity tab.
>
> Now I don't want to do this because it is nasty on so many levels from a
> security point of view that I'd not be able to sleep at night. I wanted to
> leave the main web site as its default secure Network Service. So I
> figured that this would work:
>
> 1. Create a virtual directory mapped to a folder containing the command
> line tools in the web site in question
>
> 2. Create a new application pool with the local system identity
>
> 3. Assign the virtual directory to the new application pool
>
> I figured that this would mean that the main ASP pages (i.e., the actual
> stuff served to clients) would be nice and safe, but when I wanted to
> execute the command line tools, I could do so with elevated privs and thus
> create threads, open files and do whatever my little C++ app wanted to do
> without worries.
>
> Unfortunately, this does not work.
>
> Whilst the command line tool can still be executed, it fails initialising
> its threads, events and windows sockets.
>
> I recognise I probably look like an IIS idiot here and I've probably
> simply misunderstood how all this stuff works and I would be enormously
> grateful for any pointers that would lead me to a secure solution. I'm
> afraid I'm no IIS expert, just a C++ programmer lost in IIS configuration
> and security.
>
> As I mentioned, so far, the only solution I have that works is to flip the
> DefaultAppPool to "Local System". I know that there is a way of doing what
> I want without compromising the entire security of IIS. Reading
> recommendations, documentation pointers or thoughts and ideas on what I'm
> doing wrong or misunderstanding would put a cheshire cat sized smile on a
> tired, coffee filled programmer :-)
>
> Thanks!
>
> --
> "Does this smell like chloroform to you?"
>
>

Re: ASP page running command-line application using WScript.Shell.Exec: Fails because of insufficien

"Ken Schaefer" wrote in message
news:u9O8iGNWIHA.4076@TK2MSFTNGP03.phx.gbl...
> By default Network Service doesn't have permissions to cmd.exe. I'm
> wondering if Shell.Exec() requires access to cmd.exe at all?
> Alternatively, is tehre any way you can convert your .exe to a COM dll? Or
> even a CGI (you could call the CGI from within your ASP page by using
> ServerHTTPXML library)?

No easy way -- but I did find a way around this issue in the end without
compromising security of IIS. I re-wrote the command line application to
remove its reliance on threads. Thanks for your thoughts on this, though.