>> In other words, it stores more than email messages in a central 
>> database. Still conceptually the same deal, just with a few minor 
>> details on top.
> 
> No, not really. Shared stuff like calendars is not conceptually the same 
> as a central email store. What exchange does is inherently hard to get 
> right because (in part) of the administration/configuration problem and 
> in part because of the shared part.

So instead of sharing datestamped messages and displaying them as 
emails, you share datestamped messages and display them as calendar 
appointments. Big deal.

> A centralized email server isn't sharing anything between users, nor 
> updating things already in the database.

OK, so it's the sharing of stuff (whatever it may be) between multiple 
users that's the hard part. (Especially when each user potentially has 
an offline cache of the database.) That *is* in fact nontrivial, yes. I 
still thing it's hardly insummountable though. (Hell, M$ did it, and 
they know nothing about anything...)

>> I don't see what "windows logins" have to do with a generic web 
>> server, that's all.
> 
> Have you ever used an intranet application where you had to log in to 
> the web page?   It means it uses the Active Directory kerberos password 
> stuff to let you log into web pages.
> 
> MS SQL server allows this too.

We have a couple of 3rd party applications that do this. Apparently they 
all word by using something called LDAP (which is an open standard). You 
don't need a special feature of the web server just for that. Indeed, we 
have non-web apps that do the same trick... Some of them aren't even on 
Windows.

>>> And where does it say anything about root access there?
>>
>> It says that you can "bypass all security controls". How is that 
>> different from root access?
> 
> Where do you see it say "bypass all security controls"? I see it say 
> "bypass ASP.NET authentication capabilities". I see "bypass 
> authentication required to access files in secured directories."
> 
> What this bug is, in practice, is a way to go
>   "http://blah.com/yadda\..\..\hello.txt"
> and get out of the DocumentRoot defined by the web server. For example, 
> they could use
>   "http://blah.com/yadda\..\..\cgi\script.php"
> to see the source of your PHP CGI script.
> 
> Still not root access.

According to the blog where I first saw this mentioned, if you do

   http://example.com/priv/file1

it asks for a username and password due to the security settings on that 
folder. However, if you do

   http://example.com\priv\file1

it just serves the file, bypassing the security. This is apparently due 
to something about the way IIS works internally. (Something like 
all-access being the default, and restricted-access files being listed 
somewhere, and the name string in the URL not matching anything in the 
restrictions list. In other words, it fails-open rather than 
failing-closed...)

Either way, I'm sure this *specific* bug has long since been fixed. But 
the fact that such a simple and obvious bug happened in the first place 
isn't very reassuring. (You would surely have thought that throwing 
weird URLs at the server would be one of the very first things to check 
during testing... assuming M$ does that...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message