www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allowing relative file imports

reply Daniel Keep <daniel.keep.lists gmail.com> writes:
There seem to have been a few tickets thus far from people wanting to do
relative file imports using the -J switch.  Walter has stated that this
is explicitly disallowed as a defensive measure, which is fine.

I was going to post the following as an enhancement request, but I
thought it might be better if it was discussed first.

TLDR: relative paths should be safe if we disallow symlinks, disallow -J
to be used except for a small whitelist and require a specially-named
file to be present in any imported directory.

Disclaimer: I'm not a security guru.

  -- Daniel

There have been at least two reports thus far (2103 and 2759) of people
attempting to use relative imports with the -J compile-time file import
feature.

It has been stated that this is explicitly disabled due to security
concerns.

I suggest that adding relative paths (provided paths cannot escape the
base directory) is not less secure; it should already be possible to
read an arbitrary file using the feature.

Let us assume relative paths are allowed, and that the path is
"collapsed" to remove all parent (..) references, and clipped to the
base directory.  The only way to "escape" this directory is for one of
three things to happen:

1. there is a symlink to a parent directory in the import path,
2. there is a device of interest mounted in the import path or
3. the user was tricked into specifying a higher directory in the first
place.


Makefile to read any system configuration file that the user has access

tremendously stupid, which is not so much an issue with DMD but with the


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.

Therefore, I believe the following should be sufficient to ensure
relative paths are safe to include:

1. Ensure that symlinks are NOT followed.  This also applies under
Windows for junctions and symlinks (I believe it should be enough to use
GetFileAttributesEx on each path component and reject it if it has the
FILE_ATTRIBUTE_REPARSE_POINT attribute, although I cannot verify this
with XP; see
http://blogs.msdn.com/oldnewthing/archive/2004/12/27/332704.aspx).

2. Disallow -J to be the root of any drive or filesystem, and only allow
-J to be used from the following roots: %USERPROFILE% for Windows and ~
for *nix.  Possibly, this should be configured or overridable in sc.ini;
an extendible whitelist would be good.

3. Require that any directory you attempt to read from using file
imports MUST have either a "_import" or ".import" file (or whatever name
seems appropriate) present in it.

The first should prevent symlinks from being a potential attack vector,
the second should prevent most casual malicious behaviour, and the third
will ensure that the user not only have read access but WRITE access as
well (or whoever owns the directory explicitly allowed for D file imports.)

This should hopefully be sufficient to allow for relative imports.
Mar 25 2009
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Daniel Keep schrieb:

 There have been at least two reports thus far (2103 and 2759) of people
 attempting to use relative imports with the -J compile-time file import
 feature.


Please note also my posting "Proposal for fixing import("file")" on 14th
March in this NG.
Mar 25 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit wrote:

 Daniel Keep schrieb:

 There have been at least two reports thus far (2103 and 2759) of people
 attempting to use relative imports with the -J compile-time file import
 feature.


 
 Please note also my posting "Proposal for fixing import("file")" on 14th
 March in this NG.


Should go into bugzilla with a link to that thread.
Mar 25 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Mar 25, 2009 at 8:28 AM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:


 2. Disallow -J to be the root of any drive or filesystem, and only allow
 -J to be used from the following roots: %USERPROFILE% for Windows and ~
 for *nix. =A0Possibly, this should be configured or overridable in sc.ini=


;

 an extendible whitelist would be good.


%USERPROFILE% is probably a bad choice on Windows pre-Vista, mostly
because OPTLINK will die with paths with spaces in them (go OPTLINK).
That and, I have never used my %USERPROFILE% directory for anything :P
(probably because it's such a long god-damned path!)
Mar 25 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Jarrett Billingsley wrote:

 On Wed, Mar 25, 2009 at 8:28 AM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:
 

 2. Disallow -J to be the root of any drive or filesystem, and only allow
 -J to be used from the following roots: %USERPROFILE% for Windows and ~
 for *nix.  Possibly, this should be configured or overridable in sc.ini;
 an extendible whitelist would be good.


 
 %USERPROFILE% is probably a bad choice on Windows pre-Vista, mostly
 because OPTLINK will die with paths with spaces in them (go OPTLINK).
 That and, I have never used my %USERPROFILE% directory for anything :P
 (probably because it's such a long god-damned path!)


True, but what else is there?  That's where "My Documents" lives;
there's no other "safe" directory I could think of for Windows.

If the error message including the language "You may need to add this
directory, or a parent of it, to the whitelist in %PATHTODMD%\sc.ini" it
should be OK.

The point here is to allow it safely.

  -- Daniel
Mar 25 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 25 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Mar 25, 2009 at 2:18 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 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.


One, you do not use Javascript as a server-side scripting language.
That task is usually relegated to (shiver) PHP, Ruby, Python, Java or
the like.  Javascript, as far as I know, only has a place in web
programming in client-side (browser-side) scripting.  The only thing
you can do from the client is maybe munge some POST data, and then
that's a logic error on the part of your server script, not anything
to do with the language.

Two, if you did replace your server-side scripting language with
something like D, there are no more or fewer security holes than with
any other server-side scripting language.  The entire point of
server-side scripts is that they are invisible to the clients, and the
clients never see, modify, or upload server-side scripts of their own.
 It's not possible to put a malicious file import in the D server page
unless you actually have access to the server, and if an attacker does
have that kind of access, D is no more or less secure than any other
server-side language.  They'd all be vulnerable.  The attacker could
just change the server's compiler flags to change the import directory
anyway.

I understand your desire to restrict the use of import expressions,
but your example just does not add up.
Mar 25 2009
parent Miles <_______ _______.____> writes:
Jarrett Billingsley wrote:

 One, you do not use Javascript as a server-side scripting language.


Why not? Server-side JavaScript exists since 1996.

http://www.aptana.com/jaxer/
http://www.modjs.org/
Mar 27 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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.


If you're thinking of something like ASP.NET for D, whereby the server
executes a D compiler, then I think this would be a serious design flaw
of the software; the D compiler itself should be executing with the
absolute minimum permissions necessary to function, and preferably in a
VM or a jail.


 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.


Well, my proposal should -improve- security because currently it's
possible to read any file the compiler has access to simply by compiling
via a Makefile or any other build process.

If the code cannot set command-line switches, then there's no
difference, so let's ignore that case.  Let's assume the code CAN set
switches.  There's nothing to stop it doing this:


 dmd -J/etc evil.d && evil



 module evil;
 const PASSWD = cast(char[]) import("passwd");
 import std.stdio;
 void main()
 {
     writefln("200 OK\nContent-Type: text/plain\n");
     writef("%s", PASSWD);
 }


Hence why I proposed a whitelist in sc.ini itself.  This way, you can't
trick the compiler (either by controlling the command-line or by
tricking the user) into giving you the sensitive file directly.

By disallowing symlinks, you also remove the ability to "escape" a
directory tree.

Finally, the requirement for a ".dimport" or "_dimport" file or
something ensures that folders have to explicitly cleared for file
imports.  Combined with the whitelist and removal of symlinks, it should
be more or less impossible to get access to a file you shouldn't.

Perhaps it might be worthwhile to do a mock compiler (that just attempts
to read a provided filename using a -J switch) with these semantics and
see if it's possible to exploit it in any way...

  -- Daniel
Mar 25 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:

 If the code cannot set command-line switches, then there's no
 difference, so let's ignore that case.  Let's assume the code CAN set
 switches.  There's nothing to stop it doing this:


It's a lot easier to scrub command line switches than to try to scrub D 
source code. It's the server that runs dmd, not the client.

The rest of your proposal may be tight, I don't really know. I do wish 
to keep it, however, as simple as possible and the current scheme does that.
Mar 25 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 Daniel Keep wrote:

 If the code cannot set command-line switches, then there's no
 difference, so let's ignore that case.  Let's assume the code CAN set
 switches.  There's nothing to stop it doing this:


 
 It's a lot easier to scrub command line switches than to try to scrub D
 source code. It's the server that runs dmd, not the client.
 
 The rest of your proposal may be tight, I don't really know. I do wish
 to keep it, however, as simple as possible and the current scheme does
 that.


Sorry, poor choice of words.  I should have said "Let's assume a
malicious party who either provided the code or knows how to exploit the
code can set switches."

I'm not proposing scrubbing the source in any way.

  -- Daniel
Mar 25 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
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...
Mar 26 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 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.


Of course it is, probably just not in C. Last time I looked, there are 
two concepts around, one of "statically-generated dynamic pages" and one 
of "entirely dynamic pages". I know because I installed an Apache server 
and at that time support for statically-generated dynamic pages was new.

What that means is this:

a) statically-generated dynamic = you generate the page once, it's good 
until the source of the page changes;

b) "really" dynamic page = you generate the page at each request.


 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...


I think D with rdmd would be great for (a).


Andrei
Mar 26 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 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.


 
 Of course it is, probably just not in C. Last time I looked, there are 
 two concepts around, one of "statically-generated dynamic pages" and one 
 of "entirely dynamic pages". I know because I installed an Apache server 
 and at that time support for statically-generated dynamic pages was new.
 
 What that means is this:
 
 a) statically-generated dynamic = you generate the page once, it's good 
 until the source of the page changes;
 
 b) "really" dynamic page = you generate the page at each request.


Have you ever done web development? If so, did you actually do *code 
generation* on each page request? If so, I never want to work with you.

Web applications in compiled languages pretty much never invoke the 
compiler when they're running. Very few programs need a compiler on the 
machine they're deployed to. It's a security risk, and it's an unneeded 
dependency, and it pretty much guarantees a maintenance and debugging 
problem, and it promises performance issues.
Mar 26 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 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.


 
 Of course it is, probably just not in C. Last time I looked, there are 
 two concepts around, one of "statically-generated dynamic pages" and one 
 of "entirely dynamic pages". I know because I installed an Apache server 
 and at that time support for statically-generated dynamic pages was new.
 
 What that means is this:
 
 a) statically-generated dynamic = you generate the page once, it's good 
 until the source of the page changes;
 
 b) "really" dynamic page = you generate the page at each request.
 

 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...


 
 I think D with rdmd would be great for (a).


I'm still not sure what you mean. I see it as static (as in plain html) 
vs dynamic (as, FaceBook, Wikipedia, etc.). Now these dynamic pages can 
be php pages, that get their data from a database (I guess wikimedia 
would be a good example), but neither case involves creating the server 
side programs (as in *.php, *.cgi) dynamically.

Or sort-of. Many PHP web applications contain pages that dynamically 
choose which sub-elements (say a news ticker) to "show", but that's 
still just combinations of prewritten "mini-pages", if you will. (Some 
even have them in a RDBMS.)

But a use case where one would need to create CGI-BIN stuff that is so 
variable as to warrant recompiling, I don't see. One would rather have a 
set of small D programs (binaries) that do small things, like one for 
latest news, one for informing about others online, etc.

--------

Of course there are sites where I can type D source code in a box, and 
have it compiled and run. But I'm sure neither of us are talking about 
such sites? I mean, to do that, the administrator usually knows what 
he's doing! And can take care of himself, which means we don't have to 
accommodate his needs.
Mar 26 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:

 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.


Similarly, how often do you do code generation in a PHP application? You 
can do it, and I'm sure people use eval for small things, but anything 
bigger than that, it just becomes a mess.
Mar 26 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:

 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.


Consider the Java JVM. You've probably got one installed on your 
computer. It gets java code from gawd knows where (as the result of web 
browsing), it compiles it, and runs it on your machine unbeknownst to you.

.NET does that too.

Every day my browser downloads javascript code, compiles it, and runs it.

There's no reason in principle that D could not be used instead.

This means that we should think about security issues. Compiling 
untrusted code should not result in an attack on your system.

http://www.comeaucomputing.com lets you upload random C++ code, compile 
it on their system, and view the messages put out by their compiler. 
Suppose you did it with D, had it import some sensitive file, and put it 
out with a pragma msg statement?
Mar 26 2009
next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:

 Georg Wrede wrote:

 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.


 
 Consider the Java JVM. You've probably got one installed on your 
 computer. It gets java code from gawd knows where (as the result of web 
 browsing), it compiles it, and runs it on your machine unbeknownst to you.
 
 .NET does that too.
 
 Every day my browser downloads javascript code, compiles it, and runs it.
 
 There's no reason in principle that D could not be used instead.
 
 This means that we should think about security issues. Compiling 
 untrusted code should not result in an attack on your system.
 
 http://www.comeaucomputing.com lets you upload random C++ code, compile 
 it on their system, and view the messages put out by their compiler. 
 Suppose you did it with D, had it import some sensitive file, and put it 
 out with a pragma msg statement?


Your compiler can do the same:
http://codepad.org/hWC9hbPQ
Mar 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:

 Walter Bright wrote:

 http://www.comeaucomputing.com lets you upload random C++ code, 
 compile it on their system, and view the messages put out by their 
 compiler. Suppose you did it with D, had it import some sensitive 
 file, and put it out with a pragma msg statement?


 
 Your compiler can do the same:
 http://codepad.org/hWC9hbPQ


That's awesome!
Mar 26 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:

 grauzone wrote:

 Walter Bright wrote:

 http://www.comeaucomputing.com lets you upload random C++ code, 
 compile it on their system, and view the messages put out by their 
 compiler. Suppose you did it with D, had it import some sensitive 
 file, and put it out with a pragma msg statement?


 Your compiler can do the same:
 http://codepad.org/hWC9hbPQ


 
 That's awesome!


And the system seems protected, too: http://codepad.org/mzAgmvZZ
Mar 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 grauzone wrote:

 Walter Bright wrote:

 http://www.comeaucomputing.com lets you upload random C++ code, 
 compile it on their system, and view the messages put out by their 
 compiler. Suppose you did it with D, had it import some sensitive 
 file, and put it out with a pragma msg statement?


 Your compiler can do the same:
 http://codepad.org/hWC9hbPQ


 That's awesome!


 
 And the system seems protected, too: http://codepad.org/mzAgmvZZ


And I'll raise you: http://codepad.org/bp5nsprd
Mar 27 2009
next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:

 Georg Wrede wrote:

 Walter Bright wrote:

 grauzone wrote:

 Walter Bright wrote:

 http://www.comeaucomputing.com lets you upload random C++ code, 
 compile it on their system, and view the messages put out by their 
 compiler. Suppose you did it with D, had it import some sensitive 
 file, and put it out with a pragma msg statement?


 Your compiler can do the same:
 http://codepad.org/hWC9hbPQ


 That's awesome!


 And the system seems protected, too: http://codepad.org/mzAgmvZZ


 
 And I'll raise you: http://codepad.org/bp5nsprd


Not that I'm discussing against the import -J switch, but the compiler 
is also running inside a sandbox. At least it looks like:

http://codepad.org/ZGON3u56

(my interpretation: compiler crashes inside the sandbox)

Conclusion: the compiler doesn't need to be safe. Actually, using a 
sandbox approach is probably more secure than trying to fix all compiler 
security issues.
Mar 27 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
grauzone wrote:

 Walter Bright wrote:

 Georg Wrede wrote:

 Walter Bright wrote:

 grauzone wrote:

 Walter Bright wrote:

 http://www.comeaucomputing.com lets you upload random C++ code, 
 compile it on their system, and view the messages put out by their 
 compiler. Suppose you did it with D, had it import some sensitive 
 file, and put it out with a pragma msg statement?


 Your compiler can do the same:
 http://codepad.org/hWC9hbPQ


 That's awesome!


 And the system seems protected, too: http://codepad.org/mzAgmvZZ


 And I'll raise you: http://codepad.org/bp5nsprd


 
 Not that I'm discussing against the import -J switch, but the compiler 
 is also running inside a sandbox. At least it looks like:
 
 http://codepad.org/ZGON3u56
 
 (my interpretation: compiler crashes inside the sandbox)
 
 Conclusion: the compiler doesn't need to be safe. Actually, using a 
 sandbox approach is probably more secure than trying to fix all compiler 
 security issues.


What's really so hard about:

-J`pwd`/whatever

(at least on *nix)
Mar 27 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:

 Conclusion: the compiler doesn't need to be safe. Actually, using a 
 sandbox approach is probably more secure than trying to fix all compiler 
 security issues.


I've been reading a bunch of articles on making secure software lately. 
The consensus is that relying on one aspect to make software secure 
leaves one vulnerable. The more reliable way is to have layered security 
- so that if an attacker gets past one layer, he's got another layer he 
must get past.

Compiler security issues should be addressed, *and* the compiler should 
be run in a sandbox.

I'm also thinking of adjusting the code generation to reduce the ability 
to take advantage of buffer overflows, even though you shouldn't have 
buffer overflows in D.
Mar 27 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Mar 27, 2009 at 2:14 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 I'm also thinking of adjusting the code generation to reduce the ability to
 take advantage of buffer overflows, even though you shouldn't have buffer
 overflows in D.


At least not in debug mode.  ;)
Mar 27 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article

 On Fri, Mar 27, 2009 at 2:14 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 I'm also thinking of adjusting the code generation to reduce the ability to
 take advantage of buffer overflows, even though you shouldn't have buffer
 overflows in D.


 At least not in debug mode.  ;)


Correction: at least not in non-release mode.  That "release" flag really has to
be renamed.
Mar 27 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:

 Georg Wrede wrote:

 Walter Bright wrote:

 grauzone wrote:

 Walter Bright wrote:

 http://www.comeaucomputing.com lets you upload random C++ code, 
 compile it on their system, and view the messages put out by their 
 compiler. Suppose you did it with D, had it import some sensitive 
 file, and put it out with a pragma msg statement?


 Your compiler can do the same:
 http://codepad.org/hWC9hbPQ


 That's awesome!


 And the system seems protected, too: http://codepad.org/mzAgmvZZ


 
 And I'll raise you: http://codepad.org/bp5nsprd


Unfair! You must have a newer Phobos than I! :/
Mar 27 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:

 Georg Wrede wrote:

 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.


 
 Consider the Java JVM. You've probably got one installed on your 
 computer. It gets java code from gawd knows where (as the result of web 
 browsing), it compiles it, and runs it on your machine unbeknownst to you.


I was talking server side. But now that you mention, it would be kind of 
cool to have D within the browser.


 .NET does that too.
 
 Every day my browser downloads javascript code, compiles it, and runs it.
 
 There's no reason in principle that D could not be used instead.


True. But then, what would happen to the Systems Language image of D in 
folks' minds, if it is run in a browser, next to Javascript, Java, and 
who knows what "toy" languages? Would Phobos then have to be replaced 
with another library for running the app within a browser?


 This means that we should think about security issues. Compiling 
 untrusted code should not result in an attack on your system.


Well, removing disk file ops, and OS APIs in general would be the first 
step. And if you restrict some include paths, then, for symmetry, you 
should restrict all command line file paths similarly. I think there's a 
lot to do here. A half baked version would just give bad PR, but a 
proper and tight version presumably is quite some work -- but is the 
reward worth it? Is it established that enough people would use it?

Are you thinking of having a parallell Phobos tree for this, or doing it 
with conditional compilation?


 http://www.comeaucomputing.com lets you upload random C++ code, compile 
 it on their system, and view the messages put out by their compiler. 
 Suppose you did it with D, had it import some sensitive file, and put it 
 out with a pragma msg statement?


Well, even they don't let you run the compiled programs. (But that's 
probably mostly because kids would waste all the cpu cycles.) And I'd 
bet the compiler is chrooted, just to be safe. Chrooting would take care 
of that D pragma "exploit", too.

Ahhh, about links: it's the responsibility of the operator to see that 
there are no unnecessary links within the chroot tree. But some 
installations need (and others want, for specific reasons) to have soft 
links, so I don't think the compiler should frawn upon them. It's really 
not the compiler's responsibility. Similarly, there may be hard links, 
and while even they can be "detected", it's really not called for. (One 
could call this Compartmentalization of Responsibility, unheard of in 
Windows.)

---

But really, what I'm wondering here is, is this yet another "hey let's 
do this" thing?? Can we go on like this till September? And where would 
we be then? Shouldn't there be like a roadmap, or something? Or priorities?
Mar 27 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 There's no reason in principle that D could not be used instead.


 
 True. But then, what would happen to the Systems Language image of D in 
 folks' minds, if it is run in a browser, next to Javascript, Java, and 
 who knows what "toy" languages? Would Phobos then have to be replaced 
 with another library for running the app within a browser?


One would use the "safe" subset of D for that.


 This means that we should think about security issues. Compiling 
 untrusted code should not result in an attack on your system.


 
 Well, removing disk file ops, and OS APIs in general would be the first 
 step. And if you restrict some include paths, then, for symmetry, you 
 should restrict all command line file paths similarly. I think there's a 
 lot to do here. A half baked version would just give bad PR, but a 
 proper and tight version presumably is quite some work -- but is the 
 reward worth it? Is it established that enough people would use it?
 
 Are you thinking of having a parallell Phobos tree for this, or doing it 
 with conditional compilation?


I haven't thought that far.



 But really, what I'm wondering here is, is this yet another "hey let's 
 do this" thing?? Can we go on like this till September? And where would 
 we be then? Shouldn't there be like a roadmap, or something? Or priorities?


The import file thing has been around a long time. I am not planning on 
changing it in the near future.
Mar 27 2009
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
Walter Bright wrote:

 Georg Wrede wrote:

 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.


 
 Consider the Java JVM. You've probably got one installed on your 
 computer. It gets java code from gawd knows where (as the result of web 
 browsing), it compiles it, and runs it on your machine unbeknownst to you.



The thing about the JVM, though, is that it runs in a sandbox. Try to 
access the file system, or to change the display mode, from an applet or 
WebStart-enabled app. It's not going to happen without the user granting 
permission. And you know every time the JVM starts up, either from the 
Sun logo displayed as the applet loads, the Java logo in the system 
tray, or the WebStart dialog that asks permission to run the applet.

Java developers wanting to use the platform for games actually complain 
that there's too much security (or, more accurately, that the security 
dialogs are either too scary for the average user or ignored 
completely). What's worse are the independently developed browser 
plugins that allow untrusted executable binaries to run.


 
 .NET does that too.
 
 Every day my browser downloads javascript code, compiles it, and runs it.
 
 There's no reason in principle that D could not be used instead.
 
 This means that we should think about security issues. Compiling 
 untrusted code should not result in an attack on your system.
 
 http://www.comeaucomputing.com lets you upload random C++ code, compile 
 it on their system, and view the messages put out by their compiler. 
 Suppose you did it with D, had it import some sensitive file, and put it 
 out with a pragma msg statement?
Mar 27 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Mike Parker wrote:

 The thing about the JVM, though, is that it runs in a sandbox. Try to 
 access the file system, or to change the display mode, from an applet or 
 WebStart-enabled app. It's not going to happen without the user granting 
 permission. And you know every time the JVM starts up, either from the 
 Sun logo displayed as the applet loads, the Java logo in the system 
 tray, or the WebStart dialog that asks permission to run the applet.


You can run native executables in a sandbox, too. The hardware even 
supports that!
Mar 27 2009