
=====================================================================

                         CERT-Renater

               Note d'Information No. 2021/VULN642
_____________________________________________________________________

DATE                : 07/12/2021

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running runc (go) versions prior to 1.0.3.

=====================================================================
https://github.com/opencontainers/runc/security/advisories/GHSA-v95c-p5hm-xq8f
_____________________________________________________________________


Overflow in netlink bytemsg length field allows attacker to override
netlink-based container configuration

low   cyphar published GHSA-v95c-p5hm-xq8f   Dec 6, 2021

Package
github.com/opencontainers/runc (go)

Affected versions
<1.0.3

Patched versions
1.0.3


Description

Impact

In runc, netlink is used internally as a serialization system for
specifying the relevant container configuration to the C portion of our
code (responsible for the based namespace setup of containers). In all
versions of runc prior to 1.0.3, the encoder did not handle the
possibility of an integer overflow in the 16-bit length field for the
byte array attribute type, meaning that a large enough malicious byte
array attribute could result in the length overflowing and the attribute
contents being parsed as netlink messages for container configuration.

This vulnerability requires the attacker to have some control over the
configuration of the container and would allow the attacker to bypass
the namespace restrictions of the container by simply adding their own
netlink payload which disables all namespaces.

Prior to 9c44407, in practice it was fairly difficult to specify an
arbitrary-length netlink message with most container runtimes. The only
user-controlled byte array was the namespace paths attributes which can
be specified in runc's config.json, but as far as we can tell no
container runtime gives raw access to that configuration setting -- and
having raw access to that setting would allow the attacker to disable
namespace protections entirely anyway (setting them to /proc/1/ns/...
for instance). In addition, each namespace path is limited to 4096 bytes
(with only 7 namespaces supported by runc at the moment) meaning that
even with custom namespace paths it appears an attacker still cannot
shove enough bytes into the netlink bytemsg in order to overflow the
uint16 counter.

However, out of an abundance of caution (given how old this bug is) we
decided to treat it as a potentially exploitable vulnerability with a
low severity. After 9c44407 (which was not present in any release of
runc prior to the discovery of this bug), all mount paths are included
as a giant netlink message which means that this bug becomes
significantly more exploitable in more reasonable threat scenarios.

The main users impacted are those who allow untrusted images with
untrusted configurations to run on their machines (such as with shared
cloud infrastructure), though as mentioned above it appears this bug was
not practically exploitable on any released version of runc to date.


Patches

The patch for this is d72d057 and runc 1.0.3 was released with this bug
fixed.


Workarounds

To the extent this is exploitable, disallowing untrusted namespace paths
in container configuration should eliminate all practical ways of
exploiting this bug. It should be noted that untrusted namespace paths
would allow the attacker to disable namespace protections entirely even
in the absence of this bug.


References

     commit d72d057 ("runc init: avoid netlink message length overflows")
     https://bugs.chromium.org/p/project-zero/issues/detail?id=2241


Credits

Thanks to Felix Wilhelm from Google Project Zero for discovering and
reporting this vulnerability. In particular, the fact they found this
vulnerability so quickly, before we made a 1.1 release of runc (which
would've been vulnerable) was quite impressive.


For more information

If you have any questions or comments about this advisory:

     Open an issue in our repo


CVE ID
CVE-2021-43784

CWEs
CWE-190


Credits

     @felixwilhelm felixwilhelm Felix Wilhelm



=========================================================
+ CERT-RENATER       |    tel : 01-53-94-20-44          +
+ 23/25 Rue Daviel   |    fax : 01-53-94-20-41          +
+ 75013 Paris        |    email:cert@support.renater.fr +
=========================================================

