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

Nathan Neulinger nneul at mst.edu
Mon May 20 05:36:10 MSD 2013


I'm not giving users direct access to the system/APIs/etc - it's just via a portal/UI - but there's a difference between 
"worry about user screwing up their dialplan from me missing something if I let them define an email address" vs "give 
user full unrestricted access cause the use of email address in the core doesn't even quote command line arguments".

In both cases, I still need to be concerned with sanitizing input - more a matter of what the defense-in-depth looks like.

Right now - if I _want_ to allow untrusted input in certain circumstances - such as passing caller id info to an 
external executable, there simply is no way to do it safely. That's what the patches are for.

-- Nathan

On 05/19/2013 04:06 PM, Avi Marcus wrote:
> 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 <mailto: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>
>     <mailto: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> <mailto: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> <mailto:nneul at mst.edu <mailto:nneul at mst.edu>>
>      >         Missouri S&T Information Technology (573) 612-1412 <tel:%28573%29%20612-1412> <tel:%28573%29%20612-1412>
>      >         System Administrator - Architect
>      >
>      >         _________________________________________________________________________
>      >         Professional FreeSWITCH Consulting Services:
>      > consulting at freeswitch.org <mailto:consulting at freeswitch.org> <mailto: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>
>     <mailto: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> <mailto: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>
>     <mailto: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 <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
>
>

-- 
------------------------------------------------------------
Nathan Neulinger                       nneul at mst.edu
Missouri S&T Information Technology    (573) 612-1412
System Administrator - Architect



Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list