Subject: Re: Option to make cpp(1) not accept named pipes or devices as include
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 11/29/2004 20:41:47
In article <Pine.NEB.email@example.com>,
Jim Wise <firstname.lastname@example.org> wrote:
>-----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?
That is the only way to fix this problem, so I say go for it.