mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Gabriel Ravier <gabravier@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] fix wide printf numbered argument buffer overflow
Date: Fri, 14 Apr 2023 11:48:20 -0400	[thread overview]
Message-ID: <20230414154820.GM4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <20230414145543.2877269-1-gabravier@gmail.com>

On Fri, Apr 14, 2023 at 04:55:42PM +0200, Gabriel Ravier wrote:
> The nl_type and nl_arg arrays defined in vfwprintf may be accessed
> with an index up to and including NL_ARGMAX, but they are only of size
> NL_ARGMAX, meaning they may be written to or read from 1 element too
> far.
> 
> For example, the following program:
> 
>  #include <assert.h>
>  #include <stdio.h>
>  #include <string.h>
>  #include <wchar.h>
> 
> int main(void) {
>    char buffer[500];
>    for (size_t i = 0; i < sizeof(buffer); ++i)
>       buffer[i] = (i % 3) ? 0 : 42;
> 
>    wchar_t result;
> 
>    int ret = swprintf(&result, 1, L"%1$s", "");
>    assert(ret != -1);
> }
> 
> evidences the bug, by sometimes mistakenly failing the assertion
> and always triggering a warning under valgrind (the behavior is highly
> dependent on build configuration - I could only reproduce the assert
> failure with GCC 12.2.1 on a very specific system - but the bug is
> still there, as evidenced by the warning valgrind always emits)

Thanks!

To clarify for readers, the reason it fails is that the wide printf
core checks that the argument type list consists of a contiguous run
of used positions followed by unused positions all the way up to the
end of the buffer. This involves checking the 9 position, which was
out-of-bounds due to an off-by-one error in the declaration. If the
overlapping memory happened to have a nonzero value, it would appear
as a present %9$ slot with one or more prior slots unused, thereby
triggering the error condition.

While all instances of nonconforming behavior and UB are bad, I don't
think this is of particular security relevance, despite being
out-of-bounds array read/write. Write is only reachable if the
application is using format strings with a 9th numbered argument
position, and affected programs seem like they should be
malfunctioning already regardless of any attacker-controlled input.
Still I'm glad to have this fix in time for a release.

Rich

      reply	other threads:[~2023-04-14 15:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 14:55 Gabriel Ravier
2023-04-14 15:48 ` Rich Felker [this message]

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=20230414154820.GM4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=gabravier@gmail.com \
    --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).