{"uuid": "15e0d64d-5846-41e1-82c0-42d5c260391b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-21551", "type": "seen", "source": "https://t.me/hacking_Attack/7388", "content": "Black Hat Ethical Hacking\nHundreds of Millions of Dell Users at Risk from Kernel-Privilege Bugs\n\nhttps://www.blackhatethicalhacking.com/wp-content/uploads/2017/11/black-hat-locks-and-electronics.jpg Hundreds of Millions of Dell Users at Risk from Kernel-Privilege BugsPost Views: 124 \nReading Time: 1 Minute\nFive high-severity security flaws in Dell\u2019s firmware update driver are impacting potentially hundreds of millions of Dell desktops, laptops, notebooks and tablets, researchers said.\nThe bugs have gone undisclosed for 12 years, and could allow the ability to bypass security products, execute code and pivot to other parts of the network for lateral movement, according to SentinelLabs.\n\nThe multiple local privilege-escalation (LPE) bugs exist in the firmware update driver version 2.3 (dbutil_2_3.sys) module, which has been in use since 2009. The driver component handles Dell firmware updates via the Dell BIOS Utility, and it comes pre-installed on most Dell machines running Windows.\n\n\u201cHundreds of millions of Dell devices have updates pushed on a regular basis, for both consumer and enterprise systems,\u201d according to SentinelLabs researchers, writing in a Tuesday blog posting.\n\nThe five bugs are collectively tracked as CVE-2021-21551, and they carry a CVSS vulnerability-severity rating of 8.8 out of 10.\nSee Also: Hewlett Packard Enterprise Plugs Critical Bug in Edge Platform Tool Privilege Escalation to Kernel-ModeResearchers reported that the flaws allow adversaries to escalate their status from non-administrator user to having kernel-mode privileges.\n\nThe five bugs specifically are:\n\n* LPE No. 1, due to memory corruption\n* LPE No 2, also due to memory corruption\n* LPE No. 3, due to a lack of input validation\n* LPE No. 4, also due to a lack of input validation\n* Denial of service flaw, due to a code-logic issue\n\nSentinelLabs researchers said they\u2019re withholding a proof-of-concept (PoC) exploit until June 1, which will be for the LPE No. 1 issue. However, they did break down some general issues with the driver.\n\n\u201cThe first and most immediate problem with the firmware update driver arises out of the fact that it accepts input/output control (IOCTL) requests without any [access-control list] ACL requirements,\u201d according to the posting. \u201cThat means that it can be invoked by a non-privileged user. Allowing any process to communicate with your driver is often a bad practice since drivers operate with the highest of privileges.\u201d\n\nACLs are a collection of permit-and-deny rules that provide security by blocking unauthorized users and allowing authorized users to access specific resources.\nSee Also: Offensive Security Tool: SSHPry2.0\nAn example of the issues with this can be illustrated with IOCTL 0x9B0C1EC8. Using that request makes it possible to completely control the arguments passed to the \u201cmemmove\u201d function, which allows the copying of memory blocks. This in turn leads to an arbitrary read/write vulnerability, researchers noted.\n\n\u201cA classic exploitation technique for this vulnerability would be to overwrite the values of \u2018present\u2019 and \u2018enabled\u2019 in the token-privilege member inside the EPROCESS of the process whose privileges we want to escalate,\u201d they explained. EPROCESS acts as the process object for a given routine.\n\nSentinelLabs also highlighted the issue in the driver that\u2019s at the heart of LPEs No. 3 and 4: It\u2019s possible to run in/out (I/O) instructions in kernel mode with arbitrary operands, i.e., instructions that specify what data is to be manipulated or operated on.\n\n\u201cThis is less trivial to exploit and might require using various creative techniques to achieve elevation of privileges,\u201d they explained. However, a successf[...]", "creation_timestamp": "2026-09-01T20:02:44.698643Z"}