[Freeswitch-users] Thoughts on security/code injection/etc. in FS when allowing user supplied data

[Avi Marcus]

All of FS gives you unrestricted access -- raw XML, mod_xml_curl, lua, etc.

If you want to limit access, use http://wiki.freeswitch.org/wiki/Mod_httapi --
it has a permissions option for what the user is allowed to access.
THAT system has a permission framework. If you find a bug in there, then
there's something to do about it.
-Avi

On Sun, May 19, 2013 at 11:26 PM, Nathan Neulinger <nneul at mst.edu> wrote:

> Agreed. I was actually (in my case) less concerned about security than
> 'oops that didn't do the right thing' for stuff
> as simple as "user email address(es)" - accidentally using a ";" to
> separate them (users coming from outlook for
> example) would result in a completely improper behavior - trying to run
> user address as a command...
>
> Similar for something like "send this caller-id name to this external
> system command" - too many places where a
> seemingly legitimate use is really insecure.
>
> I submitted a Jira with a patch to at least add a shell quoting function,
> and another one to make use of that shell
> quoting for the email addr in switch_simple_email. I'm sure there are
> others, but I wanted to cover a couple obvious cases.
>
> Would need more work to be fully useful though...
>
> -- Nathan
>
> On 05/19/2013 02:50 PM, Cal Leeming [Simplicity Media Ltd] wrote:
> > This could really use some input from Tony, as it really comes down to a
> design decision.
> >
> > It could be argued that you should not be exposing raw configuration to
> your customers without sanitizing the input
> > yourselves.. and it could be argued that the input should be sanitized
> anyway.
> >
> > FS isn't attempting to push security through obscurity (given that all
> the code is open source), but many closed source
> > products do.
> >
> > Either way, it would be good to hear Tony's thoughts on this.
> >
> > Cal
> >
> > On Sun, May 19, 2013 at 8:21 PM, Daniel Ivanov <sertys at gmail.com<mailto:
> sertys at gmail.com>> wrote:
> >
> >     I am glad to see someone is concerned about input validation when it
> comes to voip. It is much neglected when we're
> >     constructing our services, partly due to the fact that it's still
> considered black magic. I believe that system and
> >     bgsystem should be strictly regulated and  ani and sip vars should
> be safe-parsed before feeding to a turing
> >     machine. Security through obscurity has never worked and i beth my
> both legs we all have a few vulnerable
> >     applications behind our backs. Let's unite to make FS the most
> stable and secure softswitch out there.
> >
> >     On May 19, 2013 5:21 PM, "Nathan Neulinger" <nneul at mst.edu <mailto:
> nneul at mst.edu>> wrote:
> >
> >         I've noticed several places in FS code and examples where it
> isn't safe at all to take user supplied data.
> >
> >         An easy example is the use of mailer_app:
> >
> >
> >         #ifdef WIN32
> >               switch_snprintf(buf, B64BUFFLEN, "\"\"%s\" -f %s %s %s <
> \"%s\"\"", runtime.mailer_app, from,
> >         runtime.mailer_app_args, to, filename);
> >         #else
> >               switch_snprintf(buf, B64BUFFLEN, "/bin/cat %s | %s -f %s
> %s %s", filename, runtime.mailer_app, from,
> >         runtime.mailer_app_args, to);
> >         #endif
> >
> >         another is ANY use of passing channel vars or data to a system
> or bgsystem command.
> >
> >
> >         This isn't an issue normally, but if you want to give limited
> ability for users to control their own dial rules,
> >         then
> >         you wind up having to be very careful with processing the data
> to make sure it's safe. That's always a good
> >         idea, but it
> >         still seems like a bad idea to take that data and then directly
> use it in a completely unsafe context like a parsed
> >         command line.
> >
> >         For the voicemail notify case, seems like an easy answer would
> be something like a "vm-notify-hook", which at that
> >         point, could call out to lua or perl to do the actual sending in
> a safe manner, passing the recipient/sender/etc. as
> >         data instead of on cmd line.
> >
> >         For the 'passing channel vars...' case, I think it would be good
> to have a 'system_json' and 'bgsystem_json' set of
> >         routines that would pass channel data to the script on stdin in
> json format.
> >
> >         Regardless of implementation of either of those, I think it
> would be worthwhile to have a shell_escape() routine
> >         in the
> >         core utilities to allow the current syntax to be used more
> safely.
> >
> >         -- Nathan
> >
> >         ------------------------------------------------------------
> >         Nathan Neulinger nneul at mst.edu <mailto:nneul at mst.edu>
> >         Missouri S&T Information Technology (573) 612-1412<tel:%28573%29%20612-1412>
> >         System Administrator - Architect
> >
> >
> _________________________________________________________________________
> >         Professional FreeSWITCH Consulting Services:
> >         consulting at freeswitch.org <mailto:consulting at freeswitch.org>
> >         http://www.freeswitchsolutions.com
> >
> >         
> >         
> >
> >         Official FreeSWITCH Sites
> >         http://www.freeswitch.org
> >         http://wiki.freeswitch.org
> >         http://www.cluecon.com
> >
> >         FreeSWITCH-users mailing list
> >         FreeSWITCH-users at lists.freeswitch.org <mailto:
> FreeSWITCH-users at lists.freeswitch.org>
> >         http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >         UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >         http://www.freeswitch.org
> >
> >
> >
> _________________________________________________________________________
> >     Professional FreeSWITCH Consulting Services:
> >     consulting at freeswitch.org <mailto:consulting at freeswitch.org>
> >     http://www.freeswitchsolutions.com
> >
> >     
> >     
> >
> >     Official FreeSWITCH Sites
> >     http://www.freeswitch.org
> >     http://wiki.freeswitch.org
> >     http://www.cluecon.com
> >
> >     FreeSWITCH-users mailing list
> >     FreeSWITCH-users at lists.freeswitch.org <mailto:
> FreeSWITCH-users at lists.freeswitch.org>
> >     http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >     UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >     http://www.freeswitch.org
> >
> >
>
> --
> ------------------------------------------------------------
> Nathan Neulinger                       nneul at mst.edu
> Missouri S&T Information Technology    (573) 612-1412
> System Administrator - Architect
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130520/487d198b/attachment-0001.html