Why Trusted HMI Engineering Toolchains Remain a Blind Spot

The talk opens with the maritime software chain, from equipment vendor to shipyard to classification society to the bridge HMI. The speaker, Younghoon Noh of the maritime security firm CIDR, argues that the engineering tool used to build those HMI applications, and the project files it produces, sit outside the scope of IACS unified requirements E26 and E27. Those requirements test the delivered equipment at approval, but not the tool that consumes project files, so the tool's handling of untrusted input goes unchecked.

The researchers analyzed one HMI builder and reported seven vulnerabilities to KISA through Korea's coordinated disclosure process. The findings fall into four groups: memory corruption while parsing project files from three input formats, which can lead to denial of service or code execution; DLL search path hijacking and loading of unsigned components; silent font installation that can spoof the operator's screen and expose the rendering path; and OPC UA sessions accepted without any security profile, with plaintext fallback. Eunji Choi presented the library loading, font, and transport classes, and walked through a scenario in which a malicious project passes review, gains trust through approval, and then runs its payload on board.

The closing argument is that type approval at delivery does not cover ships that stay in service for decades. The speakers asked for four changes: extend scope to the build tools and the components they load, track vulnerabilities continuously, require a published disclosure policy and an SBOM, and revalidate after security-relevant changes. Full details are to follow once the disclosure window closes.