Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <DS7PR12MB5765880208B3AB7E588CD462CBE2A@DS7PR12MB5765.namprd12.prod.outlook.com>
Date: Sat, 26 Aug 2023 13:58:26 -0700
From: Fangrui Song <i@...kray.me>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Subject: Re: changes for scanf in C23

On Mon, May 29, 2023 at 12:11 PM Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> wrote:
>
> Rich,
>
> on Mon, 29 May 2023 11:59:29 -0400 you (Rich Felker <dalias@...c.org>)
> wrote:
>
> > On Mon, May 29, 2023 at 12:32:02PM +0200, Jₑₙₛ Gustedt wrote:
> > > Hi,
> > > we already discussed this but it doesn't seem that we have come to a
> > > conclusion.
> > >
> > > The problem is that for C23 semantics of several string to integer
> > > conversion functions change: a 'b' or 'B' that previously was the
> > > stop condition for integer parsing may become part of the integer
> > > string. This concerns all `scanf` and `strto` derivatives.
> > >
> > > This is probably not a problem for most applications that parse
> > > strings to integers, but it could be in some situations, and in
> > > particular it could open vulnerabilities. E.g network addresses that
> > > are read with base `0` (musl does this at some point to allow to
> > > have decimal or hex strings) could be open to attacks, once people
> > > start using binary encodings for integers more often. Another
> > > scenario where this could lead to harm is automatically produced
> > > output that is automatically scanned, and where nobody previously
> > > took care of proper word boundaries.
> > >
> > > My current idea is to have two sets of these functions, one that has
> > > the old semantics and one that has the new.
> >
> > This was rejected already in the first proposal (thread here):
> >
> > Message-ID: <20230503000045.GU4163@...ghtrain.aerifal.cx>
> > https://www.openwall.com/lists/musl/2023/05/03/1
> >
> >     "There are not going to be different versions of scanf/strto*
> >     because there's just no way to do that in a conforming way..."
>
> Alright, saves me a lot of trouble. I'll forward all complaints by
> users to you ;-)
>
> Jₑₙₛ
>
> --
> :: ICube :::::::::::::::::::::::::::::: deputy director ::
> :: Université de Strasbourg :::::::::::::::::::::: ICPS ::
> :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
> :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
> :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

Nice! Not introducing new symbols saved me time on
https://reviews.llvm.org/D158943 (sanitizer patch to intercept glibc
2.38 introduced __isoc23_strtol and __isoc23_scanf family functions
for binary compatibility).

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.