The Unchecked Canvas: Smashing the Stack in JTEKT HMI Designer

In the world of Industrial Control Systems (ICS), the engineering workstation is the crown jewel. It's the machine where the logic for PLCs is written and where the screens for Human-Machine Interfaces (HMIs) are designed. If you compromise the workstation, you own the factory floor. Enter JTEKT Screen Creator Advance 2, a piece of software used to design the touch interfaces for JTEKT's industrial displays.

File format parsers are the soft underbelly of ICS software. These applications are built to ingest complex, proprietary file formats (often legacy binary blobs) that define everything from button placement to macro logic. CVE-2023-22345 is a classic example of what happens when a parser trusts its input too much. It’s a vulnerability that turns a mundane design file into a weaponized payload capable of executing arbitrary code on the designer's machine.

Why is this interesting? Because it targets the human element. You don't need to bypass a firewall to exploit this; you just need a frustrated engineer to open a "troubleshooting" file you sent them. It's a client-side attack against the people holding the keys to the physical machinery.

The vulnerability is an Out-of-bounds Write (CWE-787), but the root cause is a failure of logic rather than just a simple calculation error. According to the analysis, the issue resides in how the software handles "out of specification" errors during the parsing of project files.

When a robust parser encounters data that violates the file format specification (e.g., a button width defined as 40,000 pixels on a 1080p screen), it should throw an exception and abort the load process. Screen Creator Advance 2, however, exhibits a fatal stubbornness. It seemingly detects the error—recognizing the data is "out of specification"—but fails to stop the processing pipeline.

Imagine a construction crew building a bridge. The blueprint says to use a 10-foot beam. The truck delivers a 50-foot beam. The foreman notes, "This is the wrong size," in a logbook, but then tells the crew, "Install it anyway." The result is structural failure. In software terms, the application continues to write the malformed data into a fixed-size memory buffer, causing an overflow that overwrites adjacent memory, potentially including return addresses or function pointers.

While the proprietary source code isn't public, we can reconstruct the logic flaw based on the vulnerability behavior. This pattern is distressingly common in legacy C/C++ parsers where error handling is an afterthought or where developers try to make the software "robust" by ignoring non-critical errors.

The Vulnerable Logic

In the vulnerable version, the parser likely checks for validity but forgets the most important part: the return statement.

// Pseudo-code reconstruction of the flaw
void ParseProjectElement(char* inputData) {
    ElementHeader header;
    memcpy(&header, inputData, sizeof(header));
 
    // 1. Validation Step
    if (header.dataLength > MAX_BUFFER_SIZE) {
        // LOGIC FLAW: The error is logged/flagged, but execution continues!
        LogError("Error: Data length out of specification");
        // Missing: return; or goto error;
    }
 
    // 2. The Corruption
    // The code proceeds to use the bad length because it wasn't aborted.
    // This writes past the end of 'destinationBuffer'.
    memcpy(destinationBuffer, inputData + sizeof(header), header.dataLength);
}

The Fix

The remediation in Ver.0.1.1.4 Build01A involves strictly enforcing the error condition. When the parser detects data that is out of spec, it must immediately halt processing to prevent the dangerous memcpy or write operation.

// The patched logic
    if (header.dataLength > MAX_BUFFER_SIZE) {
        LogError("Error: Data length out of specification");
        // FIX: Abort the operation immediately
        return ERROR_INVALID_FILE;
    }

This simple addition of a flow control statement prevents the instruction pointer from ever reaching the memory corruption routine.

Exploiting CVE-2023-22345 requires a standard file format exploit chain. Since this is a Windows-based application, the attacker needs to craft a file that bypasses modern mitigations like ASLR (Address Space Layout Randomization) and DEP (Data Execution Prevention).

Step 1: File Format Reversing The attacker starts by generating valid project files and fuzzing them. They mutate specific fields—lengths, offsets, and counters—looking for crashes. The goal is to find the specific field that triggers the "out of specification" error path.

Step 2: Triggering the Overflow Once the crash is identified, the attacker refines the file. They set a length field to a value larger than the allocated buffer. When the user opens this file, the application attempts to copy the attacker's payload into the buffer. Because the length is unchecked (effectively), the copy operation smashes the stack or heap metadata.

Step 3: Gaining Control If it's a stack overflow, the attacker overwrites the Saved Return Address (SRA). When the parsing function attempts to return, it pops the attacker's address off the stack instead of the legitimate caller's address. If it's a heap overflow, the attacker might corrupt the Free List or C++ vtable pointers.

Step 4: ROP Chain and Shellcode To bypass DEP, the attacker constructs a Return-Oriented Programming (ROP) chain—small snippets of existing executable code—to mark their shellcode region as executable (e.g., via VirtualProtect). Finally, the execution flows to the shellcode, which likely opens a reverse shell back to the attacker.

[!NOTE] This is a "User Interaction Required" (UI:R) vulnerability. The exploit doesn't work by staring at the screen; the victim must actively open the file. This makes it a prime candidate for spear-phishing campaigns targeting OT engineers.

Why panic over a desktop app vulnerability? Because of where it sits. Screen Creator Advance 2 isn't installed on the receptionist's laptop; it's installed on the Engineering Workstation.

1. Lateral Movement: Engineering workstations often sit in a unique position in the network topology. They have one leg in the corporate IT network (to receive email/files) and one leg in the OT/ICS network (to push programming to PLCs and HMIs). Gaining RCE here bridges the air gap.

2. Project Tampering: An attacker doesn't just have to run ransomware. They can subtly modify legitimate HMI projects. Imagine altering the "Emergency Stop" button logic on a foundry control screen so that the UI shows "Stopped" while the furnace continues to heat up. The physical consequences of integrity loss in this environment are catastrophic.

3. Intellectual Property Theft: Project files contain the entire logic and layout of a manufacturing process. Stealing these files gives competitors or nation-states a blueprint of the facility's operations.

JTEKT has released a patch, and applying it is the only reliable fix. The vulnerability logic is hardcoded into the binary; no amount of firewall rules will fix a broken parser.

Immediate Action: Update to Screen Creator Advance 2 Ver.0.1.1.4 Build01A or later. This version correctly implements the error handling logic, ensuring that "out of specification" data terminates the parsing process safely.

Process Mitigation: Implement strict file hygiene. Engineering workstations should be treated as secure enclaves. Do not download project files from the internet or open email attachments directly on these machines. Transfer files via a sanitized USB or a secure file transfer gateway that scans for anomalies, although custom file format fuzzing by security gateways is rare.