[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190910173038.GQ9017@brightrain.aerifal.cx>
Date: Tue, 10 Sep 2019 13:30:38 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: printf doesn't respect locale
On Tue, Sep 10, 2019 at 06:44:24PM +0200, Tim Tassonis wrote:
> On 9/10/19 6:31 PM, Szabolcs Nagy wrote:
> >* Daniel Schoepe <daniel@...oepe.org> [2019-09-10 17:00:49 +0100]:
> >>I'm also not a fan of this behavior, I actually stumbled across this
> >>when tracking
> >>down a bug the different radix usage caused.
> >
> >i'm interested in how this can cause a bug in correct software.
>
> Depends on your definition of "correct software". I'd say correct
> software has no bugs at all...
>
> Anyway, I can think of cases where the usually correct assumption is
> made that the floating point delimiter is one byte, while some
> locales maybe need two bytes. This could then of course lead to
> memory corruption when using sprintf with a too small buffer.
FWIW, if musl does adopt support for locale-variant radix point, it
will be a one-bit property switching between '.' and ','
The issue with wrong space reservations for multibyte radix points you
raise is definitely one of the motivations. There are also attacks on
glibc and other localedef-based implementations where you make a
custom locale where the radix point is something else, like a digit or
letter, to cause data to be misinterpreted in dangerous ways.
Normally attackers don't have control to do this, but it can happen
with things like ssh propagating locale environment variables to a
git-only remote account or similar.
Since there are only two values of the radix point character with any
cultural significance, support for anything else is just YAGNI
generality for its own sake, at the expense of safety.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
