Subject: Option to make cpp(1) not accept named pipes or devices as include
To: None <>
From: Jim Wise <>
List: tech-toolchain
Date: 11/29/2004 14:31:56
Hash: SHA1

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?

- -- 
				Jim Wise
Version: GnuPG v1.2.6 (NetBSD)