gnuplot-beta — Developers and beta testers of new gnuplot code

Run in an X window - Feature request.

[Donald B. <dm...@re...>]

Hi there,

I've been using gnuplot since about 1998 and I have to say it is one of
my favourite bits of software! Well done to all concerned!

I often end up gluing together bits of software to make test rigs and
the like and it strikes me  that a couple of features would be really
nifty.

- Being able to specify at execution time an X window in which to open
the X11 driver. Something like:- gnuplot --window 0x0179AC5F This would
allow very simple embeding in other applications.

- The ability to turn off the gnu readline input such that operation
down a pipe is reliable. At the moment I have two versions of gnuplot
kicking round: both with and without gnu readline.

I'm not sure about how easy this would be as I find the size of the
gnuplot source code intimidating to my rather minor C skills.

So I'd appreciate any comments on the above ideas, but would ask to
include me on any posting as our sys admin won't let us subscribe to
mailing lists.

Once again, many many thanks.

Donald
--
Dr Donald M Burns
Special Projects Engineer

Re: Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

On Thursday 02 September 2004 01:51 am, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> > Ethan A Merritt wrote:
> >> Is it intended to allow
> >>     ./configure --enable-with-image --disable-binary-data-file
> >>
> >> If so, I suspect the following bit of code in plot2d.c will break

[which apparently it does]

> > So going beyond the attached patch to make images work with the old
> > matrix/binary code would mean tacking in a few lines in df_3dmatrix.
> > But that means passing in information about the plot style to
> > df_3dmatrix().  That brings us back to the philosophical discussion of
> > how best to do that in an organized fashion... 

I think the simpler thing is just to acknowledge that images are
intrinsically binary data, and set it up so that the specific configuration
command above is not accepted.  If you want image support, you
also need to select binary file support.

Re: Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

Daniel J Sebald wrote:

>
>
> Ethan A Merritt wrote:
>
>> Is it intended to allow
>>     ./configure --enable-with-image --disable-binary-data-file
>>
>> If so, I suspect the following bit of code in plot2d.c will break
>>
>
> You're suspecting that the !define(BINARY_DATA_FILE) will cause the 
> plotting of images to fail if an image is, say, in ASCII format in a 
> file?  Just thinking about it, I'd say you are correct, so attached is 
> a patch to remove the !define(BINARY_DATA_FILE) portion.
>
> However, the fact is that when BINARY_DATA_FILE is disabled, images 
> still won't work with ASCII matrix format.  It has to do with the 
> comment in the code below.  A couple things.  ASCII matrix is done 
> through the df_3dmatrix() routine in the non BINARY_DATA_FILE code. 
> plot2d.c does not use df_3dmatrix() so there is a conflict right 
> there. Gnuplot attempts reading the file, but the result is not as 
> expected. Second, in df_3dmatrix is the line of code:
>
>    this_iso->p_count = width;
>
> The image routine needs the p_count to be width*height of grid.  So 
> that fails.
>
> So going beyond the attached patch to make images work with the old 
> matrix/binary code would mean tacking in a few lines in df_3dmatrix. 
> But that means passing in information about the plot style to 
> df_3dmatrix().  That brings us back to the philosophical discussion of 
> how best to do that in an organized fashion... for which I don't think 
> there's been a conclusion.  Then again, my opinion is that 
> df_3dmatrix() is a rift with the df_readline() approach to data 
> entry.  (For the reason that the instruction I listed above implicitly 
> assumes something about the style of the plot, whereas df_readline 
> never does so.) 


So, to be more conclusive, I'm suggesting that in either case of having 
a "general binary" or just the "gnuplot matrix binary", it might be 
wiser to keep the df_readascii() and df_readbinary() subfunctions inside 
df_readline() and reposition a few #ifdefs to turn off "general binary" 
than it is to attempt continuing with df_3dmatrix().

Dan

Re: Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

Ethan A Merritt wrote:

>Is it intended to allow
>	./configure --enable-with-image --disable-binary-data-file
>
>If so, I suspect the following bit of code in plot2d.c will break
>

You're suspecting that the !define(BINARY_DATA_FILE) will cause the 
plotting of images to fail if an image is, say, in ASCII format in a 
file?  Just thinking about it, I'd say you are correct, so attached is a 
patch to remove the !define(BINARY_DATA_FILE) portion.

However, the fact is that when BINARY_DATA_FILE is disabled, images 
still won't work with ASCII matrix format.  It has to do with the 
comment in the code below.  A couple things.  ASCII matrix is done 
through the df_3dmatrix() routine in the non BINARY_DATA_FILE code. 
 plot2d.c does not use df_3dmatrix() so there is a conflict right there. 
 Gnuplot attempts reading the file, but the result is not as expected. 
 Second, in df_3dmatrix is the line of code:

    this_iso->p_count = width;

The image routine needs the p_count to be width*height of grid.  So that 
fails.

So going beyond the attached patch to make images work with the old 
matrix/binary code would mean tacking in a few lines in df_3dmatrix. 
 But that means passing in information about the plot style to 
df_3dmatrix().  That brings us back to the philosophical discussion of 
how best to do that in an organized fashion... for which I don't think 
there's been a conclusion.  Then again, my opinion is that df_3dmatrix() 
is a rift with the df_readline() approach to data entry.  (For the 
reason that the instruction I listed above implicitly assumes something 
about the style of the plot, whereas df_readline never does so.)

Dan


>
>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>plot2d.c:  432
>
>        case DF_FIRST_BLANK:
>#if !defined(WITH_IMAGE) || !defined(BINARY_DATA_FILE)
>            /* break in data, make next point undefined */
>            current_plot->points[i].type = UNDEFINED;
>#else
>            /* The binary input routines generate DF_FIRST_BLANK at the end
>             * of scan lines, so that the data may be used for the isometric
>             * splots.  Rather than turning that off inside the binary
>             * reading routine based upon the plot mode, DF_FIRST_BLANK is
>             * ignored for certain plot types requiring 3D coordinates in
>             * MODE_PLOT.
>             */
>            if ((current_plot->plot_style == IMAGE) || (current_plot->plot_style == RGBIMAGE))
>                continue;
>            /* break in data, make next point undefined */
>            current_plot->points[i].type = UNDEFINED;
>#endif
>
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: disabling 'insecure' parts of gnuplot file

[Hans-Bernhard B. <br...@ph...>]

On Wed, 1 Sep 2004, Ethan A Merritt wrote:

> I think you are embarking on an impossible project.

I wouldn't say "impossible", but it's a good deal harder than any of the
quick suggestions posted so far would make believe.

At the minimum, we'ld need to:

1) find all calls to "potentially unsafe" functions
2) clear up those that aren't unsafe, thanks to their call environment
   (e.g., scanf() can be unsafe, but with the right format string, it's
   quite safe)
3) trace all of the remaining unsafe ones to user interface entry
   points (including !, shell, everything conditioned on -DPIPES, 
   set output)
4) forbid all of those unconditionally based on a compile flag.  A
   runtime flag wouldn't do, because it'd be too easy to manipulate
   by any odd buffer overflow attack.  The code has to be *removed*
   from the "safe-mode" binary.

That procedure is the "security audit" I've been talking about, and I
suspect we have neither the expertise, nor the organization, nor the
man-power needed to do it.

> I rather suspect that in 4.1 it will be possible to bypass
> your test sequence using new string-handling syntax:

Well, that hole would have to be closed like Perl does it, I guess. I.e.
all strings composed by string operands are considered harmful until
proven otherwise, and forbidden to be used by any of the potentially
dangerous commands.

Over and all, I'm quite sure that running gnuplot in a chroot/jail, under
a 'nobody' account, will remain the more practical solution by a wide
margin, for quite some time, possibly forever.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: image/binary patch complete

[Hans-Bernhard B. <br...@ph...>]

On Wed, 1 Sep 2004, Daniel J Sebald wrote:

> I didn't follow the issue there.  rgb255_from_gray() was commented out 
> of CVS, then I thought maybe it was put back in for the PNG vectors 
> patch. 

I commented it out because it wasn't used.  Putting it back in, or
deciding what else to do with it, I leave to those of you who (used to)
call it.

Whether or not the similarly-named function is a supercede, or a slight
variation, or an independent re-invention, I don't know. It should be
deducible from comments, the ChangeLog and cvs log entries, though.  If
it's not, blame whoever wrote the other version. ;-)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: disabling 'insecure' parts of gnuplot file

[Edward P. <es...@pg...>]

On Wed, Sep 01, 2004 at 11:08:17PM -0700, Ethan A Merritt wrote:
> On Wednesday 01 September 2004 10:01 pm, Edward Peschko wrote:
> > here's my first attempt at a 'safe' gnuplot. It simply looks for certain
> > characters in a file ('<', '!', etc)
> 
> So no math in gnuplot any more?
> 
> No commands like
>   plot 'data' using ($1<$2 ? $1 : $2)

good point..

although I think I could get rid of this, assuming that "<" has to come 
inside a backtick or shell command in order to be used.  Backtick is already
covered...

> No logical operations like
>   if (!defined(VAR)) ...

likewise, '!' may only be used in unsafe context if it came at the 
beginning of a string, so I could qualify this... although I'm not sure
if this is totally true.

> I think you are embarking on an impossible project.
> What about commands like
>   load "malicious.script"
>   call "timebomb" "new shell" "arg1" "arg2"

call and load will need to be disabled too..

>   PART3 = "rm x11"
>   NEW_TERM = PART1.PART2.PART3
>   set print "temp"
>   print NEW_TERM
>   load "temp"

this is fixed if load is disabled... set print needs to be disabled, too

> or maybe even in-line
>   set $(PART2.PART3)

ok - then 'set \$' needs to be disabled as well.

> If you really want to pursue this, I think you would be better off 
> wrapping all source code that implements the "dangerous" features
> with an #ifndef SECURE  <suspect code> #endif
> 
> Then people who were willing to accept a substantially less
> flexible, but purportedly secure, gnuplot could do
>   ./configure --enable-secure


of course, that might be the ultimate goal of this.
However, for the purposes of both rapid prototyping and 
getting something useful (quickly), its hard to beat perl.

And - as I wrapped it under nobody, perhaps an option could be 
given to accept *all* of gnuplot syntax if a wrapper user is used.
So, it might be useful as-is as an end product.

As for hackers, yes, that is a possibility, but I think that there will
be plenty of examples of what they try to do when they connect to
my wiki (if it gets popular). The script has two modes:

  a) safe safe mode (running under nobody)
  b) safe mode 

All I have to do is run it for a six months or so under safe-safe mode - 
and log the things that people try to do. I'm sure I'll get a lot of creative
attempts to try to break into it in that time (especially if gnuplot gets 
incorporated into wikipedia itself.)

And anyhow, the fact that safe mode was hard didn't stop perl 
(for example) from having taint mode.. I don't see why its not 
worth a shot to do the same for gnuplot.

Ed


-----
ps - updated script 
-----

#!/bin/env perl 

use strict;

my $errorclasses = 
        { 
          '!' => 'shell escape not allowed!',
          '`' => 'backtick not allowed!',
          '<' => '< input not allowed!',
          '>' => '> output not allowed!',
          'output' => 'output to another file is not allowed (use stdin)',
          'outpu' => 'output to another file is not allowed (use stdin)',
          'outp' => 'output to another file is not allowed (use stdin)',
          'out' => 'output to another file is not allowed (use stdin)',
          'ou' => 'output to another file is not allowed (use stdin)',
          '' => 'setting to a variable is not allowed',

          'print' => 'printing to external files is not allowed',
          'prin' => 'printing to external files is not allowed',
          'pri' => 'printing to external files is not allowed',
          'pr' => 'printing to external files is not allowed',

          'load' => 'loading external files is not allowed',
          'loa' => 'loading external files is not allowed',
          'lo' => 'loading external files is not allowed',
          'l' => 'loading external files is not allowed',

          'call' => 'loading external files is not allowed',
          'cal' => 'loading external files is not allowed',
          'ca' => 'loading external files is not allowed',

          'terminal' => 'setting terminal is not allowed',
          'termina' => 'setting terminal is not allowed',
          'termin' => 'setting terminal is not allowed',
          'termi' => 'setting terminal is not allowed',
          'term' => 'setting terminal is not allowed',
          'ter' => 'setting terminal is not allowed',
          'te' => 'setting terminal is not allowed',

          'shell' => 'external shell is not allowed',
          'shel' => 'external shell is not allowed',
          'she' => 'external shell is not allowed',

          'system' => 'system call is not allowed',
          'syste' => 'system call is not allowed',
          'syst' => 'system call is not allowed',
          'sys' => 'system call is not allowed',
          'sy' => 'external shell is not allowed',
        };        

my $script = $ARGV[0];
my $user = ($ARGV[1] eq 'myself')? undef : $ARGV[1];
my $terminal = $ARGV[2] || "png";

my $text = _gettext($script);
my $errors = _safety(\$text);

if (@$errors)
{
  print STDERR map("Unsafe - $_\n", @$errors) if (@$errors);
}
else
{
  if ($user)
  {
    system("su $user -c '( echo \"set terminal $terminal\";cat $script )| gnuplot'");
  }
  else
  {
    system("(echo \"set terminal $terminal\"; cat $script ) | gnuplot");
  }
}

sub _safety
{
  my ($text) = @_;

  my @errors;
  my $total = 1;


  $$text =~ s"#[^\n]*""sg; # no comments.

  $DB::single = 1;

  while 
  (
    $$text =~ m/
      (.*?)
        (
          (?:(?:\n|\A)\s*\!)|            # no shells
          `|            # no backticks
          (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   \$  \S*)|  # no variable
          (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   pr  \S*)|  # no print 
          (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   ou  \S*)|  # no output
          (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   te  \S*)|  # no terminal
          (?:(?:\n|\A)\s*   she   (?:l*))|                      # no shell
          (?:(?:\n|\A)\s*   sy    [stem\s\\]*   [\$\"'])|       # no system
          (?:(?:\n|\A)\s*   l    [oad\s\\]*   [\$\"'])|         # no load
          (?:(?:\n|\A)\s*   ca   (?:[l\\\s]*)   [\$\"'])        # no call
        )
        /sgx
  )
  {
    my $before = $1;
    my $class = $2;

    my $text = $2;

    $class = _modify($class);

    my $lines = ($before =~ tr"\n"\n");

    if ($errorclasses->{$class})
    {
      $lines += ($text =~ tr"\n"\n");
      my $tot = $lines + $total;
      $text =~ s"\n""sg;
      $text =~ s"^\s*""sg;

      push(@errors, "line $tot - '$text': $errorclasses->{$class}");
      $total +=  $lines;
    }
    else
    {
      $total += $lines;
      next;
    }
  }
  return(\@errors);
}

sub _modify
{
  my ($class) = @_;

  $class =~ s"se\S*\s+""sg;
  $class =~ s"[\$\\\"\']""sg;
  $class =~ s"\s+""sg;
  return($class);
}



sub _gettext
{
  my ($script) = @_;

  open(FD, $script);
  local($/) = undef;
  my $line = <FD>;

  close(FD);

  return($line);
}

Re: disabling 'insecure' parts of gnuplot file

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

Ethan A Merritt wrote:

>If you really want to pursue this, I think you would be better off 
>wrapping all source code that implements the "dangerous" features
>with an #ifndef SECURE  <suspect code> #endif
>
>Then people who were willing to accept a substantially less
>flexible, but purportedly secure, gnuplot could do
>	./configure --enable-secure
>
>Hans-Berhard has already pointed out that a purportedly secure
>version is in a way worse than an known insecure version.
>If you use it in some critical place with no additional protection,
>then you're toast as soon as some hacker proves cleverer
>than you were in finding exploitable code sections.
>

Just following along, I tend to agree with this philosophy.  I 
understand the motivation for a SECURE version of a the program, but 
much of that security should fall upon the environment that it runs in. 
 Unix has evolved with that in mind.  A certain large software company 
keeps issuing patches to make their operating environment secure.

It seems to me a SECURE version should require only a few restrictions 
here and there if the program is launched from a non-su account.  The 
instructions where an output file or pipe are opened should probably be 
investigated.  Also, that thing Ethan pointed out with gnuplot_x11 being 
launched separately.  You'd probably have to force gnuplot_x11 to 
originate from a specific location.  You couldn't ensure security in 
gnuplot_x11 via some magic cookie, parity check, hand-shake, etc. 
because the code would be easily available for deciphering.

Dan

Re: Strange bit of code in the WITH_IMAGE patchset

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

Ethan A Merritt wrote:

>Daniel, Petr:
>
>The attached bit of code from mouse.c looks really odd.
>
>Is there really a reason for changing the behaviour of the 
>'l' hot-key (toggle log scale) depending on whether
>WITH_IMAGE is configured in or not?  If I understand
>correctly what this code does, it is now impossible to 
>toggle the y-axis log scale if your current plot contains
>image data.   Is that intended?
>
>Or, conversely.  If it is not supported to use "with image"
>if either  axis is in log mode, then shouldn't the plot command
>be rejected with an error message?
>

You've summarized this correctly.  The idea wouldn't be restricted to 
images, I guess, more generally it applies to anything where there is a 
color axis.  It's just that the variable "is_cb_plot" was introduced as 
part of the image stuff because it was a convenient thing to have when 
working with images.  (In other words, this could have been something 
all along to work with "set view map" and "splot".)

I agree that log axes and images don't mix naturally.  I probably 
thought there was no need for such a restriction because if the image 
routine can't fit a uniformly spaced grid, it issues the warning:

GNUPLOT (plot_image):  Pixel 2 (location 2,1 in grid) out of tolerance.

and continues onward, allowing all other objects to be plotted.  Exactly 
what the behavior should be in the case of a logarithmic axes and 
images, I'm not sure.  I could make it so that polygons are used and the 
pixels adjusted to their logarithmic equivalents, if feedback suggests 
that would be a good approach.  (Wouldn't be too hard to do.)

Another question here, I guess, is the behavior of "log" key when there 
are so many options for axes on the plot that could be made logarithmic. 
 That is, even in the case of no color axis in the plot, e.g., normal 
x-y line plot, there is some debate as to whether the y-axis is 
preferable to the x-axis as the one that is treated with the logarithm. 
 (It's really application dependent.  For example, if one is plotting 
the frequency characteristics of a filter, the x-axis, or frequency 
axis, is the one commonly plotted as logarithmic... well, both actually 
in the case of magnitude plots.)  What would be a really nice wish-list 
item is if the mouse position and its vicinity to the axes on the plot 
were to select which axis to apply the logarithm to.  That is, move the 
cross-hairs closer to the x-axis and the x-axis is made logarithmic when 
'l' is pressed.  But I think the axis information is lost too early in 
the chain of plotting to make that work.  Of course, the color axis is 
not a spatial entity, so exactly how one would use that scheme to make 
the color axis logarithmic, I don't know.

Dan


>
>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>mouse.c: 974
>#ifdef WITH_IMAGE
>        /* set log cb or log y whether using "with (rgb)image" plot or not */
>        if (is_cb_plot) {
>            if (CB_AXIS.log)
>                do_string_replot("unset log cb");
>            else
>                do_string_replot("set log cb");
>        } else {
>#endif
>        if (axis_array[FIRST_Y_AXIS].log)
>            do_string_replot("unset log y");
>        else
>            do_string_replot("set log y");
>#ifdef WITH_IMAGE
>        }
>#endif
>
>
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: disabling 'insecure' parts of gnuplot file

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

On Wednesday 01 September 2004 10:01 pm, Edward Peschko wrote:
> here's my first attempt at a 'safe' gnuplot. It simply looks for certain
> characters in a file ('<', '!', etc)

So no math in gnuplot any more?

No commands like
	plot 'data' using ($1<$2 ? $1 : $2)

No logical operations like
	if (!defined(VAR)) ...

I think you are embarking on an impossible project.
What about commands like
	load "malicious.script"
	call "timebomb" "new shell" "arg1" "arg2"

And that's without even touching the problems that will be
introduced by new syntax in version 4.1
I rather suspect that in 4.1 it will be possible to bypass
your test sequence using new string-handling syntax:
	PART1 = "set "
	PART2 = "te"
	PART3 = "rm x11"
	NEW_TERM = PART1.PART2.PART3
	set print "temp"
	print NEW_TERM
	load "temp"
or maybe even in-line
	set $(PART2.PART3)

If you really want to pursue this, I think you would be better off 
wrapping all source code that implements the "dangerous" features
with an #ifndef SECURE  <suspect code> #endif

Then people who were willing to accept a substantially less
flexible, but purportedly secure, gnuplot could do
	./configure --enable-secure

Hans-Berhard has already pointed out that a purportedly secure
version is in a way worse than an known insecure version.
If you use it in some critical place with no additional protection,
then you're toast as soon as some hacker proves cleverer
than you were in finding exploitable code sections.



> and operations (set terminal, set
> output) and disallows them if it finds the character strings anywhere in
> the file. If you want, you can run the command through a certain user via
> 'su':
>
> examples -
>
>     gplot_safe.p  data.dat > data.png
>     gplot_safe.p  data.dat nobody > data.png
>     gplot_safe.p  data.dat myself fig > data.fig
>
>
> The special user myself is used as a placeholder if you want another type
> of file (fig, illustrator, etc) without going through su.
>
> It was a little more difficult than I anticipated because of the
> abbreviation feature of gnuplot - and I don't know if I got all the
> 'unsafe' features so feedback is appreciated. It errs on the side of
> safety, so there may be a couple of false positives - for example,
> if there is a '!' anywhere in the file, it tags it as unsafe.
>
> Anyways, script follows..
>
> Ed
>
> ----
>
> #!/bin/env perl
>
> use strict;
>
> my $errorclasses =
>         {
>           '!' => 'shell escape not allowed!',
>           '`' => 'backtick not allowed!',
>           '<' => '< input not allowed!',
>           '>' => '> output not allowed!',
>           'output' => 'output to another file is not allowed (use stdin)',
>           'outpu' => 'output to another file is not allowed (use stdin)',
>           'outp' => 'output to another file is not allowed (use stdin)',
>           'out' => 'output to another file is not allowed (use stdin)',
>           'ou' => 'output to another file is not allowed (use stdin)',
>
>           'terminal' => 'setting terminal is not allowed',
>           'termina' => 'setting terminal is not allowed',
>           'termin' => 'setting terminal is not allowed',
>           'termi' => 'setting terminal is not allowed',
>           'term' => 'setting terminal is not allowed',
>           'ter' => 'setting terminal is not allowed',
>           'te' => 'setting terminal is not allowed',
>
>           'shell' => 'external shell is not allowed',
>           'shel' => 'external shell is not allowed',
>           'she' => 'external shell is not allowed',
>
>           'system' => 'system call is not allowed',
>           'syste' => 'system call is not allowed',
>           'syst' => 'system call is not allowed',
>           'sys' => 'system call is not allowed',
>           'sy' => 'external shell is not allowed',
>         };
>
> my $script = $ARGV[0];
> my $user = ($ARGV[1] eq 'myself')? undef : $ARGV[1];
> my $terminal = $ARGV[2] || "png";
>
> my $text = _gettext($script);
> my $errors = _safety(\$text);
>
> if (@$errors)
> {
>   print STDERR map("Unsafe - $_\n", @$errors) if (@$errors);
> }
> else
> {
>   if ($user)
>   {
>     system("su $user -c '( echo \"set terminal $terminal\";cat $script )|
> gnuplot'"); }
>   else
>   {
>     system("(echo \"set terminal $terminal\"; cat $script ) | gnuplot");
>   }
> }
>
> sub _safety
> {
>   my ($text) = @_;
>
>   my @errors;
>   my $total = 1;
>
>
>   $$text =~ s"#[^\n]*""sg; # no comments.
>
>   $DB::single = 1;
>
>   while
>   (
>     $$text =~ m/
>       (.*?)
>         (
>           \!|                                                   # no shells
>           `|                                                    # no
> backticks <|                                                    # no pipes
>
>           >|                                                    # no pipes
>
>           (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   ou  \S*)|  # no output
>           (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   te  \S*)|  # no
> terminal (?:(?:\n|\A)\s*   she   (l*))|                        # no shell
> (?:(?:\n|\A)\s*   sy    [stem\s\\]*   [\"'])          # no system )
>         /sgx
>   )
>   {
>     my $before = $1;
>     my $class = $2;
>
>     my $text = $2;
>
>     $class = _modify($class);
>
>     my $lines = ($before =~ tr"\n"\n");
>
>     if ($errorclasses->{$class})
>     {
>       $lines += ($text =~ tr"\n"\n");
>       my $tot = $lines + $total;
>       $text =~ s"\n""sg;
>       $text =~ s"^\s*""sg;
>
>       push(@errors, "line $tot - '$text': $errorclasses->{$class}");
>       $total +=  $lines;
>     }
>     else
>     {
>       $total += $lines;
>       next;
>     }
>   }
>   return(\@errors);
> }
>
> sub _modify
> {
>   my ($class) = @_;
>
>   $class =~ s"se\S*\s+""sg;
>   $class =~ s"[\\\"\']""sg;
>   $class =~ s"\s+""sg;
>   return($class);
> }
>
>
>
> sub _gettext
> {
>   my ($script) = @_;
>
>   open(FD, $script);
>   local($/) = undef;
>   my $line = <FD>;
>
>   close(FD);
>
>   return($line);
> }

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Strange bit of code in the WITH_IMAGE patchset

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

Ethan A Merritt wrote:

>On Wednesday 01 September 2004 10:34 pm, you wrote:
>  
>
>>Ethan,
>>
>>I'll take a look at this in a second, but a short note to tell you I'm
>>about to send a patch to the list for that superseded rgb_from_gray()
>>function.
>>    
>>
>
>Too late.  I already patched that in CVS.
>I also removed two pieces of redundant code in gd.trm.
>  
>

OK.  Attached is a patch to get rid of a few other warnings I've noticed.

Dan

PS:  There are few other warnings not related to the image patch left 
unaddressed.  Most of these are warnings for assignment of incomplete 
structure elements.  The others are potential uninitialized variables 
that if one looks at the logic there really isn't a problem.  But still, 
getting rid of the warning would be worth initializing the variable in 
question to zero.

color.c:114: warning: missing initializer
color.c:114: warning: (near initialization for `save_pal.gradient_num')
datafile.c:1823: warning: `axcol' might be used uninitialized in this 
function
gadgets.c:149: warning: (near initialization for `histogram_opts.title.tag')
graphics.c:1030: warning: signed and unsigned type in conditional expression
graphics.c:326: warning: `key_cols' might be used uninitialized in this 
function
plot.c:278: warning: argument `argc' might be clobbered by `longjmp' or 
`vfork'
plot.c:278: warning: argument `argv' might be clobbered by `longjmp' or 
`vfork'
plot2d.c:1964: warning: comparison of unsigned expression < 0 is always 
false
../term/pslatex.trm:219: warning: `dotIndex' might be used uninitialized 
in this function
gplt_x11.c:484: warning: missing initializer
gplt_x11.c:484: warning: (near initialization for `sm_palette.cmodel')
gplt_x11.c:2130: warning: signed and unsigned type in conditional expression
gplt_x11.c:5213: warning: signed and unsigned type in conditional expression
gplt_x11.c:5216: warning: signed and unsigned type in conditional expression

Are WITH_IMAGE and BINARY_DATA_FILE independent?

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

Is it intended to allow
	./configure --enable-with-image --disable-binary-data-file

If so, I suspect the following bit of code in plot2d.c will break


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
plot2d.c:  432

        case DF_FIRST_BLANK:
#if !defined(WITH_IMAGE) || !defined(BINARY_DATA_FILE)
            /* break in data, make next point undefined */
            current_plot->points[i].type = UNDEFINED;
#else
            /* The binary input routines generate DF_FIRST_BLANK at the end
             * of scan lines, so that the data may be used for the isometric
             * splots.  Rather than turning that off inside the binary
             * reading routine based upon the plot mode, DF_FIRST_BLANK is
             * ignored for certain plot types requiring 3D coordinates in
             * MODE_PLOT.
             */
            if ((current_plot->plot_style == IMAGE) || (current_plot->plot_style == RGBIMAGE))
                continue;
            /* break in data, make next point undefined */
            current_plot->points[i].type = UNDEFINED;
#endif


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: disabling 'insecure' parts of gnuplot file

[Edward P. <es...@pg...>]

Ok all,

here's my first attempt at a 'safe' gnuplot. It simply looks for certain characters
in a file ('<', '!', etc) and operations (set terminal, set output) and disallows
them if it finds the character strings anywhere in the file. If you want, you can
run the command through a certain user via 'su':

examples - 

    gplot_safe.p  data.dat > data.png
    gplot_safe.p  data.dat nobody > data.png
    gplot_safe.p  data.dat myself fig > data.fig


The special user myself is used as a placeholder if you want another type of file
(fig, illustrator, etc) without going through su.

It was a little more difficult than I anticipated because of the 
abbreviation feature of gnuplot - and I don't know if I got all the 
'unsafe' features so feedback is appreciated. It errs on the side of 
safety, so there may be a couple of false positives - for example, 
if there is a '!' anywhere in the file, it tags it as unsafe.

Anyways, script follows..

Ed

----

#!/bin/env perl 

use strict;

my $errorclasses = 
        { 
          '!' => 'shell escape not allowed!',
          '`' => 'backtick not allowed!',
          '<' => '< input not allowed!',
          '>' => '> output not allowed!',
          'output' => 'output to another file is not allowed (use stdin)',
          'outpu' => 'output to another file is not allowed (use stdin)',
          'outp' => 'output to another file is not allowed (use stdin)',
          'out' => 'output to another file is not allowed (use stdin)',
          'ou' => 'output to another file is not allowed (use stdin)',

          'terminal' => 'setting terminal is not allowed',
          'termina' => 'setting terminal is not allowed',
          'termin' => 'setting terminal is not allowed',
          'termi' => 'setting terminal is not allowed',
          'term' => 'setting terminal is not allowed',
          'ter' => 'setting terminal is not allowed',
          'te' => 'setting terminal is not allowed',

          'shell' => 'external shell is not allowed',
          'shel' => 'external shell is not allowed',
          'she' => 'external shell is not allowed',

          'system' => 'system call is not allowed',
          'syste' => 'system call is not allowed',
          'syst' => 'system call is not allowed',
          'sys' => 'system call is not allowed',
          'sy' => 'external shell is not allowed',
        };        

my $script = $ARGV[0];
my $user = ($ARGV[1] eq 'myself')? undef : $ARGV[1];
my $terminal = $ARGV[2] || "png";

my $text = _gettext($script);
my $errors = _safety(\$text);

if (@$errors)
{
  print STDERR map("Unsafe - $_\n", @$errors) if (@$errors);
}
else
{
  if ($user)
  {
    system("su $user -c '( echo \"set terminal $terminal\";cat $script )| gnuplot'");
  }
  else
  {
    system("(echo \"set terminal $terminal\"; cat $script ) | gnuplot");
  }
}

sub _safety
{
  my ($text) = @_;

  my @errors;
  my $total = 1;


  $$text =~ s"#[^\n]*""sg; # no comments.

  $DB::single = 1;

  while 
  (
    $$text =~ m/
      (.*?)
        (
          \!|                                                   # no shells
          `|                                                    # no backticks
          <|                                                    # no pipes
          >|                                                    # no pipes
          (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   ou  \S*)|  # no output
          (?:(?:\n|\A)\s*   se    (?:t?)   [\\\s]+   te  \S*)|  # no terminal
          (?:(?:\n|\A)\s*   she   (l*))|                        # no shell
          (?:(?:\n|\A)\s*   sy    [stem\s\\]*   [\"'])          # no system
        )
        /sgx
  )
  {
    my $before = $1;
    my $class = $2;

    my $text = $2;

    $class = _modify($class);

    my $lines = ($before =~ tr"\n"\n");

    if ($errorclasses->{$class})
    {
      $lines += ($text =~ tr"\n"\n");
      my $tot = $lines + $total;
      $text =~ s"\n""sg;
      $text =~ s"^\s*""sg;

      push(@errors, "line $tot - '$text': $errorclasses->{$class}");
      $total +=  $lines;
    }
    else
    {
      $total += $lines;
      next;
    }
  }
  return(\@errors);
}

sub _modify
{
  my ($class) = @_;

  $class =~ s"se\S*\s+""sg;
  $class =~ s"[\\\"\']""sg;
  $class =~ s"\s+""sg;
  return($class);
}



sub _gettext
{
  my ($script) = @_;

  open(FD, $script);
  local($/) = undef;
  my $line = <FD>;

  close(FD);

  return($line);
}

Strange bit of code in the WITH_IMAGE patchset

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

Daniel, Petr:

The attached bit of code from mouse.c looks really odd.

Is there really a reason for changing the behaviour of the 
'l' hot-key (toggle log scale) depending on whether
WITH_IMAGE is configured in or not?  If I understand
correctly what this code does, it is now impossible to 
toggle the y-axis log scale if your current plot contains
image data.   Is that intended?

Or, conversely.  If it is not supported to use "with image"
if either  axis is in log mode, then shouldn't the plot command
be rejected with an error message?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
mouse.c: 974
#ifdef WITH_IMAGE
        /* set log cb or log y whether using "with (rgb)image" plot or not */
        if (is_cb_plot) {
            if (CB_AXIS.log)
                do_string_replot("unset log cb");
            else
                do_string_replot("set log cb");
        } else {
#endif
        if (axis_array[FIRST_Y_AXIS].log)
            do_string_replot("unset log y");
        else
            do_string_replot("set log y");
#ifdef WITH_IMAGE
        }
#endif



-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: image/binary patch complete

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

OK, you're welcome.  Thank you Petr, and others, for your input.

I'll relinquish the floor, as it were, for patches to whomever's next. 
 (The other patches I put on sourceforge seem to conflict little with 
ongoing alterations.)

Dan


mi...@ph... wrote:

>Daniel, thanks for the great patch. I've just put it to cvs.
>Enjoy everybody!
>
>--
>PM
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: image/binary patch complete

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

Ethan Merritt wrote:

>On Tuesday 31 August 2004 02:31 am, Daniel J Sebald wrote:
>  
>
>>Yes, there are several things that can be cleaned up yet, especially if 
>>the #ifdef .. #else .. #endif constructs are untangled.  And as always, 
>>one codes something up and then later realizes a way of improving 
>>things.
>>    
>>
>
>
>../term/pdf.trm:1201: warning: implicit declaration of function `rgb255_from_gray'
>
>brogar [37] grep -l rgb255_from_gray term/*.trm
>term/gd.trm
>term/pdf.trm
>term/post.trm
>
>
>Wasn't the rgb255_from_gray() function superseded by 
>rgb255maxcolors_from_gray(double gray, rgb255_color *rgb255)
>
>Should the calls be replaced in the three drivers above,
>and the original function removed altogether?
>

I didn't follow the issue there.  rgb255_from_gray() was commented out 
of CVS, then I thought maybe it was put back in for the PNG vectors 
patch.  But if it was superseded (which looks to be the case, as I see 
now that these are duplicate functions), please change as you see fit.

Dan

Re: image/binary patch complete

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

On Tuesday 31 August 2004 02:31 am, Daniel J Sebald wrote:
> 
> Yes, there are several things that can be cleaned up yet, especially if 
> the #ifdef .. #else .. #endif constructs are untangled.  And as always, 
> one codes something up and then later realizes a way of improving 
> things.


../term/pdf.trm:1201: warning: implicit declaration of function `rgb255_from_gray'

brogar [37] grep -l rgb255_from_gray term/*.trm
term/gd.trm
term/pdf.trm
term/post.trm


Wasn't the rgb255_from_gray() function superseded by 
rgb255maxcolors_from_gray(double gray, rgb255_color *rgb255)

Should the calls be replaced in the three drivers above,
and the original function removed altogether?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: image/binary patch complete

[<mi...@ph...>]

Daniel, thanks for the great patch. I've just put it to cvs.
Enjoy everybody!

--
PM

Re: disabling 'insecure' parts of gnuplot file

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

On Wednesday 01 September 2004 08:08 am, Petr Mikulik wrote:
> Few notes:
>
> A first attempt to more secure way is to compile gnuplot without PIPES
> being defined.
>
> Then, system() and ! commands need to be disabled.

It's harder than you might think.  If you are bound and determined to
abuse a program, many paths are open.

For example,  x11.trm fires up gnuplot_x11 internally by executing
	 execvp(X11_full_command_path, optvec);

But a vandal could corrupt the path, or the environmental variables,
such that $(GNUPLOT_DRIVER_DIR)/gnuplot_x11 is a malicious program
or shell script.   To make the X terminal secure, I think you would have
to replace this whole mechanism with something else.

Re: disabling 'insecure' parts of gnuplot file

[Petr M. <mi...@ph...>]

Few notes:

A first attempt to more secure way is to compile gnuplot without PIPES being
defined.

Then, system() and ! commands need to be disabled.

And then, overload/redefine fopen() function by such a one which only plot
or splot can use for reading a file, and fail for other.

--
PM

Re: Propositions to Improve Gnuplot

[Johannes Z. <joh...@ze...>]

> > 2) Introduce a tab-completion feature as in xterm?
> 
> Exists already --- you just have to link with GNU libreadline.

not really. In gnuplot, libreadline does filename completion but is not
programmed to do command completion.

-- 
Johannes

Re: disabling 'insecure' parts of gnuplot file

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

On Tuesday 31 August 2004 06:26 pm, Edward Peschko wrote:
\> >
> > 	open stdin  from gnuplot script file
> > 	open stdout to eventual plot image
> > 	su nobody
> > 	mkdir /tmp/gnuplot/<process_id>
> > 	chdir /tmp/gnuplot/<process_id>
> > 	gnuplot
> > 	rm -rf /tmp/gnuplot/<process_id>
>
> ok.. so how do you make this generic and cross platform? 

By "cross platform" do you mean non-unix, non-cygwin?
If so, the answer is that I have no interest in doing so.  

> Right now, you can
> self-configure mediawiki by simply dropping it into a apache directory.
> Do you require people to create an extra user in order to use gnuplot?

Yes.  Or rather, I don't know.  mediawiki may provide such a
non-privileged user name anyhow.  Other wikis do.

> And how do you make it so that the 'su' doesn't require dynamic input?

Bog standard.   Make the "nobody" account have no password, so
no input required.   Anyone who does "su nobody" is forfeiting all their
privileges anyhow, so let them go ahead and do so.

> IMO unless you've got some sort of taint mode or preprocessor,
> you are just asking for trouble here..

You were doing that as soon as you decided to run a wiki.
After thinking about it, I'm not sure that you really introduce any
new security problems by running gnuplot that are not there already
if you run a general access wiki.   Vandals can already trash all the
wiki files anyhow, and the rest of the system is invisible because the 
wiki area is chroot (or if it isn't then you really need to switch
to another wiki).  So other than maybe ease-of-trashing, what's
different about running gnuplot?

I use gnuplot as a web site back-end, and have done so for years.
It has not been a problem in practice.  True, I have not
been running up-loaded scripts.   I provide access via forms, and
have the form generate a gnuplot script.   In my case any given 
form always produces the same style of plot, although the user
can force other parameters like xrange or xtics by filling in the
form.

It would not be that hard to extend this to having a set of radio-buttons
for plot style and check-boxes for many of the common gnuplot
options.  The form would always generate a trusted script, but
configurable by the user.  Then, as I already do, I would offer the
choice of running gnuplot server-side and returning the image,
or returning the script itself as a mime-tagged object to be run client-side.   
Writing such a form+cgi interface would be less work by far than
securing gnuplot, and would be a welcome contribution to the
gnuplot project if you want to volunteer.

	EAM
-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: disabling 'insecure' parts of gnuplot file

[Edward P. <es...@pg...>]

> > I think you should take the effort to make it compilably secure, but
> > that's just me...  I would think that you would *want* the ability to
> > run gnuplot using users' input. It would make the tool that much more
> > powerful.
> 
> We have that now.  What you want is something a little different: 
> you want the ability for users to safely run *each other's* input.
> It seems to me that the difficulties you are running into are not
> really a problem with gnuplot, but rather a limitation of a wiki's failure
> to distinguish one user from another.

I think its more fundamental than that - its that gnuplot cannot 
accept untrusted input.

> I think you're making this harder than it needs to be.
> Here's a variant of my previous suggestion for a wrapper;
> this one doesn't need chroot, just a captive account.
> 
> 	open stdin  from gnuplot script file
> 	open stdout to eventual plot image
> 	su nobody
> 	mkdir /tmp/gnuplot/<process_id>
> 	chdir /tmp/gnuplot/<process_id>
> 	gnuplot
> 	rm -rf /tmp/gnuplot/<process_id>

ok.. so how do you make this generic and cross platform? Right now, you can
self-configure mediawiki by simply dropping it into a apache directory.
Do you require people to create an extra user in order to use gnuplot? 
And how do you make it so that the 'su' doesn't require dynamic input?

And how about DOS attacks, ie:

!mkfile 10000000000

IMO unless you've got some sort of taint mode or preprocessor, 
you are just asking for trouble here..

Ed

Re: disabling 'insecure' parts of gnuplot file

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

On Tuesday 31 August 2004 04:28 pm, Edward Peschko wrote:
>
> plot '-' index 0, '-' index1

In my experience, that mode is not very useful.
It's better to create a file with the data in it and
plot the data from there.  If nothing else, it allows
'replot' on demand, which the inline version doesn't.
For instance, mousing with inline data does not
allow zoom, because it requires an implicit replot.
I don't think you want to go in this direction.

> I think you should take the effort to make it compilably secure, but
> that's just me...  I would think that you would *want* the ability to
> run gnuplot using users' input. It would make the tool that much more
> powerful.

We have that now.  What you want is something a little different: 
you want the ability for users to safely run *each other's* input.
It seems to me that the difficulties you are running into are not
really a problem with gnuplot, but rather a limitation of a wiki's failure
to distinguish one user from another.

I think you're making this harder than it needs to be.
Here's a variant of my previous suggestion for a wrapper;
this one doesn't need chroot, just a captive account.

	open stdin  from gnuplot script file
	open stdout to eventual plot image
	su nobody
	mkdir /tmp/gnuplot/<process_id>
	chdir /tmp/gnuplot/<process_id>
	gnuplot
	rm -rf /tmp/gnuplot/<process_id>

The user "nobody" would have write access to
/tmp/gnuplot  but nowhere else on the system.
Yes, an abusive input stream could be to corrupt another plot 
being made at the same time, but I would 
live with since the time window is small.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: disabling 'insecure' parts of gnuplot file

[Edward P. <es...@pg...>]

>
> There is another option that I have found useful in the past.
> It would achieve exactly what you describe above, but it 
> does assume that the script is trusted. What you can do  
> is to associate the mime type "application/gnuplot" with 
> a gnuplot wrapper script, and have the web site return the
> script itself via a browser click.  This is the ultimate in not
> losing anything to translation.  For details, see

well, yes, but I also want to display the graph itself, not just the data.
Seeing the graph would be the default - there would be a data function to see
the data associated with it - associated with 

Perhaps the way around this is to start from the ground up - namely
extract the parts of gnuplot functionality that I'd need and build a 
'mini-gnuplot'. Just thinking out loud here, I don't know how hard this
would be to do.

> issues you are worried about are not of primary concern.
> The data being plotted can either be local to the user's machine,
> or can be pulled from the web site via http protocols.
> If the data were on a wiki site, my procedure would allow 
> your (a), (b) and (c) above.

right, but wiki allows an 'upload file' feature, which means
you can't assume trust. And even if you *did* show just the graph,
you really can't take the chance that someone won't cut and copy it
into their machine, run it, and cause themselves grief..

Come to think of it, maybe a preprocessor is the way to go - but 
instead of running the gnuplot graph, it shields against malicious 
constructs before the fact, so that they never even get to the server. 
Or perhaps just allows a small subset of functionality, and junks the rest.

I think that a wrapper like this would be a worthwhile thing to include
with the gnuplot distribution..

Ed