[Insight-developers] formatstring vulnerability in NumericSeriesFileNames::GetFileNames

Kent Williams kent at psychiatry.uiowa.edu
Tue Jun 27 10:48:49 EDT 2006


On platforms that support it. substituting snprintf will remove the 
buffer overflow problem.
I checked, and Linux,MacOSX and Irix support snprintf. Not all Windows 
compilers support snprintf, though Visual C++ and Borland C++ do have 
_snprintf going back several versions, which is the same thing.

It would be a worthy goal to remove printf family functions from 
Insight, both because of the potential for buffer overruns, and because 
printf isn't part of "The C++ Way."  Unfortunately printf-family 
functions seem to provide finer-grained control over output formats than 
their C++ replacements, or at least I've never seen a concise 
description of how to replace printf with functionally equivalent stream 
operations.

It probably wouldn't hurt to add a snprintf wrapper to the KWSys 
library, to hide compiler dependencies. In looking through the KWSys 
header, I noticed there is a function EstimateFormatLength, which will 
return the upper bound on the buffer size needed for a particular format 
and argument list. Unfortunately it uses va_list argument lists, which 
are rather clumsy to use.

Boost has a replacement, but due to the Boost build system, if you want 
to use Boost, you have to live in Boost's world.

Henning Meyer wrote:

> Hello,
>
> I just had a look a this function and it looks like there is a format
> string vulnerability:
>  char temp[4096];
>  for (unsigned long i = m_StartIndex; i <= m_EndIndex; i+= 
> m_IncrementIndex)
>    {
>    sprintf (temp, m_SeriesFormat.c_str(), i);
>    std::string fileName(temp);
>    m_FileNames.push_back(fileName);
>    }
> As far as I have seen the length of m_SeriesFormat is not checked. So
> one might use it for format string attacks.



More information about the Insight-developers mailing list