[PATCH nbdkit v4] tests: Remove $libdir from LD_PRELOAD arg
by Richard W.M. Jones
It turns out that LD_PRELOAD already searches the path and that's
going to be far more reliable than using $libdir.
Fixes: commit 8972831aa2a32d4b5820465d37c1827eb76450e4
Fixes: commit 362e0fdcae37db876e13b944102a5c152e6bc563
---
tests/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 35b2e4a6..f8af70c5 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -76,7 +76,7 @@ TESTS_ENVIRONMENT = \
random = $(shell bash -c 'echo $$(( 1 + (RANDOM & 255) ))')
if HAVE_GLIBC_234
TESTS_ENVIRONMENT += \
- LD_PRELOAD="$${LD_PRELOAD:+"$$LD_PRELOAD:"}$(libdir)/libc_malloc_debug.so.0" \
+ LD_PRELOAD="$${LD_PRELOAD:+"$$LD_PRELOAD:"}libc_malloc_debug.so.0" \
GLIBC_TUNABLES=glibc.malloc.check=1:glibc.malloc.perturb=$(random) \
$(NULL)
else
--
2.32.0
3 years, 3 months
[PATCH nbdkit v3] tests: Improve test for libc_malloc_debug
by Richard W.M. Jones
Previous commits tried to add support for new glibc 2.34 feature
libc_malloc_debug by checking for the specific version of glibc.
However this risks setting LD_PRELOAD to a non-existent path (eg. if
the user does not specify any ./configure --prefix which results in
setting LD_PRELOAD=/usr/local/lib/libc_malloc_debug.so.0).
While LD_PRELOAD normally just warns (noisily) if it cannot find the
library, the warning causes some tests to fail. In any case it's
better not to set LD_PRELOAD at all in this case.
Instead let's test for the presence of libc_malloc_debug on the
provided --prefix or --libdir path in ./configure, and then use that
to enable the LD_PRELOAD stuff.
Fixes: commit 8972831aa2a32d4b5820465d37c1827eb76450e4
Fixes: commit 362e0fdcae37db876e13b944102a5c152e6bc563
---
configure.ac | 31 ++++++++++++++++++++-----------
tests/Makefile.am | 4 ++--
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/configure.ac b/configure.ac
index ea13c75c..0e4c4a28 100644
--- a/configure.ac
+++ b/configure.ac
@@ -569,17 +569,26 @@ AS_IF([test "x$is_windows" = "xyes"],[
AC_SEARCH_LIBS([getaddrinfo], [network socket])
-dnl Does this platform require libc_malloc_debug.so.0 (glibc >= 2.34)?
-AC_MSG_CHECKING([if this is glibc >= 2.34])
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
-#include <limits.h>
-#if !defined(__GLIBC__) || __GLIBC__ < 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 34)
-#error "not glibc 2.34"
-#endif
- ]])], [is_glibc_234=yes], [is_glibc_234=no]
-)
-AC_MSG_RESULT([$is_glibc_234])
-AM_CONDITIONAL([HAVE_GLIBC_234], [test "x$is_glibc_234" = "xyes"])
+dnl Does this platform have $libdir/libc_malloc_debug.so.0 (glibc >=
+dnl 2.34)? We have to override the idiotic exec_prefix misfeature to
+dnl get to the real libdir.
+real_libdir="$(
+ if test "x$prefix" != xNONE; then
+ exec_prefix="$prefix"
+ else
+ exec_prefix="$ac_default_prefix"
+ fi
+ eval echo $libdir
+)"
+LIBC_MALLOC_DEBUG="$real_libdir/libc_malloc_debug.so.0"
+AC_MSG_CHECKING([for $LIBC_MALLOC_DEBUG])
+AS_IF([test -r $LIBC_MALLOC_DEBUG], [
+ have_libc_malloc_debug=yes
+ AC_SUBST([LIBC_MALLOC_DEBUG])
+],[have_libc_malloc_debug=no])
+AC_MSG_RESULT([$have_libc_malloc_debug])
+AM_CONDITIONAL([HAVE_LIBC_MALLOC_DEBUG],
+ [test "x$have_libc_malloc_debug" = xyes])
dnl Check for SELinux socket labelling (optional).
PKG_CHECK_MODULES([LIBSELINUX], [libselinux], [
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 35b2e4a6..109853ea 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -74,9 +74,9 @@ TESTS_ENVIRONMENT = \
# uninitialized read problems when using glibc, and doesn't affect
# normal operation or other libc.
random = $(shell bash -c 'echo $$(( 1 + (RANDOM & 255) ))')
-if HAVE_GLIBC_234
+if HAVE_LIBC_MALLOC_DEBUG
TESTS_ENVIRONMENT += \
- LD_PRELOAD="$${LD_PRELOAD:+"$$LD_PRELOAD:"}$(libdir)/libc_malloc_debug.so.0" \
+ LD_PRELOAD="$${LD_PRELOAD:+"$$LD_PRELOAD:"}$(LIBC_MALLOC_DEBUG)" \
GLIBC_TUNABLES=glibc.malloc.check=1:glibc.malloc.perturb=$(random) \
$(NULL)
else
--
2.32.0
3 years, 3 months
Better sparse random?
by Abhay Raj Singh
We can use machine learning/statistics in plugins to generate more
'real; disk images/extents. Currently, sparse-random is the go-to
test. I think we can leverage ML/statistics for more true-to-life disk
images hence more accurate benchmarks. These will expose factors that
are more relevant for real systems. Generative Adversarial
Networks(GANs) might be useful.
However, we will need info about real images to first train the generator.
Regards
Abhay
3 years, 3 months
[PATCH nbdkit] tests: Invoke MALLOC_CHECK_ correctly and only for glibc
by Richard W.M. Jones
This is kind of horrible, but it seems to work and I can't currently
think of any better way ...
I verified that it does actually set the right environment variables
and invoke the malloc checking behaviour in glibc 2.34. I didn't test
it yet with glibc < 2.34 or !glibc.
Rich.
3 years, 3 months
[libnbd PATCH] ci: Do not run valgrind checks
by Martin Kletzander
Since valgrind checks find unrelated issues it spoils the CI effort and makes us
ignore the output in the long run. If we want we can turn on valgrind checks
for one or two particular platforms by setting "CHECK_VALGRIND" to "force".
Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
---
.gitlab-ci.yml | 3 ---
ci/build.sh | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 60c8097d32bc..22e732b184d9 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -249,7 +249,6 @@ x64-opensuse-leap-152:
- x64-opensuse-leap-152-container
variables:
NAME: opensuse-leap-152
- CHECK_VALGRIND: skip
x64-opensuse-tumbleweed:
extends: .native_build_job
@@ -257,7 +256,6 @@ x64-opensuse-tumbleweed:
- x64-opensuse-tumbleweed-container
variables:
NAME: opensuse-tumbleweed
- CHECK_VALGRIND: skip
x64-ubuntu-1804:
extends: .native_build_job
@@ -273,7 +271,6 @@ x64-ubuntu-2004:
- x64-ubuntu-2004-container
variables:
NAME: ubuntu-2004
- CHECK_VALGRIND: skip
x64-freebsd-12-build:
extends: .cirrus_build_job
diff --git a/ci/build.sh b/ci/build.sh
index 2811fc4535f2..8ee4a87ea9b7 100755
--- a/ci/build.sh
+++ b/ci/build.sh
@@ -103,7 +103,7 @@ main() {
run_checks check
- if test "$CHECK_VALGRIND" != "skip"
+ if test "$CHECK_VALGRIND" = "force"
then
run_checks check-valgrind
fi
--
2.32.0
3 years, 3 months
[PATCH] launch: board model for RISC-V
by Heinrich Schuchardt
On RISC-V there is no default machine type. Invoking QEMU requires to
specify a board model with the -M option. So let's define MACHINE_TYPE
as virt.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com>
---
lib/guestfs-internal.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h
index b3f887935..4097b33fd 100644
--- a/lib/guestfs-internal.h
+++ b/lib/guestfs-internal.h
@@ -157,6 +157,9 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr)
#ifdef __powerpc__
#define MACHINE_TYPE "pseries"
#endif
+#ifdef __riscv
+#define MACHINE_TYPE "virt"
+#endif
/* Differences in qemu device names on ARMv7 (virtio-mmio), s/390x
* (CCW) vs normal hardware with PCI.
--
2.32.0
3 years, 3 months
[NBDKIT SECURITY] STARTTLS denial-of-service weakness
by Eric Blake
We have discovered a potential Denial of Service Attack in nbdkit,
when using opportunistic TLS.
Lifecycle
---------
Reported: 2021-08-12 Fixed: 2021-08-18 Published: 2021-08-18
This has been assigned CVE-2021-3716.
Credit
------
Reported and patched by Eric Blake <eblake(a)redhat.com>.
Reviewed by Rich Jones <rjones(a)redhat.com>.
Description
-----------
nbdkit is a Network Block Device (NBD) server with multiple plugins,
and includes the ability to do opportunistic (--tls=yes) or forced
(--tls=require) encryption.
While the NBD protocol already documents the risk of using
opportunistic mode [1] (because neither the client nor the server can
detect a meddler-in-the-middle [MitM] downgrade attack) and recommends
forced TLS mode if downgrade attacks must be prevented, until
recently, it had not considered other potential MitM effects beyond
trivial modification of NBD_OPT_STARTTLS requests.
[1] https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md#securi...
An attacker can proxy all traffic between a client and server, and can
inject plaintext commands to the server prior to the point that the
client requests the transition to TLS with NBD_OPT_STARTTLS. By
injecting a request for NBD_OPT_STRUCTURED_REPLY before encryption is
started, the attacker will cause affected nbdkit versions in
opportunistic TLS mode to send structured reply traffic during the
encrypted session, thereby confusing a client that is unprepared for
structured replies, even though both the client and the server assume
that the connection is now safe from a MitM attack because the TLS
request succeeded. Depending on how the client handles unexpected
structured replies, the attacker can use this to form a denial of
service attack on the client, distinct from a trivial protocol
downgrade attack.
Mitigating this is the fact that the attack is not possible if nbdkit
is in forced TLS mode (--tls=require); and the NBD protocol already
recommends using forced TLS in scenarios that want to protect against
a MitM attack. Furthermore, a client that requests structured replies
after encryption is enabled is not impacted (this includes qemu 2.12
and newer, and all versions of libnbd); the denial of service only
occurs with TLS clients that do not understand structured replies
(this includes qemu 2.8 through 2.11, and nbd-client 3.15 through the
present).
Similarly, it is possible to prevent the attack by arranging clients
and servers to use a trusted network (for example, using nbdkit -U for
a local Unix socket, rather than exposing the connection over TCP).
Fixed versions of nbdkit ensure that the NBD_OPT_STARTTLS command now
restores all server state back to the same settings as the original
new client session, so that a client is guaranteed that once
encryption is started, the only way to change the protocol sent over
the wire is via subsequent changes triggered by encrypted negotiation
between the client and server, without interference from a MitM
attacker.
Test if nbdkit is a vulnerable version
--------------------------------------
At this time, there are no known readily-available open source clients
which allow easy injection of NBD_OPT_STRUCTURED_REPLY prior to
NBD_OPT_STARTTLS, thus no easy way to test for the vulnerability other
than creating a custom client.
Workarounds
-----------
In general, it is recommended to use forced tls (--tls=require) to
avoid MitM attacks in the first place. But if opportunistic
encryption must be used (--tls=yes), it is recommended to upgrade to a
fixed version of nbdkit, or to ensure that clients that want to use
TLS will request structured replies after the encryption is enabled.
If this cannot be done, apply network filtering (eg. firewall, TCP
wrappers, etc.) or use a Unix domain socket instead of TCP to ensure
that untrusted clients cannot connect to nbdkit as a MitM attacker.
Fixes
-----
This affects all nbdkit versions 1.12 through 1.26.4, as well as
development versions through 1.27.5. A fix is available for the
current development branch, and a followup email will give commit ids
for each stable branch where the fix has been backported.
https://listman.redhat.com/archives/libguestfs/2021-August/msg00077.html
* development branch (1.27)
use nbdkit >= 1.27.6 from
http://download.libguestfs.org/nbdkit/1.15-development/
* stable branch 1.26
use nbdkit >= 1.26.5 from
http://download.libguestfs.org/nbdkit/1.26-stable/
* stable branch 1.24
use nbdkit >= 1.24.6 from
http://download.libguestfs.org/nbdkit/1.24-stable/
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
3 years, 3 months
[PATCH] docs: Link to protocol security considerations in uri docs
by Eric Blake
Especially useful in light of the recent publishing of
https://nostarttls.secvuln.info/, which documents a variety of
implementations vulnerable to downgrade attacks in SMTP and IMAP, as
well as its caution that that any protocol with a STARTTLS operation
(which includes NBD) needs to be aware of the potential downgrade
attacks.
The NBD protocol documentation already covers what is necessary to
avoid the effects of a downgrade attack, and all known implementations
of NBD servers and clients with working NBD_OPT_STARTTLS have at least
one mode where TLS is mandatory rather than opportunistic. So I don't
see this as a CVE against the NBD protocol itself, so much as a worry
about the potential for future poor implementations that disregard the
documentation.
---
I'm likely to push this to the NBD spec later this week if it doesn't
receive any reviews beforehand.
doc/uri.md | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/uri.md b/doc/uri.md
index 925ad4b..28aa94d 100644
--- a/doc/uri.md
+++ b/doc/uri.md
@@ -73,6 +73,12 @@ One of the following scheme names SHOULD be used to indicate an NBD URI:
Other URI scheme names MAY be used but not all NBD clients will
understand them or even recognize that they refer to NBD.
+Note that using opportunistically encrypted connections (via the `nbd`
+or `nbd+unix` scheme) risks a protocol downgrade attack; whereas
+requests for a secure connection (via the `nbds` or `nbds+unix`
+scheme) MUST use TLS to connect. For more details, see
+<https://github.com/NetworkBlockDevice/nbd/blob/master/doc/proto.md#securi...>
+
## NBD URI authority
The authority field SHOULD be used for TCP/IP connections and SHOULD
--
2.31.1
3 years, 3 months
[nbdkit PATCH] server: CVE-2021-???? reset structured replies on starttls
by Eric Blake
https://nostarttls.secvuln.info/ pointed out a common implementation
flaw in various SMTP and IMAP servers with regards to improperly
caching plaintext state across the STARTTLS encryption boundary. It
turns out that nbdkit has the same vulnerability in regards to the NBD
protocol: an attacker is able to inject a plaintext
NBD_OPT_STRUCTURED_REPLY before proxying everything else a client
sends to the server; if the server then acts on that plaintext request
(as nbdkit did before this patch), then the server ends up sending
structured replies to at least NBD_CMD_READ, even though the client
was not expecting them. The NBD spec has been recently tightened to
declare the nbdkit behavior to be a security hole.
---
[NB: I'm still in the process of getting a CVE assigned; there is no
embargo since the issue is already public, but I may wait to apply
this patch until the commit message can be tweaked]
---
server/protocol-handshake-newstyle.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/server/protocol-handshake-newstyle.c b/server/protocol-handshake-newstyle.c
index a2c89c9a..7e6b7b1b 100644
--- a/server/protocol-handshake-newstyle.c
+++ b/server/protocol-handshake-newstyle.c
@@ -495,7 +495,8 @@ negotiate_handshake_newstyle_options (void)
return -1;
conn->using_tls = true;
debug ("using TLS on this connection");
- /* Wipe out any cached default export name. */
+ /* Wipe out any cached state. */
+ conn->structured_replies = false;
for_each_backend (b) {
free (conn->default_exportname[b->i]);
conn->default_exportname[b->i] = NULL;
--
2.31.1
3 years, 3 months
