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

[Nathan Neulinger]

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