EulerOS 2.0 SP12 : docker-runc (EulerOS-SA-2026-3331)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
##

include('compat.inc');

if (description)
{
  script_id(343732);
  script_version("1.1");
  script_set_attribute(attribute:"plugin_modification_date", value:"2026/09/08");

  script_cve_id("CVE-2026-41579");

  script_name(english:"EulerOS 2.0 SP12 : docker-runc (EulerOS-SA-2026-3331)");

  script_set_attribute(attribute:"synopsis", value:
"The remote EulerOS host is missing a security update.");
  script_set_attribute(attribute:"description", value:
"According to the versions of the docker-runc package installed, the EulerOS installation on the remote host is affected
by the following vulnerabilities :

    ['This is a PUBLIC release of a low-severity vulnerability in runc which\nhas been fixed in runc 1.3.6,
    runc 1.4.3, and runc 1.5.0-rc.3. There was\nNO EMBARGO WINDOW for this vulnerability, as our analysis was
    that the\nthreat of this issue was not severe and we noticed that a similar issue\nwas publicly fixed in
    crun[1].\n\nBased on our analysis, this vulnerability has a score of 3.3 (Low) with\na CVSSv3 vector of
    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N.\n\n[1]:', '/* Impact */\n\nWhen setting up the container
    rootfs, setupPtmx and setupDevSymlinks\ncall os.Remove and os.Symlink with a filepath.Join string which
    allow an\nimage with /dev as a symlink to trick runc into deleting files called\nptmx on the host or
    creating a hardcoded set of symlinks with specific\nnames and targets in an arbitrary pre-existing host
    directory.\n\nPlease note that this issue is not exploitable under Docker because it\ncreates a top-level
    ro layer that masks any malicious /dev symlink\npresent in the container image (this is also done without
    mounting the\nlower layers so there is no opportunity for the malicious /dev symlink\nto trick it into
    resolving to some other path). Unfortunately, Podman\nand containerd do not do this and so users using
    those higher-level\nruntimes with runc can be exploited via a malicious image.\n\nThis issue mirrors a
    somewhat similar issue in crun, which was also\npublished recently (CVE-2026-47766).\n\n Actually, at
    the time we analysed this issue, containerd had dead code\nthat implemented this feature but the
    implementation contained several\nsecurity issues that would arguably have made it more exploitable
    than\nin runc. Luckily, the code appears to have never been used (at least\nsince 2017) and the code has
    since been removed[2].\n\n[2]:', '/** Mitigating Factors **/\n\nThere are a few mitigating factors about
    this issue which reduce the\nimpact for most users quite significantly, and is the reason why we\ndecided
    to release the fix publicly without an embargo.\n\nWhile the deletion of 'ptmx' seems like a significant
    issue, in practice\nit is quite limited. Notably, devpts does not permit you to unlink\n/dev/pts/ptmx
    regardless of privileges and so it is not a usable target\nfor this attack. Additionally, while /dev/ptmx
    can be unlinked, trying\nto use an image with a symlink from /dev to /dev will cause runc will\nreturn
    an error before it reaches the buggy code (it correctly detects a\nsymlink loop while setting up the mount
    target and the code correctly\nscopes the lookup inside the container). Thus, the only files called\nptmx
    that are guaranteed to exist on the system cannot actually be\nremoved by this bug and so only some user
    file that happens to have that\nspecific name could be deleted, which seems fairly unlikely to happen
    on\nreal systems.\n\nAs for the issue of symlinks, again the impact is likely quite limited.\nWhile the
    creation of arbitrary symlinks could be used to create drop-in\nfiles for system services (and thus lead
    to a container breakout), the\nhardcoded set of symlink names and targets that this bug allows you
    to\ncreate on the host make it quite unlikely that you would be able to do\nmuch more than pollute the
    host system with dummy symlinks. Here is the\ncomplete list of symlinks that can be created with this
    attack:\n\n * core  /proc/kcore\n * fd  /proc/self/fd/\n * ptmx  pts/ptmx\n * stdin  /proc/self/fd/0\n *
    stdout  /proc/self/fd/1\n * stderr  /proc/self/fd/2\n\nNote that none of these symlinks are likely to
    point to user-controlled\ndata -- the /proc/self/fd/$n symlinks are all properties of the
    process\naccessing them (so privileged processes will only see the state they\nwere spawned with) and the
    pts/ptmx symlink is almost certainly in the\nsame privilege scope as the directory the symlink itself is
    in. It seems\nthe only somewhat plausible impact would be that a service could return\nan error when
    trying to parse one of these symlinks and thus treat it as\nan invalid configuration file. How arbitrary
    processes deal with this\nsituation is a bit hard to analyse, but most daemons require\nconfiguration
    files to have certain suffixes (such as .conf) so it\'s not\nreally clear how large the impact is in
    practice and it seems there are\na few barriers to clear to use this to cause a DoS or other
    problems.\n\n This would actually be quite problematic if it could occur because\nglibc seemingly only
    attempts to use /dev/ptmx when creating new\nterminals and thus most terminal managers (including tmux)
    and shell\ntools (including sudo -- but not su) would fail to start and thus bring\nthe system to a halt.
    setupPtmx does add a symlink to /dev/pts/ptmx\nafterwards but on some systems the mode of the host
    /dev/pts/ptmx is set\nto 0o000 which would still cause the same DoS issue.\n\n/* Mitigations */\n\nUsing
    user namespaces restricts this attack fairly significantly such\nthat the attacker can only create/delete
    inodes in directories that the\nremapped root user/group has write access to. Unless the root user
    is\nremapped to an actual user on the host (such as with rootless containers\nthat don\'t use
    '/etc/sub[ug]id'), this in practice means that an\nattacker would only be able to create or delete inodes
    in world-writable\ndirectories.\n\nLSMs can restrict the scope of where in the host filesystem runc can
    be\ntricked into operating on, though how much this helps is questionable.\nThe default
    'container_runtime_t' SELinux label rules (or custom\nAppArmor rules for the host 'runc' context) may
    restrict the scope where\nthese filesystem operations can operate on, but we have not done an\nin-depth
    analysis on the impact of those kinds of LSM protections.\n\n/* Patches */\n\nThis issue has been patched
    in runc 1.3.6, runc 1.4.3, and runc\n1.5.0-rc.3. The patches which resolve this issue on main are:\n\n *
    864db8042dbb ('rootfs: make /dev initialisation code fd-based')\n * 66acd48f9d42 ('rootfs: make cgroupv1
    subsystem symlinks fd-based')\n\nUnfortunately, backporting them to apply cleanly on top of runc
    1.3.5\nand runc 1.4.2 requires quite a few other backports that would bloat the\nset of patches included
    here. It is almost certainly easier for users to\njust update to the latest patch release (which is our
    general\nrecommendation for any security release anyway).\n\n/* Credits */\n\nThanks to 'Davias' for
    initially finding and reporting this issue. The\nsame underlying issue (with varying levels of
    completeness) was later\nreported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu\n(@mosskappa),
    and Derek Manzella (@Dmanzella).\n\n-- \nAleksa Sarai\nFounding Engineer at Amutable'](CVE-2026-41579)

Tenable has extracted the preceding description block directly from the EulerOS docker-runc security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version
number.");
  # https://developer.huaweicloud.com/ict/en/site-euleros/euleros/security-advisories/EulerOS-SA-2026-3331
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?9697cf10");
  script_set_attribute(attribute:"solution", value:
"Update the affected docker-runc packages.");
  script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:N/C:N/I:P/A:N");
  script_set_cvss_temporal_vector("CVSS2#E:U/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:U/RL:O/RC:C");
  script_set_attribute(attribute:"cvss4_vector", value:"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N");
  script_set_attribute(attribute:"cvss4_threat_vector", value:"CVSS:4.0/E:U");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2026-41579");

  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");

  script_set_attribute(attribute:"vuln_publication_date", value:"2026/06/22");
  script_set_attribute(attribute:"patch_publication_date", value:"2026/09/08");
  script_set_attribute(attribute:"plugin_publication_date", value:"2026/09/08");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:huawei:euleros:docker-runc");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:huawei:euleros:2.0");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Huawei Local Security Checks");

  script_copyright(english:"This script is Copyright (C) 2026 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("ssh_get_info.nasl");
  script_require_keys("Host/local_checks_enabled", "Host/cpu", "Host/EulerOS/release", "Host/EulerOS/rpm-list", "Host/EulerOS/sp");
  script_exclude_keys("Host/EulerOS/uvp_version");

  exit(0);
}

include("rpm.inc");

if (!get_kb_item("Host/local_checks_enabled")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);

var _release = get_kb_item("Host/EulerOS/release");
if (isnull(_release) || _release !~ "^EulerOS") audit(AUDIT_OS_NOT, "EulerOS");
var uvp = get_kb_item("Host/EulerOS/uvp_version");
if (_release !~ "^EulerOS release 2\.0(\D|$)") audit(AUDIT_OS_NOT, "EulerOS 2.0 SP12");

var sp = get_kb_item("Host/EulerOS/sp");
if (isnull(sp) || sp !~ "^(12)$") audit(AUDIT_OS_NOT, "EulerOS 2.0 SP12");

if (!empty_or_null(uvp)) audit(AUDIT_OS_NOT, "EulerOS 2.0 SP12", "EulerOS UVP " + uvp);

if (!get_kb_item("Host/EulerOS/rpm-list")) audit(AUDIT_PACKAGE_LIST_MISSING);

var cpu = get_kb_item("Host/cpu");
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ("x86_64" >!< cpu && cpu !~ "^i[3-6]86$" && "aarch64" >!< cpu && "x86" >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, "EulerOS", cpu);
if ("aarch64" >!< cpu) audit(AUDIT_ARCH_NOT, "aarch64", cpu);

var flag = 0;

var pkgs = [
  "docker-runc-1.1.3-9.h35.eulerosv2r12"
];

foreach (var pkg in pkgs)
  if (rpm_check(release:"EulerOS-2.0", sp:"12", reference:pkg)) flag++;

if (flag)
{
  security_report_v4(
    port       : 0,
    severity   : SECURITY_NOTE,
    extra      : rpm_report_get()
  );
  exit(0);
}
else
{
  var tested = pkg_tests_get();
  if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
  else audit(AUDIT_PACKAGE_NOT_INSTALLED, "docker-runc");
}