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.