Security implication of `COMPILE_R7RS`
shirok opened this issue · comments
A concern is raised regarding srfi-138's compile-r7rs redirecting execution to the value of the environment variable COMPILE_R7RS. If the variable is accidentally set, or covertly set with some malicious scripts, a user may execute other programs unintentionally.
In general, if the attacker can set an environment variable, you're already owned. However, the variable does allow obfuscated attack vector against naive users, so at least some means of raising awareness is a good thing.
Another potential trouble is that the user sets the variable for experimenting and then forget about it, and wonders why compile-r7rs doesn't run the installed one. We can print a message to let them know. After all, COMPILE_R7RS redirection should be considered as a temporary measure, for there are better ways to switch implementations.
At least, it is a bad idea to call programs from environment variables if we're running suid-ed cde. There are other instances, such as PAGER or EDITOR, too.
One way is to mark strings provided from outside as "tained", and prohibit their use in certain places. But that wouldn't be a small change.
When COMPILE_R7RS is defined, we issue message that we don't support that feature, and run our compiler. Originally we supported it only because of SRFI-138, but it is awkward, for there are multiple common ways to switch alternative implementations. Supporting irregular ways to redirect execution is more of a source of confusion rather than convenience.
I guess this one has settled.