gnuplot / Bugs / #1413 Buffer overflow in epslatex terminal

AntonG - 2014-05-29

Sorry for not logging-in reporting this bug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ethan Merritt - 2014-05-29

I can't reproduce this in any of
gnuplot_4.4.4
gnuplot_4.6.3
gnuplot_4.6.4
gnuplot_4.6.5
gnuplot_5.0.rc1

I also tested issuing the commands
gnuplot> FOO = sprintf('%.850f',0)
gnuplot> print strlen(FOO)
852

I also tested current gnuplot under valgrind to see if there was indeed an overflow, detected or not. Valgrind reported no problems.

I believe that error message comes from libc itself. Could there be an issue with buffer size limits in the environment? Does a simple-minded C program that issues the same sprintf() statement cause the same error message?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Christoph Bersch - 2014-05-29
  
  I can reproduce this, but need a bit longer strings.
  
  4.6.4:
  
  gnuplot -e "set terminal epslatex header sprintf('%.857f',0)"
  
  5.0rc1:
  
  gnuplot -e "set terminal epslatex header sprintf('%.864f',0)"
  
  and running valgrind in the latter case gives:
  
  valgrind gnuplot -e "set terminal epslatex header sprintf('%.864f',0)" ==6125== Memcheck, a memory error detector ==6125== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==6125== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==6125== Command: gnuplot -e set\ terminal\ epslatex\ header\ sprintf('%.864f',0) ==6125== ==6125== Invalid read of size 1 ==6125== at 0x4C2B5A4: strcmp (mc_replace_strmem.c:730) ==6125== by 0x435B17: fill_gpval_string (eval.c:843) ==6125== by 0x435C4C: update_gpval_variables (eval.c:944) ==6125== by 0x49755E: set_command (set.c:629) ==6125== by 0x428D91: do_line (command.c:614) ==6125== by 0x428F84: do_string_and_free (command.c:452) ==6125== by 0x4185A5: main (plot.c:623) ==6125== Address 0x0 is not stack'd, malloc'd or (recently) free'd
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- AntonG - 2014-05-29
  
  Hi Ethan,
  
  I can reproduce it:
  
  gnuplot -e "set terminal epslatex header sprintf('%.850f',0)"
  buffer overflow detected : gnuplot terminated
  ======= Backtrace: =========
  /lib/x86_64-linux-gnu/libc.so.6(+0x6ea2f)[0x7f8ba77baa2f]
  /lib/x86_64-linux-gnu/libc.so.6(fortify_fail+0x37)[0x7f8ba7840dd7]
  /lib/x86_64-linux-gnu/libc.so.6(+0xf3e50)[0x7f8ba783fe50]
  /lib/x86_64-linux-gnu/libc.so.6(+0xf2deb)[0x7f8ba783edeb]
  gnuplot(+0xce408)[0x7f8ba9481408]
  gnuplot(+0x96818)[0x7f8ba9449818]
  gnuplot(+0x2468d)[0x7f8ba93d768d]
  gnuplot(+0x24878)[0x7f8ba93d7878]
  gnuplot(+0x1899b)[0x7f8ba93cb99b]
  /lib/x86_64-linux-gnu/libc.so.6(libc_start_main+0xf5)[0x7f8ba776db45]
  gnuplot(+0x18e3c)[0x7f8ba93cbe3c]
  ======= Memory map: ========
  ...
  ...
  
  Our compilation-flags are relatively strict [1]:
  
  -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat
  -Werror=format-security
  
  [1] https://buildd.debian.org/status/fetch.php?pkg=gnuplot&arch=i386&ver=4.6.5-1&stamp=1393630615
  
  Thanks
  
  Anton
  
  2014-05-29 19:39 GMT+02:00 Ethan Merritt sfeam@users.sf.net:
  
  I can't reproduce this in any of
  gnuplot_4.4.4
  gnuplot_4.6.3
  gnuplot_4.6.4
  gnuplot_4.6.5
  gnuplot_5.0.rc1
  
  I also tested issuing the commands
  gnuplot> FOO = sprintf('%.850f',0)
  gnuplot> print strlen(FOO)
  852
  
  I also tested current gnuplot under valgrind to see if there was indeed an
  overflow, detected or not. Valgrind reported no problems.
  
  I believe that error message comes from libc itself. Could there be an issue
  with buffer size limits in the environment? Does a simple-minded C program
  that issues the same sprintf() statement cause the same error message?
  
  [bugs:#1413] Buffer overflow in epslatex terminal
  
  Status: open
  Group: 5.0
  Created: Thu May 29, 2014 11:41 AM UTC by Anonymous
  Last Updated: Thu May 29, 2014 12:10 PM UTC
  Owner: nobody
  
  Dear Gnuplot developers,
  
  the following bug has been reported on Debian Bug-Tracker. I would like you
  to ask to have a look at it [1].
  
  ========================
  gnuplot -e "set terminal epslatex header sprintf('%.850f',0)"
  
  gives
  
  buffer overflow detected : gnuplot terminated
  
  But actually I really want to set a header as long as this. Longer then
  852 characters.
  ========================
  
  [1] https://bugs.debian.org/748400
  
  Thank you
  
  Anton
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/gnuplot/bugs/1413/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: ~~#1413~~
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ethan Merritt - 2014-05-29

I see it now.

post.trm and many other terminals build up the term_options[MAX_LINE_LEN+1] string by using strcat().
strcat() allows no check for overflow, so yes this is an obvious source of errors.

There are 200+ uses of strcat() in gnuplot so replacing it everywhere with a bounds-checked strncat() would be tedious, though I suppose it should be done. Or we could implement a gp_strlcat() function.

However, that would only fix the reported problem in the sense that you'd get an error message rather than a segfault. This is clearly an example of a string that shouldn't be stored in term_options at all. I wonder how many other options this is true for.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ethan Merritt - 2014-05-29

The attached patch is a fix for the specific problem. It skips storing the header string in term_options. Of course this doesn't prevent other things from causing a buffer overflow, so it's only a bandaid.

It also breaks "set term push/pop" in the corner case:
set term epslatex header "A"
...
set term push
set term epslatex header "B"
...
set term pop

That's probably not a big concern in practice, but it's unfortunate.

epslatex_header_overflow.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

AntonG - 2014-05-29

Thanks Ethan for the proposed patch! Will you apply it to the 5.0 version of Gnuplot? If so, I will not apply it to the Debian-builds, just wait for the final 5.0.

Best regards

Anton

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Ethan Merritt - 2014-05-29
  
  I will apply some variant for both 4.6.6 and 5.0. Maybe for 5.0 there should be a more widespread cleanup of the strcat() calls.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ethan Merritt - 2014-05-29

Also a work-around:

I suppose this is obvious, but if you really want a header that is many lines of code it seems simpler to put the header in a separate file and change the gnuplot command to
set term epslatex header "\\include{myheaderfile}\n"

Last edit: Ethan Merritt 2014-05-29

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ethan Merritt - 2014-05-30

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Buffer overflow in epslatex terminal

A portable, multi-platform, command-line driven graphing utility

Priority

Searches

Help

#1413 Buffer overflow in epslatex terminal

Related

Discussion

Related