On 12/2/18 10:39 AM, Richard W.M. Jones wrote:
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 found that when we create a TLS session object we
never free it, which is a bit of a problem (although easy to fix -
patch 4).
I'll need to backport this fix to every stable branch. It's not clear
how exploitable this is -- it's my feeling that you'd need to open
millions of TLS sessions which would take forever, and the result
would only be a denial of service as nbdkit runs out of memory and
crashes.
Can the leak happen with merely a port probe, or only by someone that
was able to get past the handshake? If the former, then it is a vehicle
for DoS attacks and probably worth a CVE (because the person performing
the port probe can crash nbdkit from servicing real clients, even though
the attacker does not own TLS credentials); if the latter, it is not a
security bug (no escalation in privilege by locking yourself out).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization:
qemu.org |
libvirt.org