Hello, I reviewed rdma-core version 16.0-1 as checked into bionic. This
isn't a full security audit but rather a quick gauge of maintainability.
- CVE history is a bit hard to look for, since this source package is
quite new and composed of many previous source packages.
Which source packages do we get to delete as a result of this
new package?
- rdma-core provides drivers, libraries, preloadable shims, example
programs, and probably real useful utilities for high-end networking
cards.
- Build-Depends: cmake, debhelper, dpkg-dev, libnl-3-dev, libnl-route-3-dev,
libsystemd-dev, libudev-dev, ninja-build, pkg-config, python, valgrind
- services unknown, I didn't spend enough time to investigate
- pre/post inst/rm scripts mostly automatically generated except for
creating an rdma group, trigger udevadm rules
- systemd service files look normal enough, rdma-load-modules*.service
will load modules, I'm surprised /etc/modules.d/ doesn't suffice
- No dbus
- No setuid
- Many executable files:
ibacm_16.0-1_amd64.deb
/usr/bin/ib_acme
/usr/sbin/ibacm
ibverbs-utils_16.0-1_amd64.deb
/usr/bin/ibv_asyncwatch
/usr/bin/ibv_devices
/usr/bin/ibv_devinfo
/usr/bin/ibv_rc_pingpong
/usr/bin/ibv_srq_pingpong
/usr/bin/ibv_uc_pingpong
/usr/bin/ibv_ud_pingpong
/usr/bin/ibv_xsrq_pingpong
rdmacm-utils_16.0-1_amd64.deb
/usr/bin/cmtime
/usr/bin/mckey
/usr/bin/rcopy
/usr/bin/rdma_client
/usr/bin/rdma_server
/usr/bin/rdma_xclient
/usr/bin/rdma_xserver
/usr/bin/riostream
/usr/bin/rping
/usr/bin/rstream
/usr/bin/ucmatose
/usr/bin/udaddy
/usr/bin/udpong
rdma-core_16.0-1_amd64.deb
/usr/bin/rxe_cfg
/usr/sbin/iwpmd
/usr/sbin/rdma-ndd
srptools_16.0-1_amd64.deb
/usr/sbin/srp_daemon
/usr/sbin/ibsrpdm -> srp_daemon
- No sudo fragments
- Most intricate udev files I've seen in a while
- I didn't spot any test suites run during the build
- One instance of popen(), seemed fine
- Extensive memory manipulation; cppcheck found some errors (scanf, realloc
looked real; everything with resp is false-positives)
- extensive file operations, including reading commands as part of
LD_PRELOAD files for configuration of networking. There were some
low-risk stack buffer overflow possibilities in some of the filenames
generated based on inputs.
- extensive environment variable reading; sometimes parsed, sometimes just
the presence of a variable is enough. Sometimes used to determine paths
for future dlopen(3) calls.
- extensive logging, spot checks looked safe.
- No cryptography
- Extensive networking
- I didn't notice privileged portions of processes
- No WebKit
- No PolicyKit
- No JavaScript
- cppcheck reports a lot, mostly false positives unique to this project,
but some deserve further inspection
Possible issues:
- The xsrq_pingpong.c example has an unsafe /tmp/xrc_domain file use. This
may need a CVE.
- librdmacm/preload.c fds_alloc() integer overflow in memory allocation if
nfds is too large, suggest calloc() instead to handle this case properly
- librdmacm/rsocket.c rs_fds_alloc() integer overflow in memory allocation if
nfds is too large, suggest calloc() instead to handle this case properly
- providers/hns/hns_roce_u_verbs.c hns_roce_u_alloc_pd()
calls ibv_cmd_alloc_pd() with &resp.ibv_resp, sizeof(resp)
^^ 4B ^^ ^^^ 12B ^^^
- providers/mthca/qp.c mthca_tavor_post_send()
f0 and op0 appear to be able to be used uninitialized -- they are
assigned in the !size0 case but !size0 is not consulted before
using them
- providers/mthca/qp.c mthca_arbel_post_send()
f0 and op0 appear to be able to be used uninitialized -- they are
assigned in the !size0 case but !size0 is not consulted before
using them
- libibverbs/verbs.c ibv_query_gid_type() may have stack buffer
overflow if portnum and index have over eight characters in their
decimal representations together. What are the input limits on these
variables? Consider asprintf() instead.
- iwpmd/iwarp_pm_server.c iwarp_port_mapper() does not handle return value
from process_iwpm_msg(), process_iwpm_netlink_msg() functions
- ./libibumad/sysfs.c sys_read_string() possible stack buffer overflow
if dir_name and file_name parameters are too long. Consider asprintf()
instead.
- ./ibacm/src/acm_util.c acm_if_is_ib() acm_if_get_pkey() acm_if_get_sgid()
these functions construct funny filenames
//sys//class//net//%s//address
//sys//class//net//%s//pkey
//sys//class//net//%s//type
Even though the kernel will collapse these to
//sys/class/net/%s/address
//sys/class/net/%s/pkey
//sys/class/net/%s/type
as part of opening the files, it's surprising, weird, and the leading
double slashes may work differently in the future. I recommend modifying
these to usual Unix convention of single slashes between pathname
components.
- ./providers/mlx5/buf.c mlx5_get_alloc_type(), mlx5_alloc_get_env_info(),
more, may write a truncated string into the name[128] buffer, if the
input parameter component is too long. Consider asprintf() instead.
rdma-core is extremely complicated; we will be almost entirely reliant
upon upstream assistance in preparing updates. The overall code quality is
quite good and the list of possible issues above feels about par for this
much highly-intricate high-performance software.
I'd strongly like to keep ibverbs-utils and rdmacm-utils in universe:
these look a lot like the 'example' sources that I did not inspect very
closely. At least ibv_xsrq_pingpong's use of a temporary file would
deserve a CVE if this tool is widely deployed. (If it's just a source
example then that's fine. The bar is quite low for such tools. But if it's
on user machines then it deserves to be held to a higher standard.) Thus
I'd like the -utils packages to be in universe unless there is a
compelling reason to promote them.
Security team ACK for promoting rdma-core to main.
Thanks
** Changed in: rdma-core (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/1732892
Title:
[MIR] 18.04 rdma-core as replacement for older ibverbs code
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rdma-core/+bug/1732892/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
