As this project doesn't seem to have a dedicated policy or instructions on reporting a potential security issue, I'm left only with a public issue.
Write_Nw_Config_to_DB constructs a file system path using filepath.Join and using a Docker network ID passed to the driver.
Under normal operations, Docker itself passes only network ID strings consisting of hex digits. However, as the Mellanox SR-IOV plugin is an "external" (unmanaged) plugin, any process with sufficient access rights can call the plugin API via its unix socket and inject arbitrary network IDs, such as ../../../../boot/vmlinuz or similar.
As pointed out above, this requires access to the plugin's API socket, which is probably the same as access to Docker's API socket anyway. With access to the Docker API socket, it is already possible to start privileged containers. However, system admins might overlook this potential attack vector as they are acquainted with the docker socket, but not necessarily with plugin sockets.
As this project doesn't seem to have a dedicated policy or instructions on reporting a potential security issue, I'm left only with a public issue.
Write_Nw_Config_to_DB constructs a file system path using
filepath.Joinand using a Docker network ID passed to the driver.Under normal operations, Docker itself passes only network ID strings consisting of hex digits. However, as the Mellanox SR-IOV plugin is an "external" (unmanaged) plugin, any process with sufficient access rights can call the plugin API via its unix socket and inject arbitrary network IDs, such as
../../../../boot/vmlinuzor similar.As pointed out above, this requires access to the plugin's API socket, which is probably the same as access to Docker's API socket anyway. With access to the Docker API socket, it is already possible to start privileged containers. However, system admins might overlook this potential attack vector as they are acquainted with the docker socket, but not necessarily with plugin sockets.
Optional: obligatory XKCD "Exploits of a Mom" reference