Subject: Option to make cpp(1) not accept named pipes or devices as include
To: None <email@example.com>
From: Jim Wise <firstname.lastname@example.org>
Date: 11/29/2004 14:31:56
-----BEGIN PGP SIGNED MESSAGE-----
I have been looking at finally resolving the DoS attack noted in
# calendar uses cpp to expand user calendars.
# calendar -a can be used as a local DOS by making an included file a
# named pipe, thus this is turned off by default.
Now, obviously, this could be done by denying users the ability to use
cpp on their calendar files, but this would be a mistake since
#include'ing the calendars of holidays in /usr/share/calendar is a very
typical use of calendar.
This could also be solved by adding a rudimentary #include processor to
calendar(1) itself, but this would get messy fast, and would almost
certainly break some ways in which users use cpp directives in calendar
A third way to solve this would be to give cpp(1) the ability,
controlled by a command line option or an environment variable, to
refuse to parse any file which is not S_ISREG(). This would be easy to
add, since cpp already (at line 292 of cppfiles.c) skips any directory
which is #includ'ed, continuing to search the include path for the
specified file name.
Doing this would, in addition, have general utility, since other
utilities which use cpp to parse untrusted input files could benefit as
What do people think? Is this not worth touching the cpp sources for
(even given that such changes would be fed back to FSF)? Does anyone
see another way to provide utilities the ability to parse untrusted cpp
input files safely?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----