We (still) use FreePascal quite a bit in our first/second-year education, in particular, in <PEACH.win.tue.nl>, our Programming Education And Contest Hosting verification system.

I was thinking of adding a remote FreePascal service along the following lines. You go to its web interface, browse for your source files (possibly a whole zip archive) on your local machine, enter command-line options, and let our server compile your stuff with a (selectable) version of fpc (under Linux), then you get back the results (possibly also in a zip archive). Mabye we can support cross compiles as well.

Why do this? Because that way people can use/try FreePascal without installing anything.

Furthermore, we plan to support several versions of FreePascal in parallel. That way, it may also be useful to the FreePascal community. E.g. when diagnosing a problem.

Here are some questions:

1. Do you think this service would be useful?

2. Do you think the interface described above is good enough? Suggestions for refinements would be appreciated.

3. Are there any security risks that we may have overlooked? Of course, we will impose certain limitation to avoid resource hogging. But maybe there are ways to put together a malicious source file that makes the compiler misbehave ...

4. Whatever else comes to your mind ...

Best regards,

Tom Verhoeff

Michael Van Canneyt wrote

Don't make all distributed units available, and forbid the use of some units. You don't want people opening an FTP socket and download 24G on your machine.

I think it only compiles things, and does not execute them.

Micha

Don't make all distributed units available, and forbid the use of some units. You don't want people opening an FTP socket and download 24G on your machine.

Even then, people could create a unit that makes direct kernel calls, or link to C. I would disallow use of the external keyword, {$L} and {$Linklib } statements in sources. So you'll definitely need some preprocessing.

Michael.

He only wants to allow remote compiling, not remote running. He wonders whether the compiler contains security holes that could be triggered by feeding it illegal source code. The answer is that it is that the compiler still contains errors which can cause it to crash in some situations, so it may be possible for specially grafted source code to make the compiler do all sorts of naughty things. I have not yet seen any examples of this, however.

Jonas

Tom Verhoeff wrote

1. Do you think this service would be useful?

Extremely useful! And a great idea. Things like that can be revolutionary.

2. Do you think the interface described above is good enough? Suggestions for refinements would be appreciated.

I work a lot with user interfaces, and as such, I beliave that this kind of project can benifit greatly from a easy to use, intuitive, good looking, but clean interface.

A few suggestions:

- Make a integrated help system. With very basic stuff about coding pascal programs. An way to access the documentation for the Run-time Library might also be nice.

- Output compiler messages, so you can see any problems witch might have occured.

- Translate the page to other languages. I am even be willing to help. I know php and xhtml well if help is needed creating the page.

Tom Verhoeff wrote

Why do this? Because that way people can use/try FreePascal without installing anything.

ah ...

installing really isn't too complicated currently.

download a tarball, expand it, and run the compiler ?

i can't imagine having to fiddle around with some webapp is going to be any simpler than that.

Mabye we can support cross compiles as well.

_this_ might actually be compelling.

i use FreePascal for developing plugins for a flight simulator for instance.

the flight simulator runs on windows, OSX and Linux, but i only have access to windows and linux for compiling.

being able to cross compile to OSX would be cool.

there are others in the same community of people who use Delphi, that i have been trying to hook into FreePascal who have the same problem.

being able to point them at a place to cross compile their Delphi projects to non-windows platforms would be cool.

Furthermore, we plan to support several versions of FreePascal in parallel. That way, it may also be useful to the FreePascal community. E.g. when diagnosing a problem.

i suspect anyone who is "diagnosing" anything to this detail is going to want to have their versions/tools locally so that can see what is going on.

Tom Verhoeff

Tony

Yes. Also for us, since this allows users to evaluate compilation with several versions. (e.g. last release, last known good snapshot, relative recent (SVN) version of each branch)

2. Do you think the interface described above is good enough? Suggestions for refinements would be appreciated.

As a design parameter, keep the possibility to use two or more builds of the same version. This mainly for SVN versions.

3. Are there any security risks that we may have overlooked? Of course, we will impose certain limitation to avoid resource hogging. But maybe there are ways to put together a malicious source file that makes the compiler misbehave ...

Make sure the mem limits are tight enough, and guard against a lot of requests in rapid order. (some ratelimiting?)

The basic problem is user spawning processes that use tons of memory. Has written "denial of service" written all over it with capital z.

Maybe there is some excuting possible via windres and via the linker call. (those contain program execution, some of those might use shell; shell code injection?)

Michael Van Canneyt wrote

I would also add the possibility to upload a zip file with some units. Processing a single unit is not useful for evaluation, and having to upload all units manually is tedious and error-prone.

From the original mail:

***
I was thinking of adding a remote FreePascal service along the following lines. You go to its web interface, browse for your source files (possibly a whole zip archive) on your local machine, enter command-line options, and let our server compile your stuff with a (selectable) version of fpc (under Linux), then you get back the results (possibly also in a zip archive). Mabye we can support cross compiles as well. ***

Jonas

I would also add the possibility to upload a zip file with some units. Processing a single unit is not useful for evaluation, and having to upload all units manually is tedious and error-prone.

Michael.

Correct. It is compile only, without execution of the resulting binary.

Tom

Michael Van Canneyt wrote

I would also add the possibility to upload a zip file with some units. Processing a single unit is not useful for evaluation, and having to upload all units manually is tedious and error-prone.

That is the intention (as indicated in my original message):

... You go to its web interface, browse for your source files (possibly a whole zip archive) on your local machine, enter command-line options, ...

Thanks for all the useful comments,

Tom

L505 wrote

Also, a simple macro could end up in a neverending loop and bring down the server. Lots of other ways to make a compiler go nuts.

The Free Pascal compiler checks for recursive expansion. If it goes over 16, it stops.

In case you prove otherwise, of course, we have a bug...

Michael.

The compiler should compile that in minutes on any recent machine :-) And you can limit the edit box length. Standard web practice, I'd say ?

One could of course forge a web request.

Michael.

I made a browser based freepascal compiler to demonstrate something I call "Browser Abuse Syndrome". Along with a Tail utility Paul was interested in seeing, it is doable. The bandwidth, though, is expensive.

Hmmm.
The helpdesk was definitely bugging me too much today. I should not try and remember FPC list threads when that happens...

My apologies :/

Michael.

Also, a simple macro could end up in a neverending loop and bring down the server. Lots of other ways to make a compiler go nuts.

- Macros, never ending loops...

- Huge source files (copy and paste 6,000,000 lines into the edit box).

One thing I would like to add to the discussion is support for the LCL. Dunno if it was explicitly the puurpose to do that already, but I thought I should mention it anyway.

Darius

I think this is a great idea.

It takes FPC beyond open source --to being fully open access.

One could, then do coding on a dummy terminal in a hotel room or wherever without having to carry around a laptop etc. Awesome, IMHO.

Why do this? Because that way people can use/try FreePascal without installing anything.

This too.

Here are some questions: 1. Do you think this service would be useful?

Definitely. See above.

2. Do you think the interface described above is good enough? Suggestions for refinements would be appreciated.

One thing I would love to have is t have an account and keep my source files etc there, which would save us both fom the uploading the sources all the time. And, a simple browser-based source editor maybe :-)

4. Whatever else comes to your mind ...

AJAX based IDE? :-)

Here is my first fpc DOS attack:

type
  TMyClassA = class;
  TMyClassA = class(TMyClassA)
    procedure DoSomething; override;
  end;

Mattias

Tom Verhoeff wrote:
[...]

Great idea. I played a little and found two security issues :

1. Consider the following program, that let's the attacker know what's the default display manager on your system:

----------------
program get_file_contents;
const
   usr = 1;
   bin = 1;
   gdm = 10;
   xdm = 100;
   kdm = 1000;
const
   Marker = 1 {$I /etc/X11/default-display-manager};
begin
   Writeln(Marker);
end.
----------------

As you can see, this is achieved by using {$I ...} with an absolute path. This way I can include arbitrary file, and do some tricks (like above creating constants "usr", "bin" ... and then a constant "Marker" that has different value depending on your display manager). This way I can investigate various things about your system.

(Wow, it was fun creating this program :) )

Conclusion: be extra-careful about what people include with $I in their submitted programs. So you have to either scan source files, or maybe run within chroot. Or you must be sure that you don't have any sensitive information readable by fpc process on your system.

2. Another minor issue: using {$I %xxx%} feature submitter can get knowledge about environment variables on your system.

----------------
begin
   Writeln({$I %PATH%});
end.
----------------

This way I know what's the value of $PATH, as seen by fpc process.

Conclusion: don't put sensitive information inside your environment variables accessible to running fpc process.

Michalis

However, I wouldn't want to install the latest version from svn when I encounter a bug in the stable release.

I was more thinking of being in need of getting some code running (by using a newer fpc version through the web), or confirming that your does/did compile properly with version x (on platform y).

Of course, you don't need to use the remote service if you have your own solution. I would certainly encourage people to install their own local version of fpc (e.g. by having a download link on the web interface and a link to the install FAQ).

The idea is that (a) it might lower the threshold for people new to fpc to give it a try; (b) to make some older/newer version of fpc easily accessible; (c) to make it easier to get started on cross compiling (though I suspect we will encounter some issues here, but I trust that these are solvable with help from the mailing lists).

Tom

I think that running the compiler must absolutely be done in a chroot() environment, with adapted environment settings and using appropriate setrlimit() settings to avoid memory and CPU hogs.

In Belgium there is a linux distribution for schools, and they run all network related processes in chroot() environments. Takes some work to set up, but is the most safe. For a service as this, I think it's definitely needed.

Michael.

Reported as 4569:
http://www.freepascal.org/bugs/showrec.php3?ID=4569

Maybe the test program can be added to the testsuite. ;-)

Vincent.

Thanks.

There are more such denial of service attack possibilities. But they don't happen in serious pascal code, so I don't think, they should pollute the bug list. The above is different, as the real bug is that fpc allows cycles and can happen by a single typo.

Other potential denial of services attacks:

Concatenation of string constants needs O(n^2).
s=' ... string ...'
+' ... string ...'
... one thousand concatenations ...
;

Include directives
FPC allows a maximum depth of 16 levels. That means a single include file can create valid n^15 include directives.

// fpc has a built-in maximum of include files depth 16
// this can be used for a denial of service attack:
{$IFNDEF DOSStarted}
{$DEFINE DOSStarted}
{$DEFINE Level1}
{$I denialofservice.inc}
{$ELSE}
{$IFDEF Level3}{$UNDEF Level3}{$DEFINE Level4}{$NOTE Level 4}{$ENDIF}
{$IFDEF Level2}{$UNDEF Level2}{$DEFINE Level3}{$NOTE Level 3}{$ENDIF}
{$IFDEF Level1}{$UNDEF Level1}{$DEFINE Level2}{$NOTE Level 2}{$ENDIF}
{$IFNDEF Level4} // increase this till 15
// include n-times
{$I denialofservice.inc}
{$I denialofservice.inc}
{$ENDIF}
{$IFDEF Level1}{$UNDEF Level1}{$NOTE Level 0}{$ENDIF}
{$IFDEF Level2}{$UNDEF Level2}{$DEFINE Level1}{$NOTE Level1}{$ENDIF}
{$IFDEF Level3}{$UNDEF Level3}{$DEFINE Level2}{$NOTE Level2}{$ENDIF}
{$IFDEF Level4}{$UNDEF Level4}{$DEFINE Level3}{$NOTE Level3}{$ENDIF}
{$ENDIF}

Maybe the test program can be added to the testsuite. ;-)

Mattias

Email Abuse Syndrome:

This makes me think we should start up something accepting emails as input to the compiler interface.

Every time someone sends an email to the FPC list, the compiler compiles any code snippets in the email. All bugs are tracked for us immediately. No need to copy and paste any more.