CWE-362
Allowed-with-ReviewConcurrent 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.
2903 vulnerabilities reference this CWE, most recent first.
GHSA-64XP-V3FR-3344
Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-05-24 19:19A concurrent execution using shared resource with improper Synchronization vulnerability ('Race Condition') in the customer database interface of FortiPortal before 6.0.6 may allow an authenticated, low-privilege user to bring the underlying database data into an inconsistent state via specific coordination of web requests.
{
"affected": [],
"aliases": [
"CVE-2021-36181"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-02T18:15:00Z",
"severity": "LOW"
},
"details": "A concurrent execution using shared resource with improper Synchronization vulnerability (\u0027Race Condition\u0027) in the customer database interface of FortiPortal before 6.0.6 may allow an authenticated, low-privilege user to bring the underlying database data into an inconsistent state via specific coordination of web requests.",
"id": "GHSA-64xp-v3fr-3344",
"modified": "2022-05-24T19:19:25Z",
"published": "2022-05-24T19:19:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36181"
},
{
"type": "WEB",
"url": "https://fortiguard.com/advisory/FG-IR-21-102"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6548-G7F4-3JWP
Vulnerability from github – Published: 2022-05-14 03:03 – Updated: 2022-05-14 03:03A race condition exists in a driver in all Android releases from CAF using the Linux kernel (Android for MSM, Firefox OS for MSM, QRD Android) before security patch level 2018-05-05 potentially leading to a use-after-free condition.
{
"affected": [],
"aliases": [
"CVE-2018-5853"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-06T19:29:00Z",
"severity": "HIGH"
},
"details": "A race condition exists in a driver in all Android releases from CAF using the Linux kernel (Android for MSM, Firefox OS for MSM, QRD Android) before security patch level 2018-05-05 potentially leading to a use-after-free condition.",
"id": "GHSA-6548-g7f4-3jwp",
"modified": "2022-05-14T03:03:35Z",
"published": "2022-05-14T03:03:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5853"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2018-05-01"
},
{
"type": "WEB",
"url": "https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0/commit/?id=f64e9815f0488a7b37e4e1395a1457d1dfefda66"
},
{
"type": "WEB",
"url": "https://www.codeaurora.org/security-bulletin/2018/07/02/july-2018-code-aurora-security-bulletin"
}
],
"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-657P-GHH6-V8FR
Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2024-04-04 00:53There is a race condition vulnerability on Huawei Honor V10 smartphones versions earlier than Berkeley-AL20 9.0.0.156(C00E156R2P14T8), Honor 10 smartphones versions earlier than Columbia-AL10B 9.0.0.156(C00E156R1P20T8) and Honor Play smartphones versions earlier than Cornell-AL00A 9.0.0.156(C00E156R1P13T8). An attacker tricks the user into installing a malicious application, which makes multiple processes to operate the same variate at the same time. Successful exploit could cause execution of malicious code.
{
"affected": [],
"aliases": [
"CVE-2019-5216"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-06T15:29:00Z",
"severity": "HIGH"
},
"details": "There is a race condition vulnerability on Huawei Honor V10 smartphones versions earlier than Berkeley-AL20 9.0.0.156(C00E156R2P14T8), Honor 10 smartphones versions earlier than Columbia-AL10B 9.0.0.156(C00E156R1P20T8) and Honor Play smartphones versions earlier than Cornell-AL00A 9.0.0.156(C00E156R1P13T8). An attacker tricks the user into installing a malicious application, which makes multiple processes to operate the same variate at the same time. Successful exploit could cause execution of malicious code.",
"id": "GHSA-657p-ghh6-v8fr",
"modified": "2024-04-04T00:53:35Z",
"published": "2022-05-24T16:47:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5216"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20190116-01-smartphone-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-65FW-CHH2-JRH3
Vulnerability from github – Published: 2022-05-17 02:30 – Updated: 2022-05-17 02:30An issue was discovered in certain Apple products. macOS before 10.12.4 is affected. The issue involves the "AppleGraphicsPowerManagement" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.
{
"affected": [],
"aliases": [
"CVE-2017-2421"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-02T01:59:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in certain Apple products. macOS before 10.12.4 is affected. The issue involves the \"AppleGraphicsPowerManagement\" component. A race condition allows attackers to execute arbitrary code in a privileged context via a crafted app.",
"id": "GHSA-65fw-chh2-jrh3",
"modified": "2022-05-17T02:30:37Z",
"published": "2022-05-17T02:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2421"
},
{
"type": "WEB",
"url": "https://support.apple.com/HT207615"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/97140"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1038138"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-65RH-573H-VGW7
Vulnerability from github – Published: 2022-05-17 01:10 – Updated: 2022-05-17 01:10Race condition in the Measurement, Aggregation, and Correlation Engine (MACE) implementation in Cisco IOS 15.4(2)T3 and earlier allows remote attackers to cause a denial of service (device reload) via crafted network traffic that triggers improper handling of the timing of process switching and Cisco Express Forwarding (CEF) switching, aka Bug ID CSCul48736.
{
"affected": [],
"aliases": [
"CVE-2015-0608"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-02-12T01:59:00Z",
"severity": "HIGH"
},
"details": "Race condition in the Measurement, Aggregation, and Correlation Engine (MACE) implementation in Cisco IOS 15.4(2)T3 and earlier allows remote attackers to cause a denial of service (device reload) via crafted network traffic that triggers improper handling of the timing of process switching and Cisco Express Forwarding (CEF) switching, aka Bug ID CSCul48736.",
"id": "GHSA-65rh-573h-vgw7",
"modified": "2022-05-17T01:10:42Z",
"published": "2022-05-17T01:10:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-0608"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/100808"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2015-0608"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/viewAlert.x?alertId=37421"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/72566"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1031731"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6634-G827-CG9W
Vulnerability from github – Published: 2023-07-05 18:30 – Updated: 2024-04-04 05:23In MADEFORNET HTTP Debugger through 9.12, the Windows service does not set the seclevel registry key before launching the driver. Thus, it is possible for an unprivileged application to obtain a handle to the NetFilterSDK wrapper before the service obtains exclusive access.
{
"affected": [],
"aliases": [
"CVE-2023-35863"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-05T18:15:10Z",
"severity": "MODERATE"
},
"details": "In MADEFORNET HTTP Debugger through 9.12, the Windows service does not set the seclevel registry key before launching the driver. Thus, it is possible for an unprivileged application to obtain a handle to the NetFilterSDK wrapper before the service obtains exclusive access.",
"id": "GHSA-6634-g827-cg9w",
"modified": "2024-04-04T05:23:55Z",
"published": "2023-07-05T18:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35863"
},
{
"type": "WEB",
"url": "https://ctrl-c.club/~blue/nfsdk.html"
},
{
"type": "WEB",
"url": "https://www.madefornet.com/products.html"
},
{
"type": "WEB",
"url": "https://www.michaelrowley.dev/research/posts/nfsdk/nfsdk.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-665W-MH9X-RC36
Vulnerability from github – Published: 2022-05-17 00:57 – Updated: 2022-05-17 00:57Race condition in Pepper, as used in Google Chrome before 23.0.1271.64, allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to buffers.
{
"affected": [],
"aliases": [
"CVE-2012-5119"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-11-07T11:43:00Z",
"severity": "MODERATE"
},
"details": "Race condition in Pepper, as used in Google Chrome before 23.0.1271.64, allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors related to buffers.",
"id": "GHSA-665w-mh9x-rc36",
"modified": "2022-05-17T00:57:41Z",
"published": "2022-05-17T00:57:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5119"
},
{
"type": "WEB",
"url": "https://code.google.com/p/chromium/issues/detail?id=149759"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/79866"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A15977"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2012/11/stable-channel-release-and-beta-channel.html"
},
{
"type": "WEB",
"url": "http://osvdb.org/87072"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/56413"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-66CR-WXHM-P423
Vulnerability from github – Published: 2025-06-18 12:30 – Updated: 2025-11-14 18:31In the Linux kernel, the following vulnerability has been resolved:
mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW
Ever since the Dirty COW (CVE-2016-5195) security issue happened, we know that FOLL_FORCE can be possibly dangerous, especially if there are races that can be exploited by user space.
Right now, it would be sufficient to have some code that sets a PTE of a R/O-mapped shared page dirty, in order for it to erroneously become writable by FOLL_FORCE. The implications of setting a write-protected PTE dirty might not be immediately obvious to everyone.
And in fact ever since commit 9ae0f87d009c ("mm/shmem: unconditionally set pte dirty in mfill_atomic_install_pte"), we can use UFFDIO_CONTINUE to map a shmem page R/O while marking the pte dirty. This can be used by unprivileged user space to modify tmpfs/shmem file content even if the user does not have write permissions to the file, and to bypass memfd write sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590).
To fix such security issues for good, the insight is that we really only need that fancy retry logic (FOLL_COW) for COW mappings that are not writable (!VM_WRITE). And in a COW mapping, we really only broke COW if we have an exclusive anonymous page mapped. If we have something else mapped, or the mapped anonymous page might be shared (!PageAnonExclusive), we have to trigger a write fault to break COW. If we don't find an exclusive anonymous page when we retry, we have to trigger COW breaking once again because something intervened.
Let's move away from this mandatory-retry + dirty handling and rely on our PageAnonExclusive() flag for making a similar decision, to use the same COW logic as in other kernel parts here as well. In case we stumble over a PTE in a COW mapping that does not map an exclusive anonymous page, COW was not properly broken and we have to trigger a fake write-fault to break COW.
Just like we do in can_change_pte_writable() added via commit 64fe24a3e05e ("mm/mprotect: try avoiding write faults for exclusive anonymous pages when changing protection") and commit 76aefad628aa ("mm/mprotect: fix soft-dirty check in can_change_pte_writable()"), take care of softdirty and uffd-wp manually.
For example, a write() via /proc/self/mem to a uffd-wp-protected range has to fail instead of silently granting write access and bypassing the userspace fault handler. Note that FOLL_FORCE is not only used for debug access, but also triggered by applications without debug intentions, for example, when pinning pages via RDMA.
This fixes CVE-2022-2590. Note that only x86_64 and aarch64 are affected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR.
Fortunately, FOLL_COW is no longer required to handle FOLL_FORCE. So let's just get rid of it.
Thanks to Nadav Amit for pointing out that the pte_dirty() check in FOLL_FORCE code is problematic and might be exploitable.
Note 1: We don't check for the PTE being dirty because it doesn't matter for making a "was COWed" decision anymore, and whoever modifies the page has to set the page dirty either way.
Note 2: Kernels before extended uffd-wp support and before PageAnonExclusive (< 5.19) can simply revert the problematic commit instead and be safe regarding UFFDIO_CONTINUE. A backport to v5.19 requires minor adjustments due to lack of vma_soft_dirty_enabled().
{
"affected": [],
"aliases": [
"CVE-2022-50014"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:29Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW\n\nEver since the Dirty COW (CVE-2016-5195) security issue happened, we know\nthat FOLL_FORCE can be possibly dangerous, especially if there are races\nthat can be exploited by user space.\n\nRight now, it would be sufficient to have some code that sets a PTE of a\nR/O-mapped shared page dirty, in order for it to erroneously become\nwritable by FOLL_FORCE. The implications of setting a write-protected PTE\ndirty might not be immediately obvious to everyone.\n\nAnd in fact ever since commit 9ae0f87d009c (\"mm/shmem: unconditionally set\npte dirty in mfill_atomic_install_pte\"), we can use UFFDIO_CONTINUE to map\na shmem page R/O while marking the pte dirty. This can be used by\nunprivileged user space to modify tmpfs/shmem file content even if the\nuser does not have write permissions to the file, and to bypass memfd\nwrite sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590).\n\nTo fix such security issues for good, the insight is that we really only\nneed that fancy retry logic (FOLL_COW) for COW mappings that are not\nwritable (!VM_WRITE). And in a COW mapping, we really only broke COW if\nwe have an exclusive anonymous page mapped. If we have something else\nmapped, or the mapped anonymous page might be shared (!PageAnonExclusive),\nwe have to trigger a write fault to break COW. If we don\u0027t find an\nexclusive anonymous page when we retry, we have to trigger COW breaking\nonce again because something intervened.\n\nLet\u0027s move away from this mandatory-retry + dirty handling and rely on our\nPageAnonExclusive() flag for making a similar decision, to use the same\nCOW logic as in other kernel parts here as well. In case we stumble over\na PTE in a COW mapping that does not map an exclusive anonymous page, COW\nwas not properly broken and we have to trigger a fake write-fault to break\nCOW.\n\nJust like we do in can_change_pte_writable() added via commit 64fe24a3e05e\n(\"mm/mprotect: try avoiding write faults for exclusive anonymous pages\nwhen changing protection\") and commit 76aefad628aa (\"mm/mprotect: fix\nsoft-dirty check in can_change_pte_writable()\"), take care of softdirty\nand uffd-wp manually.\n\nFor example, a write() via /proc/self/mem to a uffd-wp-protected range has\nto fail instead of silently granting write access and bypassing the\nuserspace fault handler. Note that FOLL_FORCE is not only used for debug\naccess, but also triggered by applications without debug intentions, for\nexample, when pinning pages via RDMA.\n\nThis fixes CVE-2022-2590. Note that only x86_64 and aarch64 are\naffected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR.\n\nFortunately, FOLL_COW is no longer required to handle FOLL_FORCE. So\nlet\u0027s just get rid of it.\n\nThanks to Nadav Amit for pointing out that the pte_dirty() check in\nFOLL_FORCE code is problematic and might be exploitable.\n\nNote 1: We don\u0027t check for the PTE being dirty because it doesn\u0027t matter\n\tfor making a \"was COWed\" decision anymore, and whoever modifies the\n\tpage has to set the page dirty either way.\n\nNote 2: Kernels before extended uffd-wp support and before\n\tPageAnonExclusive (\u003c 5.19) can simply revert the problematic\n\tcommit instead and be safe regarding UFFDIO_CONTINUE. A backport to\n\tv5.19 requires minor adjustments due to lack of\n\tvma_soft_dirty_enabled().",
"id": "GHSA-66cr-wxhm-p423",
"modified": "2025-11-14T18:31:25Z",
"published": "2025-06-18T12:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50014"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5535be3099717646781ce1540cf725965d680e7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9def52eb10baab3b700858003d462fcf17d62873"
}
],
"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-66F7-F7R3-VXQ7
Vulnerability from github – Published: 2025-11-28 03:30 – Updated: 2025-11-28 03:30DoS vulnerability in the video-related system service module. Impact: Successful exploitation of this vulnerability may affect availability.
{
"affected": [],
"aliases": [
"CVE-2025-58316"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-28T03:16:00Z",
"severity": "HIGH"
},
"details": "DoS vulnerability in the video-related system service module.\nImpact: Successful exploitation of this vulnerability may affect availability.",
"id": "GHSA-66f7-f7r3-vxq7",
"modified": "2025-11-28T03:30:27Z",
"published": "2025-11-28T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58316"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-66M4-GC8H-HPJX
Vulnerability from github – Published: 2023-03-12 06:30 – Updated: 2025-03-04 19:07Ibexa DXP is using random execution time to hinder timing attacks against user accounts, a method of discovering whether a given account exists in a system without knowing its password, thus affecting privacy. This implementation was found to not be good enough in some situations. The fix replaces this with constant time functionality, configured in the new security.yml parameter 'ibexa.security.authentication.constant_auth_time'. It will log a warning if the constant time is exceeded. If this happens the setting should be increased.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "ezsystems/ezplatform-kernel"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0"
},
{
"fixed": "1.3.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "ezsystems/ezpublish-kernel"
},
"ranges": [
{
"events": [
{
"introduced": "7.5.0"
},
{
"fixed": "7.5.29"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-48366"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-13T20:55:56Z",
"nvd_published_at": "2023-03-12T05:15:00Z",
"severity": "LOW"
},
"details": "Ibexa DXP is using random execution time to hinder timing attacks against user accounts, a method of discovering whether a given account exists in a system without knowing its password, thus affecting privacy. This implementation was found to not be good enough in some situations. The fix replaces this with constant time functionality, configured in the new security.yml parameter \u0027ibexa.security.authentication.constant_auth_time\u0027. It will log a warning if the constant time is exceeded. If this happens the setting should be increased.",
"id": "GHSA-66m4-gc8h-hpjx",
"modified": "2025-03-04T19:07:18Z",
"published": "2023-03-12T06:30:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ezsystems/ezplatform-kernel/security/advisories/GHSA-342c-vcff-2ff2"
},
{
"type": "WEB",
"url": "https://github.com/ezsystems/ezpublish-kernel/security/advisories/GHSA-xfqg-p48g-hh94"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48366"
},
{
"type": "WEB",
"url": "https://developers.ibexa.co/security-advisories/ibexa-sa-2022-006-vulnerabilities-in-page-builder-login-and-commerce"
},
{
"type": "PACKAGE",
"url": "https://github.com/ezsystems/ezplatform-kernel"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Timing attack in eZ Platform Ibexa"
}
Mitigation
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
Mitigation
Use thread-safe capabilities such as the data access abstraction in Spring.
Mitigation
- 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
When using multithreading and operating on shared variables, only use thread-safe functions.
Mitigation
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
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Mitigation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
Mitigation
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
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
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.