<br><br><div><span class="gmail_quote">On 6/26/06, <b class="gmail_sendername">Peter Watkins</b> <<a href="mailto:peterw@tux.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">peterw@tux.org</a>
> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jerry Bett wrote:<br>> This may be more of a bash question than a myth question ... if so,<br>> forgive me.<br>><br>> I have a user job that encodes shows for my Palm TX ... run as :<br>><br>> palmencode $FILE% "$TITLE%" "%SUBTITLE%"
<br>><br>> 'palmencode' is a bash script inputing the command line as $1, $2 and $3<br><br>> How can one get the full title with spaces and other special characters ?<br><br>Eek. When you find a decent fix for this, update
<br> <a href="http://www.mythtv.org/wiki/index.php/User_Jobs" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.mythtv.org/wiki/index.php/User_Jobs</a><br><br>This looks like a likely security problem; what happens if someone at
<br>the organization providing your listings decides to publish a subtitle like
<br> x;#";#';touch /tmp/coulda-done-anything<br>Would Myth then cause "touch /tmp/coulda-done-anything" to run? Does<br>Myth have anything like Wietse Venema's safe_finger character scrubber?<br><br>I think the best approach with the current features would be to only
<br>pass a variable that should only have safe chars like %FILE% to some<br>wrapper script. The wrapper script would get the other details from<br>MySQL, and would scrub each variable extracted from MySQL before calling<br>
palmencode. It's technically possible to safely call palmencode with<br>arbitrary data, e.g. in Perl, you can pass multiple args to an app with<br>system() by passing multiple arguments to system() like<br>system("/path/to/palmencode",$file,$title,$subtitle) should lead to
<br>palmencode properly reading the input -- but I would not assume that<br>palmencode and the apps it calls can handle arbitrary strings. All too<br>often, Unix/Linux scripts and apps expect to be passed "safe" args.
<br><br>Another approach would be to make a wrapper script and call it with a<br>user job like<br> palmencode_wrapper FILE____%FILE% TITLE____%TITLE% SUBTITLE____<br>Have palmencode_wrapper build a single string out of all the arguments,
<br>use the odd ____ prefixes to extract the variables, change whitespace to<br>something like "_", scrub them of any characters not known to be OK<br>(regexp [^0-9a-zA-Z\.\_\-] ?), and then pass those sanitized args to
<br>palmencode. This approach should work for most innocent title/subtitle<br>values, but it sounds like Myth is letting some shell expansion take<br>place, so this wouldn't be a bulletproof workaround.<br><br>I don't think you should have to go to that trouble though. IMO, Myth
<br>should use a "positive"/"white list" filter (allow known good; discard<br>other) for those variables (and document the whitelist, so users know<br>whether to expect whitespace, for instance). If it doesn't, and my
<br>'touch' suggestion really would make that test file, then it's a<br>security flaw.<br><br>Myth shouldn't bother trying to escape chars with "/", etc. Any app that<br>really needs the raw strings should check with the database.
<br><br>-Peter<br><br><br><br><br><br></blockquote></div>Peter,<br><br>Looks like the problem was self-induced.<br><br>I added additional logging to my script, specifically "echo $@ >> $LOG" and<br>did not see any quotes around the TITLE/SUBTITLE values.
<br><br>Checking mythtv-setup again I found the quotes missing ...instead of "$TITLE" i<br>only had $TITLE. I know I added them ... no idea why they were missing.<br><br>Anyway ... looks like it's working now.<br>
<br>As far as security, the $TITLE & $SUBTITLE is used as the filename of the new<br>palm file, ie $OUTFILE=$TITLE"-"$SUBTITLE".avi" .<br><br>The final command for the script is cp TEMPFILE $OUTFILE . I'm curious as
<br>to whether a malicious $TITLE could be used and will check it out.<br><br>Thanks for the info !<br>