Ian Lance Taylor
Friday, 8 June 2007 1:52 a.m.
>
> At the very least there should be a compiler option for standard
> conformant behaviour in this area. I didn't see one in the MSDN docs.
> I would say that gets is much more dangerous than %n in printf, but
> presumably Microsoft does not disable
Matt Fago <[EMAIL PROTECTED]> writes:
> > I would say that gets is much more dangerous than %n in printf, but
> > presumably Microsoft does not disable gets
>
> Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005
> generates:
>
> warning C4996: 'gets': This function
> I would say that gets is much more dangerous than %n in printf, but
> presumably Microsoft does not disable gets
Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005
generates:
warning C4996: 'gets': This function or variable may be unsafe. Consider
using gets_s
Florian Weimer <[EMAIL PROTECTED]> writes:
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> instead of
>
> printf("%s", some_string);
> syslog(LOG_INFO, "%s", some_string);
On Thu, Jun 07, 2007 at 12:09:46PM +0200, Paolo Bonzini wrote:
>
> >printf (_("foo %s%n"), some_string, &n);
> >is ok even with -D_FORTIFY_SOURCE=2
>
> How is this considered ok? Is _("abc") placing the translation in
> non-writable memory?
Yes, the *.mo file is mmaped and gettext either retur
printf (_("foo %s%n"), some_string, &n);
is ok even with -D_FORTIFY_SOURCE=2
How is this considered ok? Is _("abc") placing the translation in
non-writable memory?
Paolo
On Thu, Jun 07, 2007 at 10:36:43AM +0200, Florian Weimer wrote:
> * Ian Lance Taylor:
>
> > What is the security issue here?
>
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> i
* Ian Lance Taylor:
> What is the security issue here?
The issue arrases in programs that pass attacker-controlled data as
the format string. They use
printf(some_string);
syslog(LOG_INFO, some_string);
instead of
printf("%s", some_string);
syslog(LOG_INFO, "%s", some_string);
The ma
I think a sprintf followed by a strlen and printf is _guarenteed_ to be
much
more portable than printf's return value. The overhead of the strlen is
minimal.
Maybe portable, but how do you choose the length of the buffer to pass
to sprintf! Ironic: we'd be trading a mostly-bogus security issue
> I think a sprintf followed by a strlen and printf is _guarenteed_ to be much
> more portable than printf's return value. The overhead of the strlen is
> minimal.
Maybe portable, but how do you choose the length of the buffer to pass
to sprintf! Ironic: we'd be trading a mostly-bogus security
Danny Smith wrote:
Unless I'missing soemthing, this is 'just' a build issue in genmode.c.
GCC builds fine for Vista target on WindowsXP. So the fix needs to be
build dependent, not host dependent.
Well if a clean fix can be found that simply avoids the use of %n, then
that's target independen
Danny Smith wrote:
Unless I'missing soemthing, this is 'just' a build issue in genmode.c.
GCC builds fine for Vista target on WindowsXP.
So the fix needs to be build dependent, not host dependent.
Well if a clean fix can be found that simply avoids the use of %n, then
that's target independ
Andrew Haley wrote:
Mmm, but I don't believe that the printf function returning the number
of characters transmitted is problematic. As far as we know, that
works everywhere. The only thing to say otherwise is a man page. My
guess is the man page is wrong.
OK, I misunderstood the situation,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Simon Brenner
> Sent: Thursday, 7 June 2007 2:40 a.m.
> > > Or just add a call to _set_printf_count_output in the relevant
> > > place, since AFAIK %n is still a standard-mandated printf format
> > >
Robert Dewar writes:
> Andrew Haley wrote:
>
> > Yes we can. gcc is written in ISO C, and ISO C says that the printf
> > function returns the number of characters transmitted, or a negative
> > value if an error occurred. We don't support bootstrapping gcc on
> > non-ISO systems.
>
> We
Paolo Bonzini wrote:
> * genmodes.c (tagged_printf, emit_insn_modes_h): Don't
> use %n on printf.
Almost identical to what we have been doing internally to circumvent
the issue, Thanks.
Olivier
Ian Lance Taylor wrote:
> What is the security issue here? I'm not seeing it. Are they
> concerned that attackers will modify the print control string somehow?
I don't know. We simply have observed bootstrap problems during
preliminary experiments on Vista, found them to be caused by
uninitia
Or, if we think that other systems are likely to also start disabling
%n by default, then it would make sense for us to change the code. It
would be easy to replace it with strlen calls, or, as you suggest, by
checking the return value of printf. The return value of printf is
portable (unlike
On Wed, Jun 06, 2007 at 07:29:26AM -0700, Ian Lance Taylor wrote:
> Olivier Hainque <[EMAIL PROTECTED]> writes:
>
> > genmodes.c uses the %n capabilities of printf to compute the width of
> > pieces it outputs. This causes troubles on Windows Vista, because ...
> >
> ><< Because of security r
Simon, you need to type:
man 3 printf
to read about printf() the C function.
Argh! Indeed I was reading the wrong manpage. That probably means
almost everything I've concluded and said was wrong :/ Apparently,
throwing your two cents in can reduce the total value of a discussion.
According to
Olivier Hainque <[EMAIL PROTECTED]> writes:
> genmodes.c uses the %n capabilities of printf to compute the width of
> pieces it outputs. This causes troubles on Windows Vista, because ...
>
><< Because of security reasons, support for the %n format specifier is
> disabled by default in
> According to my manpage, printf returns 0 on success, 1 on failure. No
> mention of the number of characters written. This is different with
> sprintf/snprintf (see e.g
> http://www.opengroup.org/onlinepubs/95399/functions/snprintf.html),
> but IIRC a number of platforms don't implement those
> Documentation error? They've got the same man page for printf(1)
> and printf(3):
Oh, except trying it on a real Mac they don't - that website's broken.
Simon, you need to type:
man 3 printf
to read about printf() the C function.
Rup.
__
Andrew Haley wrote:
> > In this case, it's the Mac OS X man page. Which I now see doesn't
> > say the same thing as POSIX. Which was just the point I was
> > trying to make you can't rely on the return value for determining
> > the number of characters written.
> Yes we can. gcc is written in ISO
Please don't top-post.
Simon Brenner writes:
> On 6/6/07, Dave Korn <[EMAIL PROTECTED]> wrote:
> > On 06 June 2007 12:04, Simon Brenner wrote:
> >
> > > According to my manpage, printf returns 0 on success, 1 on failure. No
> > > mention of the number of characters written.
> >
> > Well,
In this case, it's the Mac OS X man page. Which I now see doesn't say
the same thing as POSIX. Which was just the point I was trying to make
- you can't rely on the return value for determining the number of
characters written.
Oh, and I am sure the reality of my Operating System is very close to
On 06 June 2007 12:04, Simon Brenner wrote:
> According to my manpage, printf returns 0 on success, 1 on failure. No
> mention of the number of characters written.
Well, maybe you should ...
> use a Real Operating System
! What man page exactly are you referring to?
cheers,
In this case, you don't have to look far to see that you can't use the
return value of printf.
According to my manpage, printf returns 0 on success, 1 on failure. No
mention of the number of characters written. This is different with
sprintf/snprintf (see e.g
http://www.opengroup.org/onlinepubs/0
28 matches
Mail list logo
