{"id":"8bad6e39-c2c9-45e6-b434-7b07b966cd16","arxiv_id":"2411.16518","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Fort, a widely used RPKI validator, has a stack buffer overflow in key-usage extension handling (CVE-2024-45237) that can enable remote code execution.","lead":"This paper finds a serious buffer overflow bug in Fort, software that validates RPKI routing security data, which can let a remote attacker run their own code on the machine running it. The authors show how easy it is to trigger the bug from the Internet and argue that RPKI makes such bugs especially dangerous.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The unqualified RCE claim depends on a non-default, protection-disabled build; the live scan counts versions, not exploitable binaries.","rationale":"The strongest part of the paper is the concrete source-level bug: Listing 1 copies ku->length attacker-influenced bytes into a 2-byte stack buffer with no length check, and the local-repository experiment reproduces the overflow. That part is internally consistent. The weak link is the step from 'stack overflow exists' to 'remote code execution on real Fort deployments.' The only RCE proof disables the very protections that modern toolchains commonly enable, and the default-configuration experiment stops at a stack-protector crash. The live survey identifies only versions, not binary hardening status, so the claimed population of exploitable systems is unknown. This does not invalidate the vulnerability or the CVE; it means the severity claim is configuration-dependent and should be reported as such. The backdoor discussion is explicitly hedged and is not load-bearing. Since the reader's CONDITIONAL verdict already conditions on exactly this gap, no verdict change is needed.","tokens_in":5076,"tokens_out":14370,"duration_ms":143508,"concrete_test":"Rebuild Fort 1.6.2 from source under three configurations: (a) the authors' PoC flags (no fortify, -fno-builtin-memcpy, no stack protector), (b) the flags used by the upstream release process or the official Docker/package build, and (c) common distro-hardening flags (-O2 -D_FORTIFY_SOURCE=2 -fstack-protector-strong). For each build, disassemble handle_ku to confirm whether the memcpy into the 2-byte stack buffer survives, then replay the 13-byte malicious object through a local CURE repository and record whether the outcome is a shell, a crash, or a clean rejection. If builds (b) and (c) do not yield a shell, the abstract's unqualified RCE claim must be narrowed to non-hardened builds.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central inference is from the unchecked memcpy in Listing 1 to 'an attacker can achieve RCE on machines running Fort.' The source-level primitive is real, but the only demonstrated RCE is in a deliberately non-hardened build: the §2 PoC disables _FORTIFY_SOURCE, uses -fno-builtin-memcpy, and omits -fstack-protector-strong. In the §3 local-repository experiment run in a default configuration, the same overflow is caught by the stack protector and Fort crashes, which is a DoS, not RCE. The assertion that the exploit generalizes to ASLR-enabled setups via partial overwrite or brute force is plausible but not demonstrated. The live measurement reports over 100 systems 'running a vulnerable version' from version strings, but a version string does not reveal compiled flags; the vulnerable source can be compiled into a binary that either contains or lacks the unchecked memcpy. The paper itself documents the compiler dependency in §2, but the abstract and §1 present the result as an unconditional RCE vulnerability of Fort, and §2 claims the attack impacts all globally running Fort RPs. This is the load-bearing gap: the conversion from a real memory-corruption bug to the claimed large-scale RCE impact is not established by the evidence.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reports a buffer-overflow vulnerability in the key-usage handling of the RPKI validator Fort, identified as CVE-2024-45237. It claims that the overflow is remotely triggerable through RPKI publication points and can be escalated to remote code execution on machines running Fort, with severe consequences for RPKI validation integrity, the host, and the local network. The paper also speculates that the vulnerability might constitute an intentional backdoor. The evaluation consists of a local reproduction in which a default-configured Fort crashes under the stack protector, a proof-of-concept RCE in a configuration with compiler protections disabled, and a live measurement that finds over 100 systems running a vulnerable Fort version.","tokens_in":5256,"tokens_out":6000,"duration_ms":54082,"significance":"The paper identifies a real, externally corroborated source-level buffer overflow in Fort, anchored to a concrete code excerpt and a local reproduction, and it provides an ethical live measurement of the Fort population. The CVE assignment and the explicit code-level analysis are strengths, and the paper makes no use of fitted parameters or circular self-justification. If the RCE claim could be substantiated for default or common deployments, the impact would be substantial because relying parties are central trust points for BGP routers. However, the current evidence establishes a source-level overflow and conditional RCE; the large-scale, unconditional RCE impact stated in the abstract and introduction is not yet demonstrated.","major_comments":[{"comment":"The paper's headline claim that 'an attacker can achieve RCE on the machine running the software' (Abstract) and that the attack 'impacts all globally running RPs of Fort' (Section 1) is not supported by the evidence. The only demonstrated code execution is in a local setup 'without enabling compiler protections' (Section 2, Escalation). In the Section 3 local-repository experiment under a default compiler configuration, the same overflow is caught by the stack protector and Fort crashes, which is a denial of service, not RCE. The live measurement identifies over 100 systems running a vulnerable version from version strings, but a version string does not reveal compiled flags; the paper itself states in Section 2 that exploitability depends on the compiler setup. The manuscript must qualify the RCE claim to the configurations in which the overflow is exploitable and present the large-scale impact as an upper bound conditioned on toolchain configuration, not as a demonstrated fact.","section":"§2 Escalation; §3 Evaluation"},{"comment":"The threat model is ambiguous. The text says that an attacker 'only requires control of the default specification of the compiler toolchain to trigger the vulnerability to be compiled into the binary' and proposes injecting a file into a compiler search directory or manipulating the build environment. That is a supply-chain or build-time compromise, which is a different attack from remotely sending a malicious RPKI object to an already-deployed Fort instance. For the remote attack described in Section 2, the target's compile-time flags are fixed at build time and are not controllable by the remote attacker. The paper should separate these two threat models and state explicitly which one each claim refers to.","section":"§2 Compilation"},{"comment":"The evaluation conflates source-level vulnerability with binary-level exploitability. The statement 'all Fort version from Beta-version 2 to version 1.6.2 are vulnerable to buffer overflow' describes the source code; whether a given deployed binary contains the unchecked memcpy depends on the compiler flags used (e.g., _FORTIFY_SOURCE, -fno-builtin-memcpy, -fstack-protector-strong). The live measurement reports client versions, not the set of protections in the executed binaries. To support the large-scale RCE claim, the paper would need to sample the actual toolchain configurations of the observed systems or otherwise bound the fraction that is RCE-exploitable. Without that, the impact assessment remains speculative.","section":"§3 Evaluation"},{"comment":"The escalation to RCE on systems with modern protections is asserted rather than demonstrated. The paper states that ASLR can be bypassed by partial overwrite or brute force and cites [1], but it does not show that the specific primitive—an overflow from a 2-byte stack buffer with the third payload byte constrained to be below 0x8—yields a workable partial-overwrite or brute-force strategy for Fort's binary layout. Because the existence of remote RCE on current default builds is central to the paper's impact claim, this step requires at least a concrete exploit strategy or an explicit statement that no such bypass was implemented.","section":"§2 Escalation"}],"minor_comments":[{"comment":"The first sentence describes the key-usage field as a 9-bit field, while the overflow uses ku->length as a byte count. Please clarify the exact encoding of ku->length (for example, whether it includes the unused-bits octet of the ASN.1 BIT STRING) and state that a normally encoded 9-bit key usage would fit within the 2-byte buffer.","section":"§2 Vulnerable code"},{"comment":"The speculative discussion of an intentional backdoor should be clearly labeled as speculation. The abstract's phrase 'identify indications that the discovered vulnerability could constitute an intentional backdoor' overstates what the body shows, since Section 3 concludes that no operational indications for malicious planting were found and that a copy-paste error is also plausible.","section":"§3 Source of vulnerability"},{"comment":"There is a typo: 'all Fort version from Beta-version 2' should be 'all Fort versions from Beta-version 2'.","section":"§3 Evaluation"},{"comment":"The statement that 'The RP will only log a benign error about a malformed key-usage extension' is vague; please specify the exact log entry and its location, since 'benign' is a strong claim.","section":"§2 Exploitation"},{"comment":"The phrase 'We develop an RFC attack vector' is ambiguous; it should be 'an attack vector based on RPKI objects' or 'an attack vector using RFC 5280 certificate extensions' to avoid confusion with the RFC publication process.","section":"§1 Introduction"}],"recommendation":"major_revision","confidential_remarks":"The CVE and the code-level finding are credible, and the paper is suitable for a security venue if the claims are carefully qualified. The current version's abstract and introduction overstate the evidence; the revision should either present the result as a source-level overflow with conditionally exploitable RCE, or provide data on actual toolchain configurations of the observed systems. The backdoor speculation should be downplayed to avoid giving it the weight of a finding."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a real bug with an assigned CVE, and the authors found actual internet-facing Fort instances running affected versions. The part that doesn't fully hold up is the headline RCE claim, which depends on a compiler configuration the authors do not show exists on any of the measured systems.\n\nWhat's new: first public analysis of an RCE-capable bug in an RPKI relying-party client, CVE-2024-45237. The vulnerable memcpy in Listing 1 is concrete, and the local reproduction with a manipulated key-usage bitstring is consistent with the source. They found the buggy code was introduced in January 2019, affecting all versions through 1.6.2. The live publication-point scan reporting over 100 vulnerable clients, including Amazon and RIRs, is a useful datapoint. The backdoor speculation is appropriately hedged and not load-bearing.\n\nThe central weakness is the gap between the source-level overflow and the claimed large-scale RCE. The only demonstrated RCE runs with _FORTIFY_SOURCE undefined, -fno-builtin-memcpy, and no stack protector. In their own default-configuration experiment, the stack protector catches the overflow and Fort crashes—that's DoS, not RCE. The paper acknowledges the compiler dependence in Section 2, but the abstract and intro state the vulnerability \"allows\" RCE without that qualification. The live scan counts version strings, not compiled binaries, so we don't know how many of the 100+ systems are actually exploitable. The speculation about bypassing ASLR via partial overwrite or brute force is plausible but not demonstrated. Also, the paper ships no exploit code, measurement data, or patch details; some of that is poster-page constraints, but the version-only measurement should be labeled as such.\n\nOverall: the bug is real, the CVE is real, and the RPKI impact discussion is sensible. The paper's own evidence supports a confirmed memory-corruption vulnerability with conditional RCE and likely DoS in default builds. That is still a solid security finding for a poster. But the universal RCE language should be toned down.\n\nRecommendation: send it to peer review. It deserves referee time because of the external corroboration and the importance of RPKI infrastructure. The revision should separate confirmed bug from demonstrated exploit, state the compiler configuration assumptions clearly, and either provide the scan data or explicitly present the limitation.","headline":"Real CVE-backed buffer overflow in Fort, but the RCE framing overreaches the demonstrated, protection-disabled PoC and version-only scan.","tokens_in":5796,"tokens_out":1977,"would_cite":true,"duration_ms":20308,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A buffer overflow in the RPKI validator Fort can let an attacker publish a malicious certificate that executes code on any machine running the validator.","keywords":["RPKI","remote code execution","buffer overflow","Fort validator","BGP","key-usage extension","CVE-2024-45237","backdoor"],"falsifier":"Compile Fort 1.6.2 with a mainstream distribution's default hardening flags (for example `_FORTIFY_SOURCE=2` and `-fstack-protector-strong`), point it at a local RPKI repository containing a certificate whose key-usage bitstring is longer than two bytes, and observe whether the process exits via the fortify or stack-canary check before control flow is hijacked. If it exits before overflow, the specific RCE does not apply to default hardened builds; if it opens a shell or otherwise redirects execution, the central claim is confirmed.","tokens_in":4866,"feed_emoji":"🔓","tokens_out":7940,"duration_ms":66611,"temperature":0.7,"pith_summary":"The paper establishes that Fort, a widely used RPKI validator, contains an unchecked buffer overflow in its handling of the X.509 key-usage extension, and that an attacker who controls an RPKI publication point can turn that overflow into remote code execution on every Fort instance that downloads the malicious object. Because relying parties fetch from all public RPKI repositories, a small attacker with a registered resource can expose the exploit to the entire population of Fort validators at once. A compromised validator can then feed fabricated route-authorization data to BGP routers without forging signatures, allowing prefix hijacks or the invalidation of legitimate routes, and can be used as a stepping stone into the local network hosting the routers. The paper reports that the vulnerable code entered the repository in January 2019, that it affects all Fort versions from Beta-2 to 1.6.2, that over 100 observed live systems run affected versions, and that the issue is CVE-2024-45237 with a 9.8 severity rating. It also argues that the dead-code placement of the vulnerable function has hallmarks of a possibly intentional backdoor, while leaving open that it may be a copy-paste mistake.","feed_headline":"A buffer overflow in Fort lets attackers run code on RPKI validators","feed_subtitle":"One crafted certificate can take over the validator that BGP routers trust.","key_machinery":"The load-bearing mechanism is the unchecked `memcpy` in `handle_ku`, which copies the bytes of an ASN.1 BIT STRING (a length-prefixed byte array used in X.509 certificates) into a two-byte stack buffer according to the string's length, with no upper-bound check. That single operation converts a malformed certificate into a stack write primitive. Exploitation is gated by the compiler toolchain: `_FORTIFY_SOURCE` replaces `memcpy` with a bounds-checking variant, built-in inlining can optimize the copy away entirely, and `-fstack-protector-strong` adds a canary to functions with local arrays; the paper says none of these is explicitly set in Fort's build, so default toolchain behavior decides whether the overflow reaches a compiled binary.","core_discovery":"The central discovery is a stack buffer overflow in Fort's `handle_ku` function. The function copies an ASN.1 BIT STRING from a certificate's key-usage extension into a two-byte local array with `memcpy(data, ku->data, ku->length)` and never checks that `ku->length` is at most two. A certificate whose key-usage bitstring is longer than two bytes therefore writes attacker-controlled bytes into adjacent stack memory. The paper shows that an attacker can meet the surrounding validation checks, publish such a certificate in a live RPKI repository, and overwrite the return address with a 13-byte payload that opens a shell. It argues that all Fort versions from Beta-2 through 1.6.2 are affected, that the bug came in with a January 2019 commit, and that the observed live population includes over 100 systems running vulnerable versions. The paper's proof of concept disables compiler protections, and it states that bypassing ASLR and other mitigations is possible with additional effort.","pith_inferences":["If the version-based measurement undercounts exploitable deployments, the real impact could be larger than the 100+ observed systems, since the internet measurement records versions, not the compiler flags that determine whether the overflow is actually exploitable.","The same pattern of trusting an ASN.1 BIT STRING length without a bounds check may occur in other RPKI validators or forks; a targeted audit of key-usage parsing in those codebases is a natural next test of how general the flaw is.","The dead, unreachable code with a controllable overflow is precisely the signature that tooling could flag: future static analysis could warn on `memcpy` whose source length is parsed from network data and whose destination is a fixed-size stack array and on functions whose output is never used.","If the backdoor hypothesis is ever confirmed or rejected, it would change how RPKI trust should be structured; the paper's evidence stops short of certainty, so the operational takeaway should be to treat RP software as boundary-trust software regardless of origin."],"forward_implications":["If the exploit is valid, any Fort validator that fetches objects from an attacker's RPKI publication point can be remotely compromised, and validators fetch from all publication points by design.","A compromised validator can report arbitrary route-authorization data to BGP routers without producing any cryptographic signature, so prefix hijacks can be made to look valid and legitimate prefixes can be made to look invalid.","Because the RP machine must have network access to routers, the same foothold becomes a launching point for attacks on border routers and other hosts on the internal network.","Fort deployments that cannot be patched immediately need compensating controls such as compiler hardening, not storing router credentials on the RP host, network segmentation, and monitoring for unexpected outbound connections.","The vulnerability's presence across all affected versions means the attack surface is not limited to outdated installations; current-at-the-time Fort 1.6.2 is vulnerable as well."],"supporting_citations":[{"why":"supplies the ASLR-bypass technique referenced in the escalation discussion.","marker":"[1]"},{"why":"provides the local RPKI repository tool used to confirm the crash on Fort 1.6.2 and the prior RPKI vulnerability study cited for context.","marker":"[2]"}],"fun_headline_variants":["Fort RCE via oversized key-usage bitstring","13-byte payload owns Fort, the RPKI validator","CVE-2024-45237: Fort stack overflow leads to shell","One certificate can hijack Fort and open a shell","Fort's handle_ku buffer overflow enables RCE"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The chain from bug to remote code execution depends on the target Fort being compiled with a toolchain that does not activate fortification, stack-protector, or built-in memcpy elimination; the paper's only execution demonstration disables those protections, and its internet measurement records versions rather than compiler flags.","fun_headline_variants_meta":{"raw":{"variants":["Fort RCE via oversized key-usage bitstring","13-byte payload owns Fort, the RPKI validator","CVE-2024-45237: Fort stack overflow leads to shell","One certificate can hijack Fort and open a shell","Fort's handle_ku buffer overflow enables RCE"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000837,"raw_usage":{"total_tokens":3634,"prompt_tokens":910,"completion_tokens":2724,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":526,"completion_tokens_details":{"reasoning_tokens":2641}},"tokens_in":526,"tokens_out":2724,"duration_ms":18932,"temperature":1.0,"reasoning_tokens":2641,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T13:00:34.346867+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compile Fort 1.6.2 with a mainstream distribution's default hardening flags (for example `_FORTIFY_SOURCE=2` and `-fstack-protector-strong`), point it at a local RPKI repository containing a certificate whose key-usage bitstring is longer than two bytes, and observe whether the process exits via the fortify or stack-canary check before control flow is hijacked. If it exits before overflow, the specific RCE does not apply to default hardened builds; if it opens a shell or otherwise redirects execution, the central claim is confirmed.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"supplies the ASLR-bypass technique referenced in the escalation discussion."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"provides the local RPKI repository tool used to confirm the crash on Fort 1.6.2 and the prior RPKI vulnerability study cited for context."}],"review_version":1}