Common Weakness Enumeration

CWE-362

Allowed-with-Review

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Abstraction: Class · Status: Draft

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

2926 vulnerabilities reference this CWE, most recent first.

GHSA-C3XM-PVG7-GH7R

Vulnerability from github – Published: 2021-05-25 18:44 – Updated: 2021-05-21 19:34
VLAI
Summary
mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs
Details

Summary

runc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby an attacker can request a seemingly-innocuous container configuration that actually results in the host filesystem being bind-mounted into the container (allowing for a container escape). CVE-2021-30465 has been assigned for this issue.

An attacker must have the ability to start containers using some kind of custom volume configuration, and while recommended container hardening mechanisms such as LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of damage an attacker could do, they do not block this attack outright. We have a reproducer using Kubernetes (and the below description mentions Kubernetes-specific paths), but this is not a Kubernetes-specific issue.

The now-released runc v1.0.0-rc95 contains a fix for this issue, we recommend users update as soon as possible.

Details

In circumstances where a container is being started, and runc is mounting inside a volume shared with another container (which is conducting a symlink-exchange attack), runc can be tricked into mounting outside of the container rootfs by swapping the target of a mount with a symlink due to a time-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to previous TOCTTOU attacks (and is a problem we are working on solving with libpathrs).

However, this alone is not useful because this happens inside a mount namespace with MS_SLAVE propagation applied to / (meaning that the mount doesn't appear on the host -- it's only a "host-side mount" inside the container's namespace). To exploit this, you must have additional mount entries in the configuration that use some subpath of the mounted-over host path as a source for a subsequent mount.

However, it turns out with some container orchestrators (such as Kubernetes -- though it is very likely that other downstream users of runc could have similar behaviour be accessible to untrusted users), the existence of additional volume management infrastructure allows this attack to be applied to gain access to the host filesystem without requiring the attacker to have completely arbitrary control over container configuration.

In the case of Kubernetes, this is exploitable by creating a symlink in a volume to the top-level (well-known) directory where volumes are sourced from (for instance, /var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir), and then using that symlink as the target of a mount. The source of the mount is an attacker controlled directory, and thus the source directory from which subsequent mounts will occur is an attacker-controlled directory. Thus the attacker can first place a symlink to / in their malicious source directory with the name of a volume, and a subsequent mount in the container will bind-mount / into the container.

Applying this attack requires the attacker to start containers with a slightly peculiar volume configuration (though not explicitly malicious-looking such as bind-mounting / into the container explicitly), and be able to run malicious code in a container that shares volumes with said volume configuration. It helps the attacker if the host paths used for volume management are well known, though this is not a hard requirement.

Patches

This has been patched in runc 1.0.0-rc95, and users should upgrade as soon as possible. The patch itself can be found here.

Workarounds

There are no known workarounds for this issue.

However, users who enforce running containers with more confined security profiles (such as reduced capabilities, not running code as root in the container, user namespaces, AppArmor/SELinux, and seccomp) will restrict what an attacker can do in the case of a container breakout -- we recommend users make use of strict security profiles if possible (most notably user namespaces -- which can massively restrict the impact a container breakout can have on the host system).

References

Credit

Thanks to Etienne Champetier for discovering and disclosing this vulnerability, to Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp for testing it.

For more information

If you have any questions or comments about this advisory: * Open an issue in our issue tracker. * Email us at security@opencontainers.org.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-rc94"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-rc95"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-30465"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-362",
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-21T19:34:43Z",
    "nvd_published_at": "2021-05-27T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nrunc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby\nan attacker can request a seemingly-innocuous container configuration that\nactually results in the host filesystem being bind-mounted into the container\n(allowing for a container escape). CVE-2021-30465 has been assigned for this\nissue.\n\nAn attacker must have the ability to start containers using some kind of custom\nvolume configuration, and while recommended container hardening mechanisms such\nas LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of\ndamage an attacker could do, they do not block this attack outright. We have a\nreproducer using Kubernetes (and the below description mentions\nKubernetes-specific paths), but this is not a Kubernetes-specific issue.\n\nThe now-released [runc v1.0.0-rc95][release] contains a fix for this issue, we\nrecommend users update as soon as possible.\n\n[release]: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95\n\n### Details\n\nIn circumstances where a container is being started, and runc is mounting\ninside a volume shared with another container (which is conducting a\nsymlink-exchange attack), runc can be tricked into mounting outside of the\ncontainer rootfs by swapping the target of a mount with a symlink due to a\ntime-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to\nprevious TOCTTOU attacks (and is a problem we are working on solving with\nlibpathrs).\n\nHowever, this alone is not useful because this happens inside a mount namespace\nwith `MS_SLAVE` propagation applied to `/` (meaning that the mount doesn\u0027t\nappear on the host -- it\u0027s only a \"host-side mount\" inside the container\u0027s\nnamespace). To exploit this, you must have additional mount entries in the\nconfiguration that use some subpath of the mounted-over host path as a source\nfor a subsequent mount.\n\nHowever, it turns out with some container orchestrators (such as Kubernetes --\nthough it is very likely that other downstream users of runc could have similar\nbehaviour be accessible to untrusted users), the existence of additional volume\nmanagement infrastructure allows this attack to be applied to gain access to\nthe host filesystem without requiring the attacker to have completely arbitrary\ncontrol over container configuration.\n\nIn the case of Kubernetes, this is exploitable by creating a symlink in a\nvolume to the top-level (well-known) directory where volumes are sourced from\n(for instance,\n`/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir`), and then\nusing that symlink as the target of a mount. The source of the mount is an\nattacker controlled directory, and thus the source directory from which\nsubsequent mounts will occur is an attacker-controlled directory. Thus the\nattacker can first place a symlink to `/` in their malicious source directory\nwith the name of a volume, and a subsequent mount in the container will\nbind-mount `/` into the container.\n\nApplying this attack requires the attacker to start containers with a slightly\npeculiar volume configuration (though not explicitly malicious-looking such as\nbind-mounting `/` into the container explicitly), and be able to run malicious\ncode in a container that shares volumes with said volume configuration. It\nhelps the attacker if the host paths used for volume management are well known,\nthough this is not a hard requirement.\n\n### Patches\nThis has been patched in runc 1.0.0-rc95, and users should upgrade as soon as\npossible. The patch itself can be found [here](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f).\n\n### Workarounds\n\nThere are no known workarounds for this issue.\n\nHowever, users who enforce running containers with more confined security\nprofiles (such as reduced capabilities, not running code as root in the\ncontainer, user namespaces, AppArmor/SELinux, and seccomp) will restrict what\nan attacker can do in the case of a container breakout -- we recommend users\nmake use of strict security profiles if possible (most notably user namespaces\n-- which can massively restrict the impact a container breakout can have on the\nhost system).\n\n### References\n* [commit](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f)\n* [seclists public disclosure](https://www.openwall.com/lists/oss-security/2021/05/19/2)\n\n### Credit\n\nThanks to Etienne Champetier for discovering and disclosing this vulnerability,\nto Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp\nfor testing it.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [our issue tracker](https://github.com/opencontainers/runc/issues).\n* Email us at \u003csecurity@opencontainers.org\u003e.",
  "id": "GHSA-c3xm-pvg7-gh7r",
  "modified": "2021-05-21T19:34:43Z",
  "published": "2021-05-25T18:44:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30465"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.opensuse.org/show_bug.cgi?id=1185405"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/releases"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00023.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/35ZW6NBZSBH5PWIT7JU4HXOXGFVDCOHH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4HOARVIT47RULTTFWAU7XBG4WY6TDDHV"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-26"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210708-0003"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/05/19/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs"
}

GHSA-C433-Q7CJ-FW94

Vulnerability from github – Published: 2022-05-14 01:19 – Updated: 2022-05-14 01:19
VLAI
Details

An issue was discovered in CapMon Access Manager 5.4.1.1005. CALRunElevated.exe attempts to enforce access control by adding an unprivileged user to the local Administrators group for a very short time to execute a single command. However, the user is left in that group if the command crashes, and there is also a race condition in all cases.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-18253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-15T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in CapMon Access Manager 5.4.1.1005. CALRunElevated.exe attempts to enforce access control by adding an unprivileged user to the local Administrators group for a very short time to execute a single command. However, the user is left in that group if the command crashes, and there is also a race condition in all cases.",
  "id": "GHSA-c433-q7cj-fw94",
  "modified": "2022-05-14T01:19:57Z",
  "published": "2022-05-14T01:19:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18253"
    },
    {
      "type": "WEB",
      "url": "https://improsec.com/tech-blog/cam1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C438-4XF4-29GX

Vulnerability from github – Published: 2022-01-12 00:00 – Updated: 2024-11-14 21:31
VLAI
Details

Windows DWM Core Library Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-21852, CVE-2022-21902.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-21896"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-11T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Windows DWM Core Library Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-21852, CVE-2022-21902.",
  "id": "GHSA-c438-4xf4-29gx",
  "modified": "2024-11-14T21:31:49Z",
  "published": "2022-01-12T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21896"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21896"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-21896"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4C9-RWVW-5WRF

Vulnerability from github – Published: 2024-02-05 09:30 – Updated: 2024-02-10 06:30
VLAI
Details

A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-22386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-05T08:15:43Z",
    "severity": "MODERATE"
  },
  "details": "A race condition was found in the Linux kernel\u0027s drm/exynos device driver in\u00a0exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\n\n\n",
  "id": "GHSA-c4c9-rwvw-5wrf",
  "modified": "2024-02-10T06:30:18Z",
  "published": "2024-02-05T09:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22386"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.openanolis.cn/show_bug.cgi?id=8147"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4CM-M6VC-3XVQ

Vulnerability from github – Published: 2024-12-12 03:33 – Updated: 2024-12-12 03:33
VLAI
Details

Windows Remote Desktop Services Remote Code Execution Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-12T02:04:38Z",
    "severity": "HIGH"
  },
  "details": "Windows Remote Desktop Services Remote Code Execution Vulnerability",
  "id": "GHSA-c4cm-m6vc-3xvq",
  "modified": "2024-12-12T03:33:05Z",
  "published": "2024-12-12T03:33:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49116"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49116"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4F3-Q22X-8756

Vulnerability from github – Published: 2022-05-17 04:52 – Updated: 2022-05-17 04:52
VLAI
Details

Race condition in the cut-through proxy feature in Cisco Firewall Services Module (FWSM) Software 3.x before 3.2(28) and 4.x before 4.1(15) allows remote attackers to cause a denial of service (device reload) via certain matching traffic, aka Bug ID CSCuj16824.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-0710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-02-22T21:55:00Z",
    "severity": "HIGH"
  },
  "details": "Race condition in the cut-through proxy feature in Cisco Firewall Services Module (FWSM) Software 3.x before 3.2(28) and 4.x before 4.1(15) allows remote attackers to cause a denial of service (device reload) via certain matching traffic, aka Bug ID CSCuj16824.",
  "id": "GHSA-c4f3-q22x-8756",
  "modified": "2022-05-17T04:52:07Z",
  "published": "2022-05-17T04:52:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-0710"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140219-fwsm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C4MH-7455-PVXV

Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2024-10-17 21:31
VLAI
Details

Race condition in the kernel in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, Windows 7 Gold and SP1, Windows 8, Windows Server 2012, and Windows RT allows local users to gain privileges via a crafted application that leverages incorrect handling of objects in memory, aka "Kernel Race Condition Vulnerability," a different vulnerability than CVE-2013-1279.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-1278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-02-13T12:04:00Z",
    "severity": "HIGH"
  },
  "details": "Race condition in the kernel in Microsoft Windows XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2, R2, and R2 SP1, Windows 7 Gold and SP1, Windows 8, Windows Server 2012, and Windows RT allows local users to gain privileges via a crafted application that leverages incorrect handling of objects in memory, aka \"Kernel Race Condition Vulnerability,\" a different vulnerability than CVE-2013-1279.",
  "id": "GHSA-c4mh-7455-pvxv",
  "modified": "2024-10-17T21:31:29Z",
  "published": "2022-05-13T01:15:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1278"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-017"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A16313"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA13-043B.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4MR-QX6R-6753

Vulnerability from github – Published: 2025-09-16 18:31 – Updated: 2025-12-02 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

power: supply: axp288_fuel_gauge: Fix external_power_changed race

fuel_gauge_external_power_changed() dereferences info->bat, which gets sets in axp288_fuel_gauge_probe() like this:

info->bat = devm_power_supply_register(dev, &fuel_gauge_desc, &psy_cfg);

As soon as devm_power_supply_register() has called device_add() the external_power_changed callback can get called. So there is a window where fuel_gauge_external_power_changed() may get called while info->bat has not been set yet leading to a NULL pointer dereference.

Fixing this is easy. The external_power_changed callback gets passed the power_supply which will eventually get stored in info->bat, so fuel_gauge_external_power_changed() can simply directly use the passed in psy argument which is always valid.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-53310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T17:15:36Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: axp288_fuel_gauge: Fix external_power_changed race\n\nfuel_gauge_external_power_changed() dereferences info-\u003ebat,\nwhich gets sets in axp288_fuel_gauge_probe() like this:\n\n  info-\u003ebat = devm_power_supply_register(dev, \u0026fuel_gauge_desc, \u0026psy_cfg);\n\nAs soon as devm_power_supply_register() has called device_add()\nthe external_power_changed callback can get called. So there is a window\nwhere fuel_gauge_external_power_changed() may get called while\ninfo-\u003ebat has not been set yet leading to a NULL pointer dereference.\n\nFixing this is easy. The external_power_changed callback gets passed\nthe power_supply which will eventually get stored in info-\u003ebat,\nso fuel_gauge_external_power_changed() can simply directly use\nthe passed in psy argument which is always valid.",
  "id": "GHSA-c4mr-qx6r-6753",
  "modified": "2025-12-02T00:31:11Z",
  "published": "2025-09-16T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53310"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0456b912121e45b3ef54abe3135e5dcb541f956c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a636c6ba9ce898207f283271cb28511206ab739b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8319774d6f1567d6e7d03653174ab0c82c5c66d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C546-8JMQ-HPRJ

Vulnerability from github – Published: 2024-06-06 21:30 – Updated: 2024-10-11 20:05
VLAI
Summary
Race condition in zenml
Details

A race condition vulnerability exists in zenml-io/zenml versions up to and including 0.55.3, which allows for the creation of multiple users with the same username when requests are sent in parallel. This issue was fixed in version 0.55.5. The vulnerability arises due to insufficient handling of concurrent user creation requests, leading to data inconsistencies and potential authentication problems. Specifically, concurrent processes may overwrite or corrupt user data, complicating user identification and posing security risks. This issue is particularly concerning for APIs that rely on usernames as input parameters, such as PUT /api/v1/users/test_race, where it could lead to further complications.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "zenml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.55.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-2032"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-366"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-06T22:22:19Z",
    "nvd_published_at": "2024-06-06T19:15:53Z",
    "severity": "LOW"
  },
  "details": "A race condition vulnerability exists in zenml-io/zenml versions up to and including 0.55.3, which allows for the creation of multiple users with the same username when requests are sent in parallel. This issue was fixed in version 0.55.5. The vulnerability arises due to insufficient handling of concurrent user creation requests, leading to data inconsistencies and potential authentication problems. Specifically, concurrent processes may overwrite or corrupt user data, complicating user identification and posing security risks. This issue is particularly concerning for APIs that rely on usernames as input parameters, such as PUT /api/v1/users/test_race, where it could lead to further complications.",
  "id": "GHSA-c546-8jmq-hprj",
  "modified": "2024-10-11T20:05:28Z",
  "published": "2024-06-06T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2032"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zenml-io/zenml/commit/afcaf741ef9114c9b32f722f101b97de3d8d147b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/zenml/PYSEC-2024-105.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zenml-io/zenml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/6199cd5d-611f-4ea9-96c5-52a952ba5a56"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Race condition in zenml"
}

GHSA-C546-R2M2-7XPC

Vulnerability from github – Published: 2023-04-11 21:30 – Updated: 2023-04-11 21:30
VLAI
Details

Windows DNS Server Remote Code Execution Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-28306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-11T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Windows DNS Server Remote Code Execution Vulnerability",
  "id": "GHSA-c546-r2m2-7xpc",
  "modified": "2023-04-11T21:30:59Z",
  "published": "2023-04-11T21:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28306"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28306"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Mitigation
Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Mitigation
Architecture and Design
  • Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
  • Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Mitigation
Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Mitigation
Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Mitigation
Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Mitigation
Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Mitigation
Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

CAPEC-26: Leveraging Race Conditions

The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.