|
From: | Eric Blake |
Subject: | Re: [PATCH 1/2] nbd/server: Avoid long error message assertions CVE-2020-10761 |
Date: | Tue, 9 Jun 2020 13:41:24 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 6/8/20 1:26 PM, Eric Blake wrote:
Ever since commit 36683283 (v2.8), the server code asserts that error strings sent to the client are well-formed per the protocol by not exceeding the maximum string length of 4096. At the time the server first started sending error messages, the assertion could not be triggered, because messages were completely under our control. However, over the years, we have added latent scenarios where a client could trigger the server to attempt an error message that would include the client's information if it passed other checks first: - requesting NBD_OPT_INFO/GO on an export name that is not present (commit 0cfae925 in v2.12 echoes the name) - requesting NBD_OPT_LIST/SET_META_CONTEXT on an export name that is not present (commit e7b1948d in v2.12 echoes the name)
Note that this patch does NOT scrub the client's export name for control characters. Then again, the qcow2 file format does not (currently) prohibit control characters in bitmap or internal snapshot names, and 'qemu-img info' blindly outputs there too. We may want to do followup patches that further scrub qemu error messages to avoid scenarios where a user can attempt to coerce qemu into producing an error message containing control characters.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |