Walter Bright wrote:
Daniel Keep wrote:
It should be noted that this is really no different to executing
arbitrary code on a machine. That said, compiling a program is not
typically thought of as "executing" code, so some restrictions in this
case would probably be prudent.
Here's the scenario I'm concerned about. Let's say you set up a website
that instead of supporting javascript, supports D used as a scripting
language. The site thus must run the D compiler on the source code. When
it executes the resulting code, that execution presumably will run in a
"sandbox" at a low privilege level.
But the compiler itself will be part of the server software, and may run
at a higher privilege. The import feature could possible read any file
in the system, inserting it into the executable being built. The running
executable could then supply this information to the attacker, even
though it is sandboxed.
This is why even using the import file feature must be explicitly
enabled by a compiler switch, and which directories it can read must
also be explicitly set with a compiler switch. Presumably, it's a lot
easier for the server software to control the compiler switches than to
parse the D code looking for obfuscated file imports.
As almost everybody else here, I've maintained a couple of websites.
Using D to write CGI programs (that are compiled, real binaries) is
appealing, but I'd never even think about having the web server itself
use the D compiler!!!
I mean, how often do you see web sites where stuff is fed to a C
compiler and the resulting programs run????? (Yes it's too slow, but
that's hardly the point here.) That is simply not done.
Rdmd might get one thinking of such, but then, how many websites use
dynamically created PHP? Dynamically created pages yes, but with static
PHP source.
I must be missing something big here...
