cscope

Mu5riK <a href="http://teslcjckkydb.com/">teslcjckkydb</a>,
[url=http://zzlauxetmaer.com/]zzlauxetmaer[/url],
[link=http://fbxnqvqnidwo.com/]fbxnqvqnidwo[/link],
http://zsnflexfvkyp.com/

Logged In: YES
user_id=27517

The majority of these should be fixed now. Closing this
report. If anything is still critical, open a new report.

Logged In: YES
user_id=827328

I'll test it out this weekend.

Logged In: YES
user_id=125727

There do appear to be a number of portable snprintf
implementations out there:

http://www.ijs.si/software/snprintf/

I'm guessing that the apache one (see links a the bottom) is
probably both well tested, and license-compatible with cscope.

Logged In: YES
user_id=27517

No. First of all, the current main entry in our list of
"systems without snprintf" is DOS, not Windows --- but
anway, whatever we do should *portable*. Second, no,
DOS/DPMI doesn't generally offer read-only memory. Third,
rolling such a system on our own would be almost as serious
overkill as writing our own snprintf.

Anyway, I'm reasonably sure we don't need snprintf() for all
the problematic calls we have right now. Most of them can
be fixed by specifying explicit field widths, I think.

Logged In: YES
user_id=827328

what about a completely different approach for systems
without snprintf? Perhaps a canary type defense? Is it
possible under windows to make memory pages non-writeable
(a-la mprotect)? If so, we could wrap snprintf in a wrapper
function that allocates an extra stack page and a static
buffer which it uses in the wrapped call to sprintf. We
mprotect teh extra page to be read-only, so that if the
underlying call overwrites the static buffer, we catch a
segfault. It still crashes the system, but we avoid the
potential for expoits. Its kinda slow, but it solves the
problem for systems that don't have snprintf.

Logged In: YES
user_id=27517

We have at least one such platform: DJGPP V2.03, the MSDOS
port of GCC & friends (binaries also run on Windows, and can
be preferrable to Cygwin for various reasons.)

A warning at configure or compile time wouldn't suffice: if
snprintf() isn't there, you need either variadic macro
support (i.e. a C99-alike compiler) or vsprintf to work
around that, unless you're willing to re-work every single
call of sprintf() --- in which case it loses a good part of
its appeal. Unless you want to do something truly ugly, like

#if HAVE_SNPRINTF
# define nsize(size) , size
#else
# define snprintf sprintf
# define nsize(size) , /* nothing */
#endif

and obfuscate all calls to snprintf like this:

snprintf(buf nsize(bufsize), "%format", ...)

I don't want to do that. Not if we can avoid it at almost
any cost.

Logged In: YES
user_id=827328

How many platforms do you think we have at this point that
don't have snprintf? Is it worth perhaps just adding a
message to the configure stage or a #warning during the
build to indicate that the lack of snprintf means the
resultant binary can be open to various buffer overflow attacks?

Logged In: YES
user_id=27517

Defining your own snprintf is surprisingly hard --- that's
the main reason it's an ISO C99 requirement now. It's
essentially impossible to implement a complete snprintf() in
user code. About the only portable global modification that
works is

#if !HAVE_SNPRINTF
# define snprintf plastic_snprintf
#endif

and then implement a cheap plastic version of snprintf that
just calls vsprintf in turn and simply drops the bufsiz
argument on the way. If you lack vsprintf(), too, you're toast.

Logged In: YES
user_id=827328

well, configure already determines if snprintf is available
and sets HAVE_SNPRINTF accordingly, so what if we define our
own snprintf in the event that HAVE_SNPRINTF isn't defined
to check lengths on our own?

Logged In: YES
user_id=27517

It's not quite that simple --- snprintf() isn't reliably
available, so we can't use it without a fall-back plan.

Logged In: YES
user_id=827328

It sounds like most of this could be fixed by a recursive:
sed -e's/\(sprintf\)\(.*\,)\(.*\)/snprintf\2PATHLEN,\3/'

Does that sound about right? :)