Remote FreePascal compile service, feedback requested

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Remote FreePascal compile service, feedback requested

Michalis Kamburelis
Tom Verhoeff wrote:
[...]
>
> 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.
>

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Remote FreePascal compile service, feedback requested

Tom Verhoeff
In reply to this post by Tony Pelton
On Mon, Dec 05, 2005 at 10:03:58AM -0500, Tony Pelton wrote:

> On 12/5/05, Tom Verhoeff <[hidden email]> wrote:
> > Why do this?  Because that way people can use/try FreePascal without
> > installing anything.
>
> 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.

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

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

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
--
E-MAIL: T.Verhoeff @ TUE.NL     | Fac. of Math. & Computing Science
PHONE:  +31 40 247 41 25        | Eindhoven University of Technology
FAX:    +31 40 247 54 04        | PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/  | The Netherlands
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Remote FreePascal compile service, feedback requested

Michael Van Canneyt
In reply to this post by Michalis Kamburelis


On Tue, 6 Dec 2005, Michalis Kamburelis wrote:

> Tom Verhoeff wrote:
> [...]
>>
>> 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.
>>
>
> 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.

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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Remote FreePascal compile service, feedback requested

Vincent Snijders
In reply to this post by Mattias Gaertner
Mattias Gaertner wrote:

> On Mon, 5 Dec 2005 18:50:28 +0100 (CET)
> Michael Van Canneyt <[hidden email]> wrote:
>
>
>>
>>On Mon, 5 Dec 2005, 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...
>
>
> Here is my first fpc DOS attack:
>
> type
>   TMyClassA = class;
>  
>   TMyClassA = class(TMyClassA)
>     procedure DoSomething; override;
>   end;

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

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

Vincent.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Remote FreePascal compile service, feedback requested

Mattias Gaertner
On Tue, 06 Dec 2005 11:08:26 +0100
Vincent Snijders <[hidden email]> wrote:

> Mattias Gaertner wrote:
> > On Mon, 5 Dec 2005 18:50:28 +0100 (CET)
> > Michael Van Canneyt <[hidden email]> wrote:
> >
> >
> >>
> >>On Mon, 5 Dec 2005, 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...
> >
> >
> > Here is my first fpc DOS attack:
> >
> > type
> >   TMyClassA = class;
> >  
> >   TMyClassA = class(TMyClassA)
> >     procedure DoSomething; override;
> >   end;
>
> Reported as 4569:
> http://www.freepascal.org/bugs/showrec.php3?ID=4569

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Remote FreePascal compile service, feedback requested

L505
In reply to this post by Vincent Snijders

> > Here is my first fpc DOS attack:
> >
> > type
> >   TMyClassA = class;
> >
> >   TMyClassA = class(TMyClassA)
> >     procedure DoSomething; override;
> >   end;

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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12