gnuplot-beta

Gnuplot qua Web-Service

[Peter D. <pc...@wi...>]

(Sorry for the cross-post.)

Salvete,

     I'm running Gnuplot as a web-service, and would like to
castrate its feral shell- and system-facilities; would  any-
one  mind  inspecting  the  attached  patch to command.c for
unintended consequences?

     In particular, I kept:

     screen_ok = false;
     c_token++';

though I'm not sure what they do.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:

Re: Gnuplot qua Web-Service

[Ethan M. <merritt@u.washington.edu>]

On Thursday 28 December 2006 09:08, Peter Danenberg wrote:
>      I'm running Gnuplot as a web-service, and would like to
> castrate its feral shell- and system-facilities; would  any-
> one  mind  inspecting  the  attached  patch to command.c for
> unintended consequences?

The particular code chunk you are eviscerating is only the
tip of the iceberg [to mix metaphors hideously]. 

Shell substitution and file/pipe creation are built into gnuplot
in multiple places.  Consider statements like
   set print "/var/www/html/index.html";  print pi
Would this trash the main page of your web site?
What about
  plot "/etc/passwd" using 0:(0):1 with labels
or
  plot "< /usr/bin/reboot"

I really don't think that gutting gnuplot's internal code is the
way to approach this.  You should rather look into chroot and
other mechanisms of isolating the web server environment
itself from the rest of the system.

Re: Gnuplot qua Web-Service

[Peter D. <pc...@wi...>]

> You should rather look into chroot and other mechanisms of isolating
> the web server environment itself from the rest of the system.


     Thanks,  Ethan; Gnuplot was pretty easily chrooted, but
as long as there's no harm in excising system() and shell(),
it seems like a prudent micro-component to a macro-security-
model.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:

Re: Gnuplot qua Web-Service

[Jonathan T. <jt...@ae...>]

On Thu, 28 Dec 2006, Peter Danenberg wrote:
>      I'm running Gnuplot as a web-service, and would like to
> castrate its feral shell- and system-facilities; would  any-
> one  mind  inspecting  the  attached  patch to command.c for
> unintended consequences?

Even if you completely shut off gnuplot's ability to fork shells
and run other commands, gnuplot is very likely not secure against
malicious inputs.  That is, it is very likely that there exist malicious
gnuplot command sequences that could trigger a buffer overflow, allowing
the attacker to execute arbitrary code of her choosing in place of gnuplot.

Thus, you sould look very carefully at the security risks of allowing
untrusted web users to talk directly to gnuplot -- they might well be
able to take over control of the gnuplot process and use it for malicious
purposes.

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: Gnuplot qua Web-Service

[Peter D. <pc...@wi...>]

> That is, it is very likely that there exist malicious gnuplot
> command sequences that could trigger a buffer overflow....


     Thanks,  Jonathan; I take it Gnuplot isn't a "hardened"
application, then.

     With Schadenfreude, nevertheless, I may take the  usual
precautions (unprivileged user, chroot, resource limits) and
set loose the patched Gnuplot.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:

Re: Gnuplot qua Web-Service

[Daniel J S. <dan...@ie...>]

Jonathan Thornburg wrote:

> Even if you completely shut off gnuplot's ability to fork shells
> and run other commands, gnuplot is very likely not secure against
> malicious inputs.  That is, it is very likely that there exist malicious
> gnuplot command sequences that could trigger a buffer overflow, allowing
> the attacker to execute arbitrary code of her choosing in place of gnuplot.

I'm not following what you are saying.  Are you saying that gnuplot can plot some big files and hence overwhelm a system?  (Say, just the way my web browser with plug-ins will allow unlimited bloated, animated adverts and will slow the system to a crawl.)  Or are you saying gnuplot will lose track of some buffer that will overflow and a hacker could stuff a nasty program in there without the system knowing?  We have been better at not allowing and ridding gnuplot of memory leaks.

Dan

Re: Gnuplot qua Web-Service

[Jonathan T. <jt...@ae...>]

I wrote
| Even if you completely shut off gnuplot's ability to fork shells
| and run other commands, gnuplot is very likely not secure against
| malicious inputs.  That is, it is very likely that there exist malicious
| gnuplot command sequences that could trigger a buffer overflow, allowing
| the attacker to execute arbitrary code of her choosing in place of gnuplot.

On Sat, 30 Dec 2006, Daniel J Sebald wrote:
> I'm not following what you are saying.  Are you saying that gnuplot can plot
> some big files and hence overwhelm a system?  (Say, just the way my web
> browser with plug-ins will allow unlimited bloated, animated adverts and will
> slow the system to a crawl.)

Hmm.  That's true, but it's not what I was thinking of.  It's basically
a denial-of-service attack.


> Or are you saying gnuplot will lose track of
> some buffer that will overflow and a hacker could stuff a nasty program in
> there without the system knowing?

This is what I meant to imply.

That is, I am saying that unless someone has done a careful security
audit on the entire gnuplot source code (which I don't think is the case),
	[And maybe even if someone *has* done an audit
	-- audits can and do miss things!]
I think it very likely that there exists one or more bugs in gnuplot
which could be exploited (by malicious command and/or data-file input)
to cause the execution of arbitrary attacker-supplied code.

I emphasize that I am *not* suggesting that gnuplot is a particularly
flawed piece of software in this regard.  Rather, I'm simply saying that
Murphy's law suggests that just about *any* piece of software that's
big, complicated, written in C, and uses lots of dynamic data structures,
probably has a few exploitable buffer-overflow bugs lurking somewhere.


> We have been better at not allowing and
> ridding gnuplot of memory leaks.

Yes, this is clearly a good thing to do.  But I don't believe we're
going to fix 100% of these bugs any time soon.  We might well fix N%
for some large N which is still < 100, and that is a very good thing,
but I don't expect to get to 100%.

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam