Summary: | [wmsparse] security issue with wmsparse and IIS | ||
---|---|---|---|
Product: | Chameleon | Reporter: | Paul Spencer <pspencer@dmsolutions.ca> |
Component: | Core | Assignee: | Julien-Samuel Lacroix <jlacroix@mapgears.com> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | chameleon-dev@lists.maptools.org, dmorissette@mapgears.com, jfournier@dmsolutions.ca |
Priority: | P1 | ||
Version: | 1.99 | ||
Target Milestone: | 2.2 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: | |||
Bug Depends on: | 883 | ||
Bug Blocks: |
updated version to 1.99
any comments on this one? It won't be fixed for the beta but seems important to fix for the 2.0 release
Has this been verified? I have never given execute rights to IUSR_<compname> on cmd.exe for a Chameleon install ... this would be an immediate flag that something is wrong.
Changed target to 1.99 RC 1.
Jason, please try to replicate this issues with the latest chameleon. Daniel, what is the feasibility of modifying wmsparse to run as a cgi or php extension? I am hesitant to invest too much time into this issue because I really think the wmsparse utility needs to be rewritten as follows: 1. use sqlite database 2. support wms and wfs 3. modify phpwms in php_utils to use sqlite 4. check for other dependencies introduced by this 5. extensive testing of all affected code, including: - mapbrowser - chameleon When this happens, this issue becomes moot.
It's not technically difficult to modify wmsparse to run as a CGI (or even support dual mode), I could do that easily, just let me know. The question is more whether it's a good idea to move this to a CGI since it's not really a standalone service but a component of a larger system. For insance, impromer calls could result in corruption of your WMS servers cache... I guess we could try to restrict this CGI to calls from localhost, but that still doesn't sound right. It's really odd that with Windows you are forced to implement this kind of workarounds to run a local program: where else in the world do you solve a security issue by exposing your program through your web server? No wonder it's not the safest platform around.
Oh... you also asked about the feasibility of making it an extension... well, that's not too hard either, but extensions are harder to build (compile), so that adds an extra painful requirement for those installing the software so I would avoid it if we can.
Thinking out loud: Maybe it's time to start building the chameleon PHP extension which would include this wms parser utility and other services that chameleon needs and that don't fit anywhere else nicely.
I (still) have never come across this issue (as per comment#3) for either IIS 5 or 6. I will attempt to replicate.
Jason, you're the point man on this one :)
Verified: Win2K3, IIS6, Chameleon199b2, MS425. Verified using the WMSBrowser widget in OGC Sample app. Had to give cmd.exe read/execute permission for the parsing to work. Did not invesitage further as it has already been suggested that modifying the wmsparse exe would be a relatively simple process. Perhaps this could also be addressed when executing the wmsparse exe in php. eg: common/phpwms/server_data_manager.php line 840: exec( $cmd, $a, $retval ); I'm not sure if passthru() or system() would have the same requirements (or limitations)?
ok, so the original issue is valid. IIS user requires execute privileges on cmd.exe, which is considered a security issue. What should be done about this for version 1.99 and for future versions? I'd like to see some sort of minimal fix this time around as this would be an excellent candidate for including in some sort of php_chameleon module (which won't be done for this version). Perhaps the cgi model would be the easiest? Or should it be a documented limitation of working with IIS? Reassigning to Daniel for comment on the cgi approach ...
After further discussions with Paul, taking this specific issue and things like
overall security concerns, and long term maintenance into account, we decided to
go with a Chameleon PHP DL Extension to solve this.
The external wmsparse will continue to be available for those who don't want yet
another PHP extension to compile, but prebuilt Windows packages will come with
that extension, so the current IIS issue will be solved.
Created bug 883 about the new extension. Marking it as a blocker.
Reassigned to Julien.
work has progressed on this but it won't be ready for RC1 ...
I think this needs to be pushed to 2.1/2.2 because of the risk of breaking something at the last minute.
Bug 883 is about to be fixed, I think I should wait the 2.0
release/cvs-branching before modify the chameleon code to integrate the new php
extension.
sounds reasonable. We'll have to create a branch for 2.0 I guess and then we can start making this kind of modification.
targetting 2.2.
I commited the changes to CVS. I had hard time with the error handling. I ended including the CPL library for error handling. From now, if the chameleon is loaded succesfully, the new php module will be used to parse the capability document and modify the according dbf files. Marking as FIXED