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@mst.edu <mailto:nneul@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@gmail.com <mailto:sertys@gmail.com> <mailto:sertys@gmail.com <mailto:sertys@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@mst.edu <mailto:nneul@mst.edu> <mailto:nneul@mst.edu <mailto:nneul@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@mst.edu <mailto:nneul@mst.edu> <mailto:nneul@mst.edu <mailto:nneul@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@freeswitch.org <mailto:consulting@freeswitch.org> <mailto:consulting@freeswitch.org <mailto:consulting@freeswitch.org>> > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> <mailto:FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@freeswitch.org <mailto:consulting@freeswitch.org> <mailto:consulting@freeswitch.org <mailto:consulting@freeswitch.org>> > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> <mailto:FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@mst.edu <mailto:nneul@mst.edu> Missouri S&T Information Technology (573) 612-1412 <tel:%28573%29%20612-1412> System Administrator - Architect
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect