mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: [musl] changes for scanf in C23
Date: Mon, 29 May 2023 12:32:02 +0200	[thread overview]
Message-ID: <20230529123202.63f09fc2@inria.fr> (raw)

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

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.

 - Newly compiled objects that don't do fancy stuff (such as
   `(scanf)(...)` or `#undef scanf`) would see hard-coded linker
   symbols such as `scanf-c17` or `scanf-c23` according to the
   standard's version they compile against. When linking statically,
   this would just chose that one particular set of functions. The
   dynamic library would always have both versions, to accomdate
   objects that have been compiled with any standard's version.

 - Old compiled objects and executables as well as those where users
   chose to `#undef` or use their own headers/prototyes would receive
   a default (something like: starting with version X, musl uses C23
   semantics), but which could be overwritten under the responsibility
   of the provider of the compiled musl library.

Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

             reply	other threads:[~2023-05-29 10:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-29 10:32 Jₑₙₛ Gustedt [this message]
2023-05-29 15:59 ` Rich Felker
2023-05-29 19:10   ` Jₑₙₛ Gustedt
2023-08-26 20:58     ` Fangrui Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230529123202.63f09fc2@inria.fr \
    --to=jens.gustedt@inria.fr \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).