Hi Eric,
> On the cygwin list, it was pointed out that printf("%**s",1,"a","b")
> proceeds to try to print "b" with a field width of whatever the integer
> value of the pointer to "a" contained (or, in other words, each additional
> * consumes another vararg position off the stack). This quickly becomes a
> denial of service or even an exploitable security hole.
How can it become a security hole? Format strings come
1) from the program, where the programmer has coded them and where gcc
has checked them,
2) from .mo files, where the translator has coded them and where msgfmt -c
has checked them.
Are you saying that there are other origins of format strings? In that case,
would it be useful to bring msgfmt's format string checking for C as a ready-
to-use service into gnulib?
> Is detection of invalid format strings something that we want the gnulib
> replacement *printf routines to handle
If it is indeed a security problem and there are no better ways to fix the
security problem, I can imagine that some programmers will indeed say: "My
program should be safe even on unsafe system." (Just like libintl grew out
of the idea "my program should be localizable even on libc5 and cygwin
systems".) So, we should provide for example for snprintf 3 modules:
snprintf - substitute if function is missing
snprintf-posix - substitute if function is not POSIX compliant
snprintf-posix-safe - substitute if function is unsafe
> if so, what semantics should we provide in rejecting the bad string?
I would say that returning with errno = EINVAL is appropriate. That is the
usual errno value for invalid arguments.
Bruno
