On Thu, 23 Apr 1998 pedwardat_private wrote: > The Apache hack that M$ distributes allows one to create ANY directory > on a Frontpage enabled web server, and execute content in it. > This also goes for the stock Netscape Server config that M$ recommends. > > Hmm, I wonder if M$ deliberately places security holes in Unix apps so > that they can claim "but Frontpage under IIS doesn't have that hole!". > > Mainly because IIS loads Frontpage as a DLL (I suppose). Frontpage > wouldn't be anywhere near the PIG it is if it ran as an Apache module > or NSAPI module...but then who has an extra 5 megs per server process > to burn??? Trust me, you don't want the frontpage extensions running in your server's address space if you are concerned about security. There are many ways to improve on them without making them a module. In any case, if you make them a module then you are right back to the problems that older versions had where all the content was owned by the same user. > > EG: > > You want a rogue program to run, and the victim has anonymous uploadable > FTP (or you sign up for a service and you want to run binaries on the > server, but can't): > > mkdir _vti_bin > cd _vti_bin > put [whatever bin] > > Web browser: > > http://www.victim.com/somedirectorystructure/_vti_bin/trojanfile > > Boom you've got stuff runnin on that server. Not very interesting. What you are saying is that if you have access to the server, then you have access to the server. If someone has anonymous ftp uploads setup so the upload are readable and are inside a tree that is available from the web, _that_ is the problem. Well, guess what? The default Apache configuration does the same thing and I do not think it is a bug. Let me restate that: the default Apache config should be more explicit about what is enabled by default and should, for consistency's sake, completely disable htaccess files and all options except Indexes and FollowSymLinks everywhere, but the failure to do so is not a serious security bug as you claim. I should really finish rewriting the default config files to make more sense. If someone is running in a special environment where people have limited access to the machine, they have to configure their software to respect that. I am more than willing to point out flaws in Microsoft software, but you are barking up the wrong tree. There are other issues with the fp extensions. I'm not aware of anything like what there was in the past, and have not had the time nor interest to fully review the implications, however some of the implied trust relationships associated with running the scripts as the owner of the webspace concern me. This problem is not, however, easy to solve in general on Unix or most operating systems; you want a set of programs that are accessed by others to be able to read and write to part of your filesystem, you want it all to still be controlled by a normal user, you want to do this for a large number of users, and you don't want to create extra users on the system. Web servers could add a whole lot of very cool and useful features if this was easier to do securely, but I don't trust Apache running with a real or saved uid of root.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:51:06 PDT