I'm on shared hosting services. Till some time back I had shell access to execute the mimetex. However, recently I was told that it posses security problem to the hosting server and the shell access was discontinued. The following are the comments form my linux hosting administrator:
" Using the Tex Mod the User/Visitor, can excute Shell commands, not only JailShell commands. Using PhpSuExec it can grant root privileges, and this is a Big securitty problem"
I would like to know about the seriousness involved in this isssue and is there a way out of this.
venkatesan Iyengar
Security Issues raised in mimetex
Number of replies: 11Re: Security Issues raised in mimetex
The problem isn't with mimetex, per se, but with the way the moodle filter uses mimetex. Zig originally programmed the filter to escape to a shell, and then run mimetex from that shell. It's that shell which is the security issue. And you don't really need to run mimetex that way, so the shell's not necessary to begin with.
I believe Zig used the shell so he could issue further commands to cache mimetex images. But mimetex has its own caching mechanism, activated by compiling it with the -DCACHEPATH=\"path-to-images\" switch, see http://www.forkosh.com/mimetexmanual.html?options
Then, the php code needed to embed mimetex images in moodle pages should just be something like the very simple one-line fix
$text = preg_replace('/\[tex\](.*?)\[\/tex\]/ie',
"'
'",
$text);
(I can't get the above to display correctly. Please see the Introduction section of http://www.forkosh.com/mimetex.html for the one-line fix)
However, I don't see where in moodle to put a fix like that just by looking at the code for the tex filter. I've suggested this fix before, but nobody who knows moodle internals seemed interested in doing it. If that remains the case, you might want to try the jsmath filter, which resides on the client rather than the server. That ought to remove the security problem. The only downside is that everybody who wants to look at your moodle pages has to individually install jsmath on their own pc.
I believe Zig used the shell so he could issue further commands to cache mimetex images. But mimetex has its own caching mechanism, activated by compiling it with the -DCACHEPATH=\"path-to-images\" switch, see http://www.forkosh.com/mimetexmanual.html?options
Then, the php code needed to embed mimetex images in moodle pages should just be something like the very simple one-line fix
$text = preg_replace('/\[tex\](.*?)\[\/tex\]/ie',
"'
$text);
(I can't get the above to display correctly. Please see the Introduction section of http://www.forkosh.com/mimetex.html for the one-line fix)
However, I don't see where in moodle to put a fix like that just by looking at the code for the tex filter. I've suggested this fix before, but nobody who knows moodle internals seemed interested in doing it. If that remains the case, you might want to try the jsmath filter, which resides on the client rather than the server. That ought to remove the security problem. The only downside is that everybody who wants to look at your moodle pages has to individually install jsmath on their own pc.
Re: Security Issues raised in mimetex
Thanks John,
I understand from your reply that shell permission is not required to run mimetex. This would be a great releif to many of the hosted customers. I understand that DCACHEPATH should refer to the course id of the moodle. Since I'm not a php expert let me take help from my friends to look in to this matter. I think moodle community can take up this issue and come up with some solution. However, meanwhile I've started using jsmath even though it is slow most of the time.
I understand from your reply that shell permission is not required to run mimetex. This would be a great releif to many of the hosted customers. I understand that DCACHEPATH should refer to the course id of the moodle. Since I'm not a php expert let me take help from my friends to look in to this matter. I think moodle community can take up this issue and come up with some solution. However, meanwhile I've started using jsmath even though it is slow most of the time.
Re: Security Issues raised in mimetex
Right, shell permission is not required to run mimetex. The usual way to run mimetex is within the src= part of an html img tag. For example (where I'll write uppercase IMG instead of lowercase img so you can see it),
<IMG src="http://www.forkosh.com/mimetex.cgi?\sqrt{x^2+y^2}">
renders the image
when I replace IMG with img. No shell permission is required to process an img tag. Unfortunately, the moodle tex filter uses a roundabout procedure to generate mimetex images, and that procedure uses a shell. A more direct procedure, like illustrated above, doesn't use a shell at all.
-DCACHEPATH=\"path-to-mimetex-images\" doesn't refer to moodle course id. It's just a directory where you want mimetex to cache its images. If mimetex.cgi is in directory cgi-bin/ then -DCACHEPATH=\"images\" will cache mimetex images in directory cgi-bin/images/
Regarding Davide's remark (hi, Davide), thanks for the correction, and I'm happy to hear jsmath doesn't have to be installed on every client. That indeed makes it much more convenient.
<IMG src="http://www.forkosh.com/mimetex.cgi?\sqrt{x^2+y^2}">
renders the image
when I replace IMG with img. No shell permission is required to process an img tag. Unfortunately, the moodle tex filter uses a roundabout procedure to generate mimetex images, and that procedure uses a shell. A more direct procedure, like illustrated above, doesn't use a shell at all.
-DCACHEPATH=\"path-to-mimetex-images\" doesn't refer to moodle course id. It's just a directory where you want mimetex to cache its images. If mimetex.cgi is in directory cgi-bin/ then -DCACHEPATH=\"images\" will cache mimetex images in directory cgi-bin/images/
Regarding Davide's remark (hi, Davide), thanks for the correction, and I'm happy to hear jsmath doesn't have to be installed on every client. That indeed makes it much more convenient.
Re: Security Issues raised in mimetex
Thanks,
Is it not cumbersome to define img tag everytime i write an equation (think about teaching quantum mechanics). I think better way is to simply write equations within double dollar tags or /[...]/ and allow the filter to automatically insert img tags and render the image by calling mimetex.cgi from cgi-bin folder.
Is it not cumbersome to define img tag everytime i write an equation (think about teaching quantum mechanics). I think better way is to simply write equations within double dollar tags or /[...]/ and allow the filter to automatically insert img tags and render the image by calling mimetex.cgi from cgi-bin folder.
Re: Security Issues raised in mimetex
Yes, that would indeed be cumbersome. Fortunately, it's not necessary. And it sounds like maybe you already saw the Introduction section of http://www.forkosh.com/mimetex.html that I suggested above, since it uses exactly the same word "cumbersome" to describe <img> tags: "There's also no inherent need to repeatedly write the cumbersome <img> tag illustrated above."
Did you read that and maybe not understand the subsequent discussion? The "one-line fix" which I also mentioned above is one way to avoid using cumbersome <img> tags. And that way doesn't involve escaping to a shell, which is what caused your original security problem.
It's important to _understand_ the underlying <img> mechanism in order to see that mimetex poses no inherent security risk. But you don't want to _use_ <img> tags for every mathematical expression you write. There are _many_ ways to avoid using <img> tags. Zig chose a way that escapes to a shell, causing your security problem. I illustrated another way that doesn't cause any problem.
Did you read that and maybe not understand the subsequent discussion? The "one-line fix" which I also mentioned above is one way to avoid using cumbersome <img> tags. And that way doesn't involve escaping to a shell, which is what caused your original security problem.
It's important to _understand_ the underlying <img> mechanism in order to see that mimetex poses no inherent security risk. But you don't want to _use_ <img> tags for every mathematical expression you write. There are _many_ ways to avoid using <img> tags. Zig chose a way that escapes to a shell, causing your security problem. I illustrated another way that doesn't cause any problem.
Re: Security Issues raised in mimetex
Unfortunately we can't use CGI because Moodle is PHP and systems vary widely, so running mimetext via a system call is the best way for us.
However, I believe the way we've done it is very secure and represents no risk. A lot of bright people have examined it for exactly this reason over an extended period.
The problem here is largely social, in that any use of system commands will freak out some system adminstrators (usually with good reason since there is a lot of not-well-thought-through code around).
However, I believe the way we've done it is very secure and represents no risk. A lot of bright people have examined it for exactly this reason over an extended period.
The problem here is largely social, in that any use of system commands will freak out some system adminstrators (usually with good reason since there is a lot of not-well-thought-through code around).
Re: Security Issues raised in mimetex
John and Martin - Thanks for the reassurance that it is secure and has been well thought through. I appreciate and trust your experience and expertise.
Re: Security Issues raised in mimetex
Thanks John. As you suggested I created a new filter, called mimetex to convert [tex] taged expressions using mimetex.cgi residing in cgi-bin folder. I just modified my earlier marvin filter to construct this. The following are the codes:
<?php // $id$
function mimetex_filter($courseid, $text) {
global $CFG, $PHP_SELF, $filter_mimetex_has_initialized;
$u = $CFG->wwwroot;
if(preg_match('|https?://.*?/|', $u)){
$relurl = preg_replace('|https?://.*?/|', '', $u);
}else{
$relurl = ''; // This will typically be the case if Moodle is the web root
}
$numdirs = substr_count($PHP_SELF, '/') - 1;
if($numdirs==0){
$relurl = './' . $relurl;
}else{
$relurl = str_repeat('../', $numdirs) . $relurl;
}
$search = '/\[tex\](.*?)\[\/tex\]/ie';
$replace = "'<img src="/../cgi-bin/mimetex.cgi?'.rawurlencode('$1').'" />'";
$newtext = preg_replace($search, $replace, $text);
return $newtext;
}
?>
This created the required image. However, I have the following problem to be addressed:
How to verify whether the images is cached in the -DCACHEPATH how to recall the image back?
<?php // $id$
function mimetex_filter($courseid, $text) {
global $CFG, $PHP_SELF, $filter_mimetex_has_initialized;
$u = $CFG->wwwroot;
if(preg_match('|https?://.*?/|', $u)){
$relurl = preg_replace('|https?://.*?/|', '', $u);
}else{
$relurl = ''; // This will typically be the case if Moodle is the web root
}
$numdirs = substr_count($PHP_SELF, '/') - 1;
if($numdirs==0){
$relurl = './' . $relurl;
}else{
$relurl = str_repeat('../', $numdirs) . $relurl;
}
$search = '/\[tex\](.*?)\[\/tex\]/ie';
$replace = "'<img src="/../cgi-bin/mimetex.cgi?'.rawurlencode('$1').'" />'";
$newtext = preg_replace($search, $replace, $text);
return $newtext;
}
?>
This created the required image. However, I have the following problem to be addressed:
How to verify whether the images is cached in the -DCACHEPATH how to recall the image back?
Re: Security Issues raised in mimetex
Hi Venkatesan,
Thanks for writing that (my emailed version seems to display what you actually wrote). It looks exactly like what I'd thought of as the "correct"/straightforward mimetex plugin script. You might want to add an align=\"middle\" to your <img> tag. That's typically the more aesthetic-looking image alignment relative to surrounding text.
To verify that images are cached in -DCACHEPATH=\"path-to-images/\" just dir (windows) or ls (unix or linux) path-to-images/ from the command line, and see what's there. One thing that should be there is the ascii file mimetex.log, which you can read with any file editor to see the names and contents of all the gif files cached in your path-to-images/ directory.
Please note that you have to mkdir path-to-images/ (relative to the cgi-bin/ directory where mimetex.cgi resides) yourself, before running mimetex. If the directory specified by -DCACHEPATH=\"path-to-images/\" doesn't already exist when mimetex runs, then it just generates requested images without caching them. So be sure to mkdir path-to-images/ corresponding to -DCACHEPATH=\"path-to-images/\"
To "recall" cached images, just run mimetex in the usual way. When it's compiled with -DCACHEPATH=\"path-to-images/\" then it automatically checks path-to-images/ for an already-cached image of your requested expression. You don't have to do anything different than usual. If mimetex finds a cached image, it just uses that image without re-rendering it. Otherwise, it renders new images and caches them for future use.
You might think mimetex is an awfully big program to run just to retrieve cached images. But think how paged memory management typically works on all modern os's. Only the very few pages of memory required for mimetex's caching code will actually be loaded, not the whole program (and none of the font data).
Thanks for writing that (my emailed version seems to display what you actually wrote). It looks exactly like what I'd thought of as the "correct"/straightforward mimetex plugin script. You might want to add an align=\"middle\" to your <img> tag. That's typically the more aesthetic-looking image alignment relative to surrounding text.
To verify that images are cached in -DCACHEPATH=\"path-to-images/\" just dir (windows) or ls (unix or linux) path-to-images/ from the command line, and see what's there. One thing that should be there is the ascii file mimetex.log, which you can read with any file editor to see the names and contents of all the gif files cached in your path-to-images/ directory.
Please note that you have to mkdir path-to-images/ (relative to the cgi-bin/ directory where mimetex.cgi resides) yourself, before running mimetex. If the directory specified by -DCACHEPATH=\"path-to-images/\" doesn't already exist when mimetex runs, then it just generates requested images without caching them. So be sure to mkdir path-to-images/ corresponding to -DCACHEPATH=\"path-to-images/\"
To "recall" cached images, just run mimetex in the usual way. When it's compiled with -DCACHEPATH=\"path-to-images/\" then it automatically checks path-to-images/ for an already-cached image of your requested expression. You don't have to do anything different than usual. If mimetex finds a cached image, it just uses that image without re-rendering it. Otherwise, it renders new images and caches them for future use.
You might think mimetex is an awfully big program to run just to retrieve cached images. But think how paged memory management typically works on all modern os's. Only the very few pages of memory required for mimetex's caching code will actually be loaded, not the whole program (and none of the font data).
Re: Security Issues raised in mimetex
This sounds like something that may best be implemented by security.moodle.org so that any real risk here might be explored and patched for all users. Peace.
Re: Security Issues raised in mimetex
I just wanted to make a small correction to John's comment about the jsMath filter. The users do not need to install jsMath on their own machines. It is only installed on the server. JsMath will work faster if they install certain fonts on the user's machines, but jsMath will work correctly without that.
Davide
Davide