[mapguide-users] IMPORTANT - MapGuide RFC 136 is ready for review

[Andrew DeMerchant]

Good points, for sure. The MGOS 2.0 docs here 
<http://www.osgeo.org/files/mapguide/docs/2.0/d5/d10/class_mg_feature_service_6b09a6f5e5ae73065e3d6d24110f7d81.htm> 
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
> mapguide-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-users
>

-- 
------------------------------------------------------------------------
GEMTEC Limited <http://www.gemtec.ca/>

*Andrew DeMerchant*

tel: 506.453.1025  /  toll-free: 1.877.243.6832
fax: 506.453.9470

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20130617/dbcba1e0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gemtec.png
Type: image/png
Size: 3987 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20130617/dbcba1e0/attachment.png>