{"id":23619,"date":"2023-12-15T15:00:48","date_gmt":"2023-12-15T23:00:48","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2023\/12\/15\/news-17349\/"},"modified":"2023-12-15T15:00:48","modified_gmt":"2023-12-15T23:00:48","slug":"news-17349","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2023\/12\/15\/news-17349\/","title":{"rendered":"Patching Perforce perforations: Critical RCE vulnerability discovered in Perforce Helix Core Server"},"content":{"rendered":"

Credit to Author: Microsoft Threat Intelligence| Date: Fri, 15 Dec 2023 17:00:00 +0000<\/strong><\/p>\n

Microsoft discovered, responsibly disclosed, and helped remediate four vulnerabilities that could be remotely exploited by unauthenticated attackers in Perforce Helix Core Server<\/a> (\u201cPerforce Server\u201d), a source code management platform largely used in the videogame industry<\/a> and by multiple organizations spanning government, military, technology, retail, and more<\/a>. Perforce Server customers are strongly urged to update to version 2023.1\/2513900, available here: https:\/\/www.perforce.com\/downloads\/helix-core-p4d<\/a>. The most critical of the four vulnerabilities has a CVSS score of 10.0<\/a> because it allows for arbitrary remote code execution as LocalSystem<\/em><\/a> by unauthenticated remote attackers. An attacker with system-level remote code execution access to a source code management platform can insert backdoors into software products, exfiltrate source code and other intellectual property, and pivot to other sensitive enterprise infrastructure. While Microsoft has not observed evidence of in-the-wild exploitation for any of these vulnerabilities, exploitation of the most critical vulnerability could give unauthenticated attackers complete control over unpatched systems and connected infrastructure.<\/p>\n

Due to the way Microsoft\u2019s deployed Perforce Servers were configured, at no point were any of Microsoft\u2019s internet-facing servers vulnerable to this critical vulnerability. No consumer, customer, or partner data was at risk or leaked.<\/p>\n

Microsoft\u2019s commitment to gaming and community security<\/a> is paramount, and we worked closely with Perforce to report these vulnerabilities and drive remediation. We thank Perforce and are grateful for their team\u2019s quick response in developing and releasing patches for these vulnerabilities.<\/p>\n

While the three high severity vulnerabilities could be used to launch attacks such as a denial of service (DoS) against vulnerable systems, vulnerabilities with a CVSS score of 10.0 have the most severe potential impact that can extend beyond the vulnerable component, introducing a risk to software supply chains. The discovered vulnerabilities are summarized in the table below:<\/p>\n

\n\n\n\n\n\n\n\n
CVE ID<\/strong><\/td>\nCVSS Score<\/strong><\/td>\nCWE ID<\/strong><\/td>\nVulnerability<\/strong><\/td>\n<\/tr>\n
CVE-2023-5759<\/a><\/strong><\/td>\n7.5<\/a><\/td>\nCWE-405: Asymmetric Resource Consumption (Amplification)<\/a><\/td>\nUnauthenticated DoS via RPC Header Abuse<\/td>\n<\/tr>\n
CVE-2023-45849<\/a><\/strong><\/td>\n10.0<\/a><\/td>\nCWE-306: Missing Authentication for Critical Function<\/a><\/td>\nUnauthenticated Remote Code Execution as LocalSystem via user-bgtask RPC Command<\/td>\n<\/tr>\n
CVE-2023-35767<\/a><\/strong><\/td>\n7.5<\/a><\/td>\nCWE-306: Missing Authentication for Critical Function<\/a><\/td>\nUnauthenticated DoS via rmt-Shutdown RPC Command<\/td>\n<\/tr>\n
CVE-2023-45319<\/a><\/strong><\/td>\n7.5<\/a><\/td>\nCWE-252: Unchecked Return Value<\/a><\/td>\nUnauthenticated DoS via rmt-UpdtFovrCommit RPC Command<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Perforce Server listens on TCP port 1666 by default, though server administrators will often change this port number to hide from scanners or to host Perforce Server via TLS. Microsoft scanned the internet in November 2023 for TCP port 1666 with a custom Perforce Server network signature and found over 1,000 exposed Perforce Server instances.<\/p>\n

In this blog, we detail how we discovered each of the vulnerabilities and highlight the potential impact if exploited. Alongside applying Perforce\u2019s patches, we also include additional mitigation and protection guidance for customers to minimize the risk of exploitation. Lastly, we\u2019re sharing this information with the broader community to drive awareness to further improve protections across the security ecosystem, and to emphasize the importance of responsible disclosure and collaboration to secure platforms and devices.<\/p>\n

Discovering the vulnerabilities<\/h2>\n

To keep Microsoft\u2019s game development studios<\/a> and their customers safe, we recently conducted an application security review of Perforce Server, the source code management platform relied on by most of our studios. For our security review, we analyzed Perforce Server version 2023.1.244.2900 and installed it on Windows 11 22H2. We used Perforce Server\u2019s default installation options, which resulted by-design<\/a> in the Perforce Server service running as LocalSystem<\/em>:<\/p>\n

\"Screenshot
Figure 1. Perforce Server runs as LocalSystem<\/em><\/figcaption><\/figure>\n

Recovering debug symbols<\/h3>\n

In 2014, Perforce open-sourced<\/a> the code for their CLI Perforce Client, and informed users we can download the code from the bin.tools<\/em> subdirectory of any given release<\/a>. While having any source code is invaluable for application security vulnerability research purposes, this source code is specific to the client, not the server. The latter is only distributed in compiled binary form.<\/p>\n

The binaries that are installed by Perforce Server\u2019s installer have their debug symbols<\/a> stripped (removed from the distributed executable images), which makes it harder to understand the disassembled code during static analysis. To aid our review, we attempted to recover these debug symbols.<\/p>\n

Discovering debug symbols<\/h4>\n

Sometimes applications offer software development kits (SDKs) that can be mined for debug symbol data. In the case of Perforce Server, Perforce offers a \u201cC\/C++ API\u201d package for the Windows (x64) platform that comes in the form of a .zip file containing three directories: include<\/em>, lib<\/em>, and sample<\/em>. The lib<\/em> directory is especially interesting for us, as it contains about 400 MB of .lib files:<\/p>\n

\"Screenshot
Figure 2. SDK’s .lib files<\/em><\/figcaption><\/figure>\n

Like .exe files, .lib files are COFF<\/a> files that can contain debug symbols. By using dumpbin.exe<\/em><\/a> \/symbols <\/em>to inspect each .lib file, we found that the nine .lib files in the package contain a total of 1,251,756 debug symbol entries.<\/p>\n

To understand why this is useful to us, let us consider an approximation of how .exe and .lib files are built:<\/p>\n

\"Compilation
Figure 3. Compilation process<\/em><\/figcaption><\/figure>\n

In the diagram above, we can see that the SDK .obj files were linked along with server-specific .obj files to create Perforce Server\u2019s p4s.exe<\/em> (\u201cPerforce Service\u201d)<\/a> file. During that linking process, the debug symbols were stripped. However, the same SDK .obj files had their debug symbols retained<\/em> when linked into the SDK .lib files. Since the .lib files contain debug symbols, we can match each compiled SDK function in each .lib file to its SDK function name. If we can then find those same compiled SDK functions in Perforce Server\u2019s .exe and .dll files, we can map the SDK function names to those functions as well, thus simplifying our analysis of the p4s.exe<\/em> file.<\/p>\n

To begin, we must first determine which SDK package to use for our analysis. If we look at the containing directory<\/a> for the .zip file downloaded from the \u201cC\/C++ API\u201d package, we see it contains 144 p4api<\/em> SDK packages:<\/p>\n

\"Screenshot
Figure 4. SDK packages<\/em><\/figcaption><\/figure>\n

The reason we see 144 packages listed is that there is every combination of the following:<\/p>\n

\"Package
Figure 5. Package combinations<\/em><\/figcaption><\/figure>\n

That\u2019s nine possible values for compiler, two possible values for linking, two possible values for build type, and four possible values for OpenSSL version. In other words, multiplying those four values together leads us to 144 possible combinations. To map named functions from the SDK\u2019s .lib files to Perforce Server\u2019s p4s.exe<\/em> file, we\u2019ll need to choose the correct SDK package, since, for example, a function compiled with Visual Studio 2005 may look very different from the same function compiled with Visual Studio 2022.<\/p>\n

So how do we know which compiler, linker option, build type, and OpenSSL version were used for our installed distribution of Perforce Server? We don\u2019t. We could make some educated guesses and examine artifacts such as the binaries\u2019 Rich Headers<\/a> to determine the right combination, but instead we chose to use automation to test all possible combinations. (Note that \u201cRich Headers\u201d is a colloquial term used in the industry, not a Microsoft-official name for this structure.)<\/p>\n

Finding the right set of debug symbols<\/h4>\n

After downloading all of the statically linked p4api<\/em> archives from Perforce\u2019s website, we used IDA Pro’s<\/a> F.L.I.R.T. technology<\/a> to create signatures for each Perforce Server SDK package. To do so, we automated the following steps:<\/p>\n

    \n
  1. Use pcf.exe<\/em> (\u201cparsecoff\u201d) from IDA Pro\u2019s Fast Library Acquisition for Identification and Recognition (FLAIR) SDK to create .pat (\u201cpattern\u201d) files for each Perforce Server SDK package\u2019s .lib file.<\/li>\n
  2. Use sigmake.exe<\/em> from the FLAIR SDK to create a .sig (\u201csignature\u201d) file for all the .pat files from each given Perforce Server SDK package.<\/li>\n
  3. Use zipsig.exe<\/em> from the FLAIR SDK to compress each .sig file.<\/li>\n
  4. Disassemble Perforce Server\u2019s p4s.exe<\/em> file with IDA Pro and save the resulting .idb (\u201cIDA database\u201d) file.<\/li>\n
  5. For each .sig file, open the .idb file, apply the .sig file<\/a>, count the number of .sig file function matches<\/a>, and close the .idb file without saving the modifications.<\/li>\n
  6. Rank the number of function matches for each .sig file.<\/li>\n<\/ol>\n

    After following the process above, we found the debug symbols from p4api_vs2017_static_openssl1.1.1.zip<\/em> had the most function matches in p4s.exe<\/em>:<\/p>\n

    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    Function
    Matches<\/strong><\/td>\n    		Signature File<\/strong><\/td>\n<\/tr>\n
    11,928<\/td>\np4api_vs2017_static_openssl1.1.1_p4api-2023.1.2468153-vs2017_static.sig<\/td>\n<\/tr>\n
    11,887<\/td>\np4api_vs2017_static_openssl3_p4api-2023.1.2468153-vs2017_static.sig<\/td>\n<\/tr>\n
    11,847<\/td>\np4api_vs2017_static_openssl1.0.2_p4api-2023.1.2468153-vs2017_static.sig<\/td>\n<\/tr>\n
    11,847<\/td>\np4api_vs2017_static_p4api-2023.1.2468153-vs2017_static.sig<\/td>\n<\/tr>\n
    10,228<\/td>\np4api_vs2017_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2017_static_vsdebug.sig<\/td>\n<\/tr>\n
    10,187<\/td>\np4api_vs2017_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2017_static_vsdebug.sig<\/td>\n<\/tr>\n
    10,147<\/td>\np4api_vs2017_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2017_static_vsdebug.sig<\/td>\n<\/tr>\n
    10,147<\/td>\np4api_vs2017_static_vsdebug_p4api-2023.1.2468153-vs2017_static_vsdebug.sig<\/td>\n<\/tr>\n
    8,222<\/td>\np4api_vs2019_static_openssl1.1.1_p4api-2023.1.2468153-vs2019_static.sig<\/td>\n<\/tr>\n
    8,195<\/td>\np4api_vs2019_static_openssl3_p4api-2023.1.2468153-vs2019_static.sig<\/td>\n<\/tr>\n
    8,167<\/td>\np4api_vs2019_static_openssl1.0.2_p4api-2023.1.2468153-vs2019_static.sig<\/td>\n<\/tr>\n
    8,167<\/td>\np4api_vs2019_static_p4api-2023.1.2468153-vs2019_static.sig<\/td>\n<\/tr>\n
    7,804<\/td>\np4api_vs2019_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2019_static_vsdebug.sig<\/td>\n<\/tr>\n
    7,777<\/td>\np4api_vs2019_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2019_static_vsdebug.sig<\/td>\n<\/tr>\n
    7,749<\/td>\np4api_vs2019_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2019_static_vsdebug.sig<\/td>\n<\/tr>\n
    7,749<\/td>\np4api_vs2019_static_vsdebug_p4api-2023.1.2468153-vs2019_static_vsdebug.sig<\/td>\n<\/tr>\n
    5,818<\/td>\np4api_vs2022_static_openssl1.1.1_p4api-2023.1.2468153-vs2022_static.sig<\/td>\n<\/tr>\n
    5,802<\/td>\np4api_vs2022_static_openssl3_p4api-2023.1.2468153-vs2022_static.sig<\/td>\n<\/tr>\n
    5,784<\/td>\np4api_vs2022_static_openssl1.0.2_p4api-2023.1.2468153-vs2022_static.sig<\/td>\n<\/tr>\n
    5,784<\/td>\np4api_vs2022_static_p4api-2023.1.2468153-vs2022_static.sig<\/td>\n<\/tr>\n
    5,525<\/td>\np4api_vs2022_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2022_static_vsdebug.sig<\/td>\n<\/tr>\n
    5,509<\/td>\np4api_vs2022_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2022_static_vsdebug.sig<\/td>\n<\/tr>\n
    5,491<\/td>\np4api_vs2022_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2022_static_vsdebug.sig<\/td>\n<\/tr>\n
    5,491<\/td>\np4api_vs2022_static_vsdebug_p4api-2023.1.2468153-vs2022_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,639<\/td>\np4api_vs2015_static_openssl1.1.1_p4api-2023.1.2468153-vs2015_static.sig<\/td>\n<\/tr>\n
    1,639<\/td>\np4api_vs2015_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2015_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,630<\/td>\np4api_vs2015_static_openssl1.0.2_p4api-2023.1.2468153-vs2015_static.sig<\/td>\n<\/tr>\n
    1,630<\/td>\np4api_vs2015_static_p4api-2023.1.2468153-vs2015_static.sig<\/td>\n<\/tr>\n
    1,630<\/td>\np4api_vs2015_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2015_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,630<\/td>\np4api_vs2015_static_vsdebug_p4api-2023.1.2468153-vs2015_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,628<\/td>\np4api_vs2015_static_openssl3_p4api-2023.1.2468153-vs2015_static.sig<\/td>\n<\/tr>\n
    1,628<\/td>\np4api_vs2015_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2015_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,042<\/td>\np4api_vs2013_static_openssl1.1.1_p4api-2023.1.2468153-vs2013_static.sig<\/td>\n<\/tr>\n
    1,041<\/td>\np4api_vs2013_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2013_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,040<\/td>\np4api_vs2013_static_openssl1.0.2_p4api-2023.1.2468153-vs2013_static.sig<\/td>\n<\/tr>\n
    1,040<\/td>\np4api_vs2013_static_p4api-2023.1.2468153-vs2013_static.sig<\/td>\n<\/tr>\n
    1,039<\/td>\np4api_vs2013_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2013_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,039<\/td>\np4api_vs2013_static_vsdebug_p4api-2023.1.2468153-vs2013_static_vsdebug.sig<\/td>\n<\/tr>\n
    1,033<\/td>\np4api_vs2013_static_openssl3_p4api-2023.1.2468153-vs2013_static.sig<\/td>\n<\/tr>\n
    1,032<\/td>\np4api_vs2013_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2013_static_vsdebug.sig<\/td>\n<\/tr>\n
    973<\/td>\np4api_vs2012_static_openssl1.1.1_p4api-2023.1.2468153-vs2012_static.sig<\/td>\n<\/tr>\n
    972<\/td>\np4api_vs2012_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2012_static_vsdebug.sig<\/td>\n<\/tr>\n
    971<\/td>\np4api_vs2012_static_openssl1.0.2_p4api-2023.1.2468153-vs2012_static.sig<\/td>\n<\/tr>\n
    971<\/td>\np4api_vs2012_static_p4api-2023.1.2468153-vs2012_static.sig<\/td>\n<\/tr>\n
    970<\/td>\np4api_vs2012_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2012_static_vsdebug.sig<\/td>\n<\/tr>\n
    970<\/td>\np4api_vs2012_static_vsdebug_p4api-2023.1.2468153-vs2012_static_vsdebug.sig<\/td>\n<\/tr>\n
    967<\/td>\np4api_vs2012_static_openssl3_p4api-2023.1.2468153-vs2012_static.sig<\/td>\n<\/tr>\n
    966<\/td>\np4api_vs2012_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2012_static_vsdebug.sig<\/td>\n<\/tr>\n
    838<\/td>\np4api_vs2010_static_openssl1.1.1_p4api-2023.1.2468153-vs2010_static.sig<\/td>\n<\/tr>\n
    838<\/td>\np4api_vs2010_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2010_static_vsdebug.sig<\/td>\n<\/tr>\n
    837<\/td>\np4api_vs2010_static_openssl1.0.2_p4api-2023.1.2468153-vs2010_static.sig<\/td>\n<\/tr>\n
    837<\/td>\np4api_vs2010_static_p4api-2023.1.2468153-vs2010_static.sig<\/td>\n<\/tr>\n
    837<\/td>\np4api_vs2010_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2010_static_vsdebug.sig<\/td>\n<\/tr>\n
    837<\/td>\np4api_vs2010_static_vsdebug_p4api-2023.1.2468153-vs2010_static_vsdebug.sig<\/td>\n<\/tr>\n
    833<\/td>\np4api_vs2010_static_openssl3_p4api-2023.1.2468153-vs2010_static.sig<\/td>\n<\/tr>\n
    833<\/td>\np4api_vs2010_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2010_static_vsdebug.sig<\/td>\n<\/tr>\n
    495<\/td>\np4api_vs2008_static_openssl1.1.1_p4api-2023.1.2468153-vs2008_static.sig<\/td>\n<\/tr>\n
    495<\/td>\np4api_vs2008_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2008_static_vsdebug.sig<\/td>\n<\/tr>\n
    494<\/td>\np4api_vs2008_static_openssl1.0.2_p4api-2023.1.2468153-vs2008_static.sig<\/td>\n<\/tr>\n
    494<\/td>\np4api_vs2008_static_p4api-2023.1.2468153-vs2008_static.sig<\/td>\n<\/tr>\n
    494<\/td>\np4api_vs2008_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2008_static_vsdebug.sig<\/td>\n<\/tr>\n
    494<\/td>\np4api_vs2008_static_vsdebug_p4api-2023.1.2468153-vs2008_static_vsdebug.sig<\/td>\n<\/tr>\n
    490<\/td>\np4api_vs2008_static_openssl3_p4api-2023.1.2468153-vs2008_static.sig<\/td>\n<\/tr>\n
    490<\/td>\np4api_vs2008_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2008_static_vsdebug.sig<\/td>\n<\/tr>\n
    440<\/td>\np4api_vs2005_static_openssl1.1.1_p4api-2023.1.2468153-vs2005_static.sig<\/td>\n<\/tr>\n
    440<\/td>\np4api_vs2005_static_vsdebug_openssl1.1.1_p4api-2023.1.2468153-vs2005_static_vsdebug.sig<\/td>\n<\/tr>\n
    439<\/td>\np4api_vs2005_static_openssl1.0.2_p4api-2023.1.2468153-vs2005_static.sig<\/td>\n<\/tr>\n
    439<\/td>\np4api_vs2005_static_p4api-2023.1.2468153-vs2005_static.sig<\/td>\n<\/tr>\n
    439<\/td>\np4api_vs2005_static_vsdebug_openssl1.0.2_p4api-2023.1.2468153-vs2005_static_vsdebug.sig<\/td>\n<\/tr>\n
    439<\/td>\np4api_vs2005_static_vsdebug_p4api-2023.1.2468153-vs2005_static_vsdebug.sig<\/td>\n<\/tr>\n
    435<\/td>\np4api_vs2005_static_openssl3_p4api-2023.1.2468153-vs2005_static.sig<\/td>\n<\/tr>\n
    435<\/td>\np4api_vs2005_static_vsdebug_openssl3_p4api-2023.1.2468153-vs2005_static_vsdebug.sig<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

    The remainder of this blog post leverages these signatures for p4s.exe\u2019s<\/em> function names and type information.<\/p>\n

    Investigating the RPC header<\/h3>\n

    Given that Perforce Server runs as LocalSystem<\/em>, local elevation of privilege attacks would certainly be worthwhile to explore. However, remote attacks via a network are much more intriguing from a vulnerability research perspective. Our next step is to investigate how Perforce Server handles data it receives from remote users, or in our case, attackers.<\/p>\n

    Using TCPView<\/a>, we can see that p4s.exe<\/em> is listening for incoming connections on TCP port 1666:<\/p>\n

    \"Screenshot
    Figure 6. TCPView showing Perforce Server’s listening TCP port<\/em><\/figcaption><\/figure>\n

    Programs built for Windows that listen on TCP ports for incoming connections almost always use Winsock\u2019s recv()<\/em><\/a> <\/em>function to receive incoming network data from clients. Using IDA Pro\u2019s cross-references<\/a> (\u201cCODE XREF\u201ds below), we can see that recv()<\/em> is called by several functions:<\/p>\n

    \"Screenshot
    Figure 7. Code cross-references to recv()<\/em><\/figcaption><\/figure>\n

    We\u2019re looking to assess how received network data is parsed and handled, and to save time in determining which of the functions above actually receives the connected client data via recv()<\/em>, we used a debugger to set a breakpoint on recv()<\/em> and reviewed its thread\u2019s call-stack to reveal the following chain of function calls:<\/p>\n

    \"A
    Figure 8. The function call-stack for recv() at runtime<\/em><\/figcaption><\/figure>\n

    In the call-stack above, \u201cRpc<\/em>\u201d is short for \u201cRemote Procedure Call\u201d, a common term<\/a> used for remotely executing functions.<\/p>\n

    Although we\u2019re assessing the Perforce Server, the function RpcTransport::Receive()<\/em> (in Figure 8) is also included in the client source code<\/a> discussed above (note that the comments are from Perforce\u2019s developers, not from Microsoft):<\/p>\n

    \"Screenshot
    Figure 9. Source code for RpcTransport::Receive()<\/em><\/figcaption><\/figure>\n

    The code above does the following:<\/p>\n

      \n
    1. On line 69, calls NetBuffer::Receive()<\/em> to receive five bytes of data from the connected TCP client. We will refer to these five bytes as the RPC header.<\/li>\n
    2. On line 72, verifies that the first byte\u2019s value equals the value of the following four bytes using the XOR operation to compute a parity byte checksum.<\/li>\n
    3. On line 78, interprets those following four bytes as a 32-bit little-endian value named length<\/em>.<\/li>\n
    4. On line 85, verifies that length >= 12<\/em> and that length < 0x1FFFFFFF<\/em>.<\/li>\n
    5. On line 93, allocates memory of size length<\/em> and receives length<\/em> bytes from the connected TCP client.<\/li>\n<\/ol>\n

      However, there\u2019s a design risk in the code above, in that there\u2019s not sufficient protection against asymmetric resource consumption<\/a> attacks from remote unauthenticated attackers. An attacker could connect to the Perforce Server, send a five-byte RPC header specifying a length<\/em> value of 0x1FFFFFFE<\/em>, and cause the server to allocate 0x1FFFFFFE<\/em> bytes (about 537 MB) of memory. An attacker could exploit this vulnerability by establishing numerous connections and requesting these large memory allocations via each connection, quickly consuming all the server\u2019s available memory. Once available memory is exhausted, the next call to Alloc()<\/em> (step 5 above) will lead Perforce Server\u2019s memory allocator (which happens to be mimalloc<\/a>) to throw an unhandled std::bad_alloc()<\/em> exception from mi_try_new_handler()<\/em><\/a>, causing the Perforce Server process to crash and not restart. This denial-of-service (DoS) attack is exploitable by remote unauthenticated attackers.<\/p>\n

      This vulnerability is now identified as CVE-2023-5759<\/a> and it has a CVSS score of 7.5<\/a>.<\/p>\n

      Investigating RPC handler functions<\/h3>\n

      We showed in the call-stack above that RpcTransport::Receive()<\/em> is called by Rpc::DispatchOne()<\/em>. This latter function takes the allocated buffer received by RpcTransport::Receive()<\/em>, parses it as an RPC command with optional arguments, looks up the handler for the given RPC command, and calls the handler with the received arguments. Many of these RPC commands are mapped to the p4 commands listed here<\/a>. Specifically, there are 202 formally documented p4 commands, and about 450 defined RPC commands, though not all RPC commands have their handlers registered by default at runtime.<\/p>\n

      Since we\u2019re most interested in the possibility of remote unprivileged attacks against Perforce Server in its default configuration, we created our own Perforce client from scratch that attempts to call (without any authentication) each of the approximately 450 RPC commands defined in p4s.exe<\/em>. Of those, we found that about 360 RPC commands have their handlers registered by default at runtime. This is too high of a count to manually assess in a reasonable amount of time, so we had to find other means to prioritize our RPC command analysis.<\/p>\n

      We found that p4s.exe<\/em> statically imports 382 API functions. Of those, we identified the most interesting functions that could potentially achieve remote code execution, assuming an unauthenticated remote attacker could both execute an RPC function that calls one of these API functions and control the arguments to that API function. These functions are:<\/p>\n