|
Good points, for sure. The MGOS 2.0 docs here
seem to say that it used to only handle SELECT queries, and that
anything else would return MgFdoException....either that got changed
at some point after v2.0 or that statement was wrong. If it got
changed, maybe it's just a matter of looking how it was handled in
that older version? You might be able to revert and take some ideas
from there....if that statement was just plain wrong though, you
might be right - getting rid of it might be easiest. When I'd made my comments, I was thinking of a very basic sql grammer parser, yes. Even just something as simple as making sure the statement starts with "select" and doesn't have any commands that you'd like to block. Personally, I don't use ExecuteSqlQuery, so I'm not going to be affected! And maybe no one's really using it...maybe it's no big deal to get rid of it. My suggestion was just the first thing to come to mind after reading that rfc. On 13/06/17 10:52 AM, Jackie Ng wrote: In hindsight I probably should've had hotfixes on hand first before making this announcement.Nevertheless, if you want to patch this vulnerability out first and discuss later, I've added hotfix dlls for MGOS 2.2, MGOS 2.4, MGOS 2.5 to the RFC page. Simply overwrite the MgHttpHandler.dll under your <MapGuide Install>\Web\Php and <MapGuide Install>\Web\www\mapagent directories Once you've applied this hotfix and restarted your web server, your MapGuide installation will no longer support the EXECUTESQLQUERY operation in the mapagent, plugging up this particular vulnerability. Linux users can apply the given patch and compile a new libMgHttpHandler.so. I'm somewhat strained on Linux build resources, so if others can chip in and provide patched libMgHttpHandler.so files for the various versions of MGOS, that would be great. Now to actually respond to your post. I mention the lack of SQL safeguards, but I don't think implementing such safeguards is going to be that "simple". How do we: a) Guard against SQL injection (EXECUTESQLQUERY doesn't use bind parameters)? b) Prevent joining against tables that aren't meant or supposed to be joined? c) Protect against un-authorized SQL execution from session-based copies of a Feature Source? d) Most importantly, do all of this in C++? Do we have to implement our own SQL grammar parser? How do we handle the various DBMS-specific dialects? There's a lot of unknowns and lots of risks involved. And for what? To execute SQL over the internet via HTTP? That sentence alone smells of security holes waiting to be punched wide open! This RFCs says to take the easiest path: gut this feature out until we can rethink how to do this in a safe manner if that's even possible! I currently think it's not. Especially not over a public-facing component like the mapagent. - Jackie -- View this message in context: http://osgeo-org.1560.x6.nabble.com/IMPORTANT-MapGuide-RFC-136-is-ready-for-review-tp5060534p5060600.html Sent from the MapGuide Users mailing list archive at Nabble.com. _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users --
Andrew DeMerchant |
_______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
