similar to: [NBDKIT SECURITY] Denial of Service / Amplification Attack in nbdkit

On 9/12/19 12:41 PM, Richard W.M. Jones wrote: > We have discovered a potential Denial of Service / Amplification Attack > in nbdkit. Unfortunately, our fix for this issue cause another potential Denial of Service attack: > > Lifecycle > --------- > > Reported: 2019-09-11 Fixed: 2019-09-11 Published: 2019-09-12 > > There is no CVE number assigned for this issue

On 9/20/19 8:58 AM, Eric Blake wrote: > On 9/12/19 12:41 PM, Richard W.M. Jones wrote: >> We have discovered a potential Denial of Service / Amplification Attack >> in nbdkit. > > Unfortunately, our fix for this issue cause another potential Denial of > Service attack: > >> >> Lifecycle >> --------- >> >> Reported: 2019-09-11 Fixed:

I'm pleased to announce the releases of libnbd 1.2 and nbdkit 1.16. These are a high performance Network Block Device (NBD) client library and server. Key features of libnbd: * Synchronous API for ease of use. * Asynchronous API for writing non-blocking, multithreaded clients. You can mix both APIs freely. * High performance. * Minimal dependencies for the basic library. *

On 11/15/22 01:46, Eric Blake wrote: > The spec was silent on how many extents a server could reply with. > However, both qemu and nbdkit (the two server implementations known to > have implemented the NBD_CMD_BLOCK_STATUS extension) implement a hard > cap, and will truncate the amount of extents in a reply to avoid > sending a client a reply so large that the client would treat it

There's a denial of service attack possible from guests on any program that does inspection (eg. virt-inspector, many other virt-* tools, virt-v2v, OpenStack). The attack causes the host process to crash because of a double free. It's probably not exploitable (definitely not on Fedora because of the default memory hardening settings). This patch contains the fix and a reproducer:

We discovered a possible Downgrade Attack in libnbd. Lifecycle --------- Reported: 2019-09-14 Fixed: 2019-09-16 Published: 2019-09-16 There is no CVE number assigned for this issue yet, but the bug is being categorized and processed by Red Hat's security team which may result in a CVE being published later. Description ----------- Libnbd includes the method nbd_set_tls(h,

I worked out why valgrind wasn't being applied to nbdkit when run by many of the tests (patches 1-2). Unfortunately I'm not able to make it actually fail tests when valgrind fails. Although the situation is marginally improved in that you can now manually examine the *.log files and find valgrind failures that way. Also adds valgrinding of the Python plugin (patch 3). Along the way I

Hi, I''ve been writing a login application to utilize the features of both PAM and libpwdb. Not surprisingly, this has meant looking at some old code.. The following denial of service attack seems to work quite nicely on my ancient Red Hat 3.0.3 system with the standard login application. Perhaps this is not a problem with 4.0? Does anyone know about other distributions? joe$ nvi

libnbd's copy/copy-nbd-error.sh was triggering an assertion failure in nbdkit: $ nbdcopy -- [ nbdkit --exit-with-parent -v --filter=error pattern 5M error-pread-rate=0.5 ] null: ... nbdkit: pattern.2: debug: error-inject: pread count=262144 offset=4718592 nbdkit: pattern.2: debug: pattern: pread count=262144 offset=4718592 nbdkit: pattern.1: debug: error-inject: pread count=262144

Otherwise, a user can do things like "nbdkit iso . prog='date;prog'" to run unintended commands in addition to their alternative isoprog. This is not a CVE (since nbdkit isn't running with any more privileges than the user running those commands themselves), but shows the frailty of relying on the shell to parse subsidiary commands rather than exec()ing them directly. This

On Mon, Mar 16, 2020 at 10:36:15PM -0500, Eric Blake wrote: > Although nbdkit documents that any positive value should be treated as > success to the .can_* callbacks, we had a window of releases where > anything other than 1 could trigger an assertion failure, fixed in the > previous patch. Update what we return to avoid tripping the bug in > broken nbdkit. > > Our return

On Tue, Mar 17, 2020 at 06:59:09AM -0500, Eric Blake wrote: > On 3/17/20 3:12 AM, Richard W.M. Jones wrote: > >On Mon, Mar 16, 2020 at 10:36:15PM -0500, Eric Blake wrote: > >>Although nbdkit documents that any positive value should be treated as > >>success to the .can_* callbacks, we had a window of releases where > >>anything other than 1 could trigger an

Package: xen-3 Version: 3.1.0-1 Severity: grave Tags: security patch Hi, the following CVE (Common Vulnerabilities & Exposures) id was published for xen-3. CVE-2007-5907[0]: | Xen 3.1.1 does not prevent modification of the CR4 TSC from | applications, which allows pv guests to cause a denial of service | (crash). CVE-2007-5906[1]: | Xen 3.1.1 allows virtual guest system users to cause a |

The docs are a lot more useful with a graphic showing how to wire together nbdkit as a bridge from old-to-new. The converse, bridging new-to-old, is best deferred until I add support for the nbd plugin connecting to a TCP socket. It is also worth mentioning use of nbdkit filters (after all, qemu-nbd 4.0 was able to deprecate its --partition option by pointing to 'nbdkit --filter=partition nbd

I got annoyed by qemu-nbd's default of only allowing a single connection; combine that with nbdkit's nbd plugin, and even 'qemu-nbd --list' of nbdkit counts as the single connection and immediately hangs up. If we introduce a shared mode, then 'qemu-nbd --list' can connect as many times as it wants without killing the original qemu-nbd wrapped by nbdkit. But this in turn

A compliant server should not send NBD_REPLY_TYPE_BLOCK_STATUS unless we successfully negotiated a meta context. And our default strictness settings refuse to let us send NBD_CMD_BLOCK_STATUS unless we negotiated a meta context. But when you mix non-default settings (using nbd_set_strict to disable STRICT_COMMANDS) to send a block status without having negotiated it, coupled with a non-compliant

On systems where python is still set to python2 the check will fail even though it is still completely possible to compile and use nbdkit. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- configure.ac | 2 +- plugins/python/nbdkit-python-plugin.pod | 13 +++++++------ 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/configure.ac

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: Denial of service attack in syslogd Advisory ID: RHSA-1999:055-01 Issue date: 1999-11-19 Updated on: 1999-11-19 Keywords: syslogd sysklogd stream socket Cross references: bugtraq id #809 --------------------------------------------------------------------- 1. Topic: A

nbdkit >= 1.6 ships a VDDK plugin always built, so recommend that version instead of recommending to build nbdkit from sources. --- v2v/virt-v2v-input-vmware.pod | 28 ++-------------------------- 1 file changed, 2 insertions(+), 26 deletions(-) diff --git a/v2v/virt-v2v-input-vmware.pod b/v2v/virt-v2v-input-vmware.pod index 2b6dbaeec..b3ebda182 100644 --- a/v2v/virt-v2v-input-vmware.pod +++

The first one is the nastiest - it is an assertion failure caused by a spec-compliant client and introduced by our security fix that was released in 1.14.1. Eric Blake (4): server: Fix regression for NBD_OPT_INFO before NBD_OPT_GO server: Fix back-to-back SET_META_CONTEXT server: Forbid NUL in export and context names server: Fix OPT_GO on different export than SET_META_CONTEXT