I reviewed libblockdev version 2.16-2 as checked into bionic. This should
not be considered a full security audit but rather a quick gauge of
maintainability.
- libblockdev is a plugin-based library to work with block devices,
providing an API based interface that knows how to either perform
underlying operations directly or call the necessary command line
applications as appropriate.
- There are no CVEs in our database
- Build-Depends: debhelper, libtool, dh-python, python3:any, libglib2.0-dev
libgirepository1.0-dev, libcryptsetup-dev libdevmapper-dev libudev-dev
libsystemd-dev, libdmraid-dev, libvolume-key-dev, libbytesize-dev,
libnss3-dev libparted-dev libmount-dev libblkid-dev libpython3-dev,
libkmod-dev gtk-doc-tools, gobject-introspection, pylint
- libblockdev does not itself daemonize
- no networking
- automatically generated pre/post inst/rm scripts
- no initscripts
- no dbus services
- no setuid files
- no executables in PATH
- no sudo fragments
- no udev rules
- There is a test suite; it is not run during the build. I suspect keeping
this test suite disabled is the right approach.
- No cronjobs
- Noisy build logs, primarily from the documentation tools; not ideal, but
at least not much from the code itself
- Several plugins execute helper tools; the glib helpers make the
resulting code fairly complex, but it looks like the executions were
carefully written
- memory management is careful; allocated memory is quickly freed when it
is no longer used to simplify error handling
- normally 'files' being opened are block devices
- Logging functions looked careful
- No environment variable use
- Does not itself do cryptography -- drives LUKS, VeraCrypt, etc via
helpers
- Does not do networking
- Does not use temporary files
- Does not use WebKit
- Does not use PolicyKit
- Does not use JavaScript
- Mostly clean cppcheck results; s390 code has legitimate errors:
[src/plugins/s390.c:293]: (error) Used file that is not opened.
[src/plugins/s390.c:293]: (error) Resource handle 'fd' freed twice.
[src/plugins/s390.c:968]: (error) Resource leak: fd
The s390 code does not feel as mature as the rest of the code base.
I suspect a deeper inspection of the s390 sources would find more issues.
If it can be disabled without significant loss of functionality then I
recommend we disable it.
Security team ACK for promoting libblockdev to main.
Here's some notes I took while reviewing the code, in the hopes that they
are useful:
- bd_s390_dasd_online() double-closes fd, uses fd when it isn't open
- bd_s390_zfcp_offline() leaks fd in rc == EOF branch
- bd_s390_zfcp_online() calls fclose(fd) in a branch when fd is known to
be NULL
- bd_s390_zfcp_scsi_offline() does not check fopen(hba_path, "r") for an
error return
- bd_s390_zfcp_scsi_offline() does not check fopen(wwpn_path, "r") for an
error return
- bd_s390_zfcp_scsi_offline() does not check fopen(lun_path, "r") for an
error return
- bd_crypto_tc_open(), luks_format(), (and other functions) do not zero
out secrets such as passwords. (This is difficult to do; the goal is not
to be perfect, but to try. Simply adding memset_s() calls would be a
step in the right direction.)
- Many routines in src/plugins/crypto.c call strlen(passwd), some other
functions are described as taking binary data in password parameters. Is
there a chance of one interface setting, changing, or removing a
password, that other interfaces cannot work with?
- write_escrow_data_file() writes what looks like a secret key equivalent
to a file but does not itself set a safe umask before doing so.
Thanks
** Changed in: libblockdev (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1735499
Title:
[MIR] libblockdev
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libblockdev/+bug/1735499/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
