# Analyzing Impact and Systemwide Effects of the SlowROS Attack in an Industrial Automation Scenario
## 2 Related Work
### ROS Security  
The security of ROS 1 has been the subject of a fair amount of scrutiny by researchers and practitioners alike, especially since it gained traction for industrial applications. Initially, researchers [26; 27; 28] focused on the lack of enforceable authentication and encryption between ROS nodes, which makes them susceptible to replay attacks and service hijacking. However, they did not consider denial of service (DoS) attacks specifically and did not provide any details about their execution. Later work [29; 30] discussed ROS penetration testing and demonstrated more elaborate attacks that crash or disable some ROS nodes, thus making the services they provide unavailable to other nodes and, eventually, making the ROS system as a whole inoperable. Although the final result of those attacks is similar to the ones presented in this paper, in their case, the attack strategy is radically different. In fact, they leverage specific software vulnerabilities (for instance, CVE exploits), rather than a slow DoS attack strategy. Even a recent comprehensive review of ROS security [31] still does not mention slow DoS attacks at all. Moreover, the official \"Python library reference\" [32] warns that the xmlrpc.server module--used by the ROS communication layers--is not robust against _maliciously crafted_ data. However, it does not mention the possibility of perpetrating attacks by means of _legitimate_ data as the slow DoS attack proposed in this work does. Finally, a query performed on the Common Vulnerabilities and Exposures (CVEs) list at the time of this writing with \"ROS\" as the search term [33] returned 114 records. Of them, 82 were disputed, and hence, were not further considered. Of the remaining 32, 19 pertained to other products with a similar name (for instance, the Rugged Operating System by Siemens) and 2 were about ROS 2, leaving 11 records related to ROS 1. A further refinement of the query including \"noetic\" as the search term eventually returned two records, CVE-2020-16124 and CVE-2021-37146. CVE-2020-16124 discusses an integer overflow or wraparound vulnerability in the XML-RPC library, while CVE-2021-37146 reports an infinite loop in the XML-RPC server that may be triggered by a malicious RPC call. Neither of those vulnerabilities nor their underlying operating principle have been exploited for the attack discussed in this paper, thus confirming that the attack is, in fact, novel. The mitigation techniques discussed so far in the literature belong to three broad categories. The first category aims at _preventing_ attacks, for instance, by means of additional security-oriented components, like Rosbridge and SROS. Rosbridge is a WebSocket-ROSbridge that grants web applications controlled access to ROS nodes, and can indeed prevent attackers from reaching the ROS system directly from the Internet. However, it may be ineffective against insider threats, which act from the private side of the industrial network. SROS adds TLS support to the existing ROS protocols but is currently still experimental and has no longer been maintained since 2022 [34]. The recommendation of restricting access to the ROS network by isolating it from the Internet, advocated by the official ROS documentation [35], belongs to the same category. Nonetheless, this policy may be hard to enforce, considering that a relatively recent study [36] found a plethora of ROS systems that were indeed publicly reachable. The second category of mitigation techniques aims at _detecting_ attacks instead, usually by means of machine learning algorithms [37; 38; 39]. To the best of the authors' knowledge, none of the existing work considers slow DoS attacks, focusing instead on data injection attacks [37] or on traditional DoS attacks [38] involving large amounts of illegitimate data. The use of deep reinforcement learning to identify vulnerabilities in ROS-based robot navigation is explored in [39] but without explicitly considering DoS attacks.