4.4BSD NFS File Handles

[aleph1 () DFW ORG (Aleph One)]

Message-ID:   <3.0.32.19970306141847.009a9a00 () mail plasticsnet com>
Date:          Thu, 6 Mar 1997 14:18:48 +0600
From:  Chris Borneman <cborneman () PLASTICSNET COM>
Subject:       Re: I.I.S and Security - No authentication of scripts.
To:  Normandy () LISTSERV MSN COM


Jason,

Thanks for your feedback.  What I've found, and I'm sure you probably can't
duplicate due to not having any other filter DLLs than ASP, is more in
regards to IIS itself, and not ASP.

Before I get into the specifics, let me reply on your points.
* I had already disabled the "Windows NT Challenge/Response" in IIS
* I have tested in IE 3.01 and Navigator 4.0 Preview 2

Here are two urls you can try. The first runs without challenge, the second
does not:
        http://pnet4.plasticsnet.com/scripts/secure/test.cfm
        http://pnet4.plasticsnet.com/scripts/secure/active.asp

Both exist in the same directory with the EXACT SAME priveledge.  That
priveledge is "READ access by SYSTEM account".  Even I cannot access that
directory (/scripts/secure) when logged in.

The entire /scripts path is set to "Execute" access in IIS.

Password authentication has "Allow Anonymous" and "Basic (Clear Text)"
activated.  The anonymous account does _not_ have access to the
/scripts/secure directory and any of its subdirectories.

The files are located on an NTFS formatted drive.  I'm running Windows NT
Server 4.0 SP2 and IIS 3.0 without the hotfix that fixes the '.' issue.

As far as the "." bug in the OS instead of IIS, here is the output on my
machine.  I cannot comment on what happens on yours.

> D:\>dir c:\autoexec.bat*
> Volume in drive C has no label.
> Volume Serial Number is 2032-A225
>
> Directory of c:\
>
> 03/06/97  01:51p                    43 AUTOEXEC.BAT
>               1 File(s)             43 bytes
>                            644,612,096 bytes free
>
> D:\>type c:\autoexec.bat..
> @echo off
> PATH C:\UTIL
> SET DIRCMD=/o:gn

Now for the specifics.

My script files have the extension CFM and are used with the product Cold
Fusion from Allaire -- www.allaire.com)

I spoke with Allaire and they are supposed to issue a maintenance release
at the end of the month.  The problem lies, according to Microsoft, in
Allaire's code.  According to Allaire, it is Microsoft's approach.  I have
to side with Allaire on this.

ASP pages are actually securing properly, although ASP itself is doing the
work.  Microsoft has contacted me from the first e-mail via (name and phone
omitted by request of Microsoft employee) and we walked through the steps
and showed ASP files secure and CFM files do not.  ASP files are securing
because within the ASP filter DLL, it is switching the security context to
the current Web user.  This is something that happens automatically within
IIS for non-script files.

Since ASP files worked, Microsoft said that IIS worked.  Microsoft
maintains it is up to the filter DLL to impersonate the client before
accessing the file.  Translated, Microsoft is letting the DLL be
responsible for security.  Still a whole in my book.  ASP doesn't have the
security hole, but IIS 3.0 does.  This therefore would also be true in IIS
2.0.

My stance is that by leaving the security to the filter DLL, you are
allowing a) malicious developers that write back doors, and b) a huge door
for unsuspecting developers of filter DLLs to not close, this being my
biggest concern.

--------------------  Allaire's Knowledge Book entry
---------------------------
BUG: Microsoft IIS Security Integration Symptoms Cold Fusion template files
that are secured are returned to the client without authentication.
Description When a client requests a page from your Web server, the
username and password of the client should be authenticated against the
file requested. Website does this in their WSAPI implementation, and
Netscape does this in their NSAPI implementation. Microsoft, however,
authenticates the username and password of the client against whatever
ISAPI dll is used (in our case, CFUSION\BIN\iscf..dll), not the file
requested. Because you can only have one set of security parameters on
iscf.dll, you can have only one set of permissions on ALL Cold Fusion
templates on a given server. Workaround: Allaire is currently investigating
this problem.
----------------------------------------------------------------------------
----



At 05:56 PM 3/6/97 +0200, you wrote:
> Hi there
>
> A friend of mine forwarded this query to me, as he knows that I
> administer an IIS-based site. Please forward this on to the mailing
> list that the question was originally posted to.
>
> >        ...much of original message deleted...
>
> >      However, if you do the same for a script, IIS still _executes_ it and
> >      sends back the results.  This isn't an issue of "Read" vs. "Execute".
> >      The script isn't readable.  The directory I'm dealing with has "Read"
> >      off and "Execute" on.  However, the script also shouldn't be
> >      accessible or ran until I provide my credentials, and that is the
> >      SECURITY HOLE.  Netscape's Server does this _correctly_, so why not
> >      Microsoft?
>
> I run IIS on 3 servers, and I cannot replicate the problem on any of
> them. The problem that you're experiencing may very well be on the
> browser side. For example, if you are using Microsoft Internet
> Explorer on the same domain as the server. This is because the
> browser supports NTLM authentication via challenge/response. Because
> this is a more secure authentication mechanism than Basic clear text
> authentication, the browser chooses NTLM. Now, because you are logged
> in as a use