From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14639 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf doesn't respect locale Date: Tue, 10 Sep 2019 13:30:38 -0400 Message-ID: <20190910173038.GQ9017@brightrain.aerifal.cx> References: <20190909175452.GO9017@brightrain.aerifal.cx> <20190910163143.GI22009@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="17356"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14655-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 10 19:30:54 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i7jyf-0004PR-PJ for gllmg-musl@m.gmane.org; Tue, 10 Sep 2019 19:30:53 +0200 Original-Received: (qmail 30551 invoked by uid 550); 10 Sep 2019 17:30:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30533 invoked from network); 10 Sep 2019 17:30:51 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14639 Archived-At: 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 [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