qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, kwolf@redhat.com
Subject: Re: [PATCH for-9.1 0/2] NBD: don't print raw server error text to terminal
Date: Mon, 5 Aug 2024 20:11:31 +0100	[thread overview]
Message-ID: <20240805191131.GE1450@redhat.com> (raw)
In-Reply-To: <dkp3je5pohqlrxqrbzwd7maxgljr4gknhlmorae6ihi3vx2t4u@z3vvc5ml7vwj>

On Mon, Aug 05, 2024 at 01:48:12PM -0500, Eric Blake wrote:
> On Fri, Aug 02, 2024 at 02:26:04PM GMT, Eric Blake wrote:
> > I've requested a CVE from Red Hat, and hope to have an assigned number
> > soon.  Meanwhile, we can get review started, to make sure this is
> > ready to include in 9.1.  'qemu-img info' should never print untrusted
> > data in a way that might take over a user's terminal.
> > 
> > There are probably other spots where qemu-img info is printing
> > untrusted data (such as filenames), where we probably ought to use the
> > same sanitization tactics as shown here.  Identifying those spots
> > would be a useful part of this review, and may mean a v2 that is even
> > more extensive in the number of patches.
> 
> In fact, should we insist that 'qemu-img info XXX' refuse to accept
> any control characters on any command-line filename, and that it
> reject any backing file name with control characters as a malformed
> qcow2 file?  For reference, we JUST fixed qemu-img info to change
> qcow2 files with a claimed backing file of json:... to favor the local
> file ./json:... over the potentially dangerous user-controlled
> format/protocol description, so we are _already_ changing how strict
> qemu-img is for 9.1, and adding one more restriction to avoid
> escape-sequence madness makes sense.
> 
> Note that with:
> 
> touch $'\e[m' && qemu-img info --output=json $'\e[m'
> 
> we already escape our output, but without --output=json, we are
> vulnerable to user-controlled ESC leaking through to stdout for more
> than just the NBD server errors that I addressed in v1 of this patch
> series.  Hence my question on whether v2 of the series should touch
> more places in the code, and whether doing something like flat-out
> refusing users stupid enough to embed control characters in their
> filenames is a safe change this close to release.

You could say if someone gives you a "malicious" text file which you
cat to stdout, it could change your terminal settings.  I don't think
therefore any of this is very serious.  We should probably fix any
obvious things, but it doesn't need to happen right before 9.1 is
released, we can take our time.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top



  reply	other threads:[~2024-08-05 19:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-02 19:26 [PATCH for-9.1 0/2] NBD: don't print raw server error text to terminal Eric Blake
2024-08-02 19:26 ` [PATCH 1/2] util: Refactor json-writer's string sanitizer to be public Eric Blake
2024-08-02 21:00   ` Richard W.M. Jones
2024-08-02 21:38   ` Philippe Mathieu-Daudé
2024-08-07 18:49   ` Daniel P. Berrangé
2024-08-08  7:57     ` Markus Armbruster
2024-08-08  7:54   ` Markus Armbruster
2024-08-08 14:02     ` Eric Blake
2024-08-02 19:26 ` [PATCH 2/2] qemu-img: CVE-XXX Sanitize untrusted output from NBD server Eric Blake
2024-08-02 21:03   ` Richard W.M. Jones
2024-08-07 18:45     ` Daniel P. Berrangé
2024-08-02 21:41   ` Philippe Mathieu-Daudé
2024-08-07 13:43     ` Stefan Hajnoczi
2024-08-02 22:01   ` Richard W.M. Jones
2024-08-03  8:20     ` Richard W.M. Jones
2024-08-05 18:48 ` [PATCH for-9.1 0/2] NBD: don't print raw server error text to terminal Eric Blake
2024-08-05 19:11   ` Richard W.M. Jones [this message]
2024-08-07 17:51     ` Eric Blake

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=20240805191131.GE1450@redhat.com \
    --to=rjones@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.
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).