Hi,

My memory of the timeline of D features is quite fuzzy, so I created a service to test snippets of D source code with *all* of the DMD versions publicly available.

Right now the service is *very* in the rough and the UI is butt ugly (it just outputs the raw results), but it seems to be working. Give it a try, to fill it with some data and start exposing the bugs:

    http://www.luismarques.eu/d/archeology

I haven't yet secured the client which does the tests, and I imagine that the old DMD versions are full of vulnerabilities, so please don't be a jerk :-) (I hope the client doesn't die, I left it running at work, as I don't have a Windows machine set up at home).

Thanks for Adam "Destructinator" Ruppe, for fixing the bugs I encountered in the ddb library (PostgreSQL lib).

Luís

On Saturday, 21 December 2013 at 00:22:23 UTC, Luís Marques wrote:
> I haven't yet secured the client which does the tests, and I imagine that the old DMD versions are full of vulnerabilities, so please don't be a jerk :-) (I hope the client doesn't die, I left it running at work, as I don't have a Windows machine set up at home).

This is not running in a sandbox? And it's running on a *Windows machine*?

I really recommend you take it down. Someone will come around and infect your work network, it's just a matter of time.

On Saturday, 21 December 2013 at 00:47:49 UTC, Jakob Ovrum wrote:
> This is not running in a sandbox? And it's running on a *Windows machine*?
>
> I really recommend you take it down. Someone will come around and infect your work network, it's just a matter of time.

To be clear, the user provided source code is not run, it is only compiled. Do you really think I should take it down? (They would have to read this post, go find a DMD exploit, etc.)

On Sat, Dec 21, 2013 at 01:47:39AM +0100, Jakob Ovrum wrote:
> On Saturday, 21 December 2013 at 00:22:23 UTC, Luís Marques wrote:
> >I haven't yet secured the client which does the tests, and I imagine that the old DMD versions are full of vulnerabilities, so please don't be a jerk :-) (I hope the client doesn't die, I left it running at work, as I don't have a Windows machine set up at home).
> 
> This is not running in a sandbox? And it's running on a *Windows machine*?
> 
> I really recommend you take it down. Someone will come around and infect your work network, it's just a matter of time.

Yeah, this is a very bad idea. This forum is open to the public Internet; your message could be seen by people who you might not want to know about your server. You'll get hacked. You really need to run it inside a sandbox and/or setup user authentication before posting it to the public Internet.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

On Sat, Dec 21, 2013 at 01:54:49AM +0100, digitalmars-d-bounces@puremagic.com wrote:
> On Saturday, 21 December 2013 at 00:47:49 UTC, Jakob Ovrum wrote:
> >This is not running in a sandbox? And it's running on a *Windows machine*?
> >
> >I really recommend you take it down. Someone will come around and infect your work network, it's just a matter of time.
> 
> To be clear, the user provided source code is not run, it is only compiled. Do you really think I should take it down? (They would have to read this post, go find a DMD exploit, etc.)

Well, in that case it's not *as* bad of an idea. :P  But still, you want to be careful any time arbitrary, unfiltered user input is involved, especially when said user input is code (the executable may not be run, but remember that D code has CTFE).


T

-- 
Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn

On Saturday, 21 December 2013 at 01:03:32 UTC, H. S. Teoh wrote:
> Well, in that case it's not *as* bad of an idea. :P  But still, you want
> to be careful any time arbitrary, unfiltered user input is involved,
> especially when said user input is code (the executable may not be run,
> but remember that D code has CTFE).

Yeah. When I started using the "ddb" library for this venture
textual query parameters were unimplemented. I declined to use
the suggested workaround of query string concatenation; now *that*
would be really dangerous  :-) Once again, thanks for Adam Ruppe
for making those work.

On Saturday, 21 December 2013 at 00:54:52 UTC, Luís Marques wrote:
> On Saturday, 21 December 2013 at 00:47:49 UTC, Jakob Ovrum wrote:
>> This is not running in a sandbox? And it's running on a *Windows machine*?
>>
>> I really recommend you take it down. Someone will come around and infect your work network, it's just a matter of time.
>
> To be clear, the user provided source code is not run, it is only compiled. Do you really think I should take it down? (They would have to read this post, go find a DMD exploit, etc.)

Oh, right.

Well, then it does become a lot harder to exploit, but DMD being a C++ project it might be prone to security flaws, especially in past versions (I'm not very familiar with the DMD codebase, so can't say for sure). Make sure you don't link the executables at least, so DMD is the only point of failure. I would use "-c -o-". It becomes security through obscurity - who would want to rummage through past versions of DMD's source code?

Anyway, I know for a fact that one can easily make DMD go into an infinite loop in various ways, so you'd have to implement some kind of timeout (not talking about CTFE here, which I think is self-limiting).

On Saturday, 21 December 2013 at 01:14:05 UTC, Jakob Ovrum wrote:
> Anyway, I know for a fact that one can easily make DMD go into an infinite loop in various ways, so you'd have to implement some kind of timeout (not talking about CTFE here, which I think is self-limiting).

Yes, I implemented a timeout of just a few seconds (7s, I think). It's short so that it doesn't take too long to test with all the compiler versions. I actually tested that the template recursion is limited (500) but not CTFE (at least in my check of that it was still executing after about 15 minutes). That's also why there is already a test called "infinite CTFE", I wanted to make sure that a DOS could not be achieved with a single test case (but is still easy at the moment, since I don't have rate limiting ;))

On Sat, Dec 21, 2013 at 02:13:21AM +0100, Jakob Ovrum wrote: [...]
> Anyway, I know for a fact that one can easily make DMD go into an infinite loop in various ways, so you'd have to implement some kind of timeout (not talking about CTFE here, which I think is self-limiting).

CTFE is self-limiting? Is there an internal timeout? I mean, what stops one from doing something like:

	enum x = ctfeFunc();
	int ctfeFunc() {
		int i=1;
		while (i != 0)
		{
			i++;
			if (i > 5)
				i = 1;
		}
		return i;
	}

which would never terminate (neither will it consume memory or create objects, so you have to solve the halting problem to know whether it will terminate)?


T

-- 
Meat: euphemism for dead animal. -- Flora

On Saturday, 21 December 2013 at 01:14:05 UTC, Jakob Ovrum wrote:
> Well, then it does become a lot harder to exploit, but DMD being a C++ project it might be prone to security flaws, especially in past versions (I'm not very familiar with the DMD codebase, so can't say for sure). Make sure you don't link the executables at least, so DMD is the only point of failure. I would use "-c -o-". It becomes security through obscurity - who would want to rummage through past versions of DMD's source code?

I am indeed using -c, but unfortunately early versions of DMD do not have -o-