Modern technologies are not stopping at the IT/OT border and just as more and more Internet Things are creeping in (wirelessly and thus highly mobile – are you sure that all of them are yours just because they are able to find your network) modern software technologies are doing it, too.
Web-based user interfaces are hardly anything new, we have seen them in use at HMIs and operator workstations for years. Nice, flashy, can display diagrams your process and are making life easier. But many of these things are becoming more than just fancy input/output devices sending data to the central servers. Web browsers have become the universal canvas for GUI applications that need to run on any device with a display (a late consequence of having so many different GUIs and libraries to write programs for them around). Today you’ll find complex JavaScript/ECMAScript/TypeScript applications running on your phone and sometimes even communicating with peripheral components of complex Industrial Control Systems (not too long ago we found JavaScript tools configuring Emerson DeltaV controllers).
Millions of people are using JavaScript every day. How can that technology be so dangerous if it is widely spread? Yes and no. Browsers (which contain most of the JavaScript environments) are receiving regular updates at short intervals and most of these updates are not just additional features. Just take a look at the documented new ingredients in Chrome or Firefox (most patches are showing up in their change logs).
JavaScript is an interpreted language and as such has to be translated into something the computer it is running on can really execute. The longer and more complex the programs written in such a language are getting (just look at the name – “script” implies something simple and short) the longer the translation into executable code will take. One of the first shortcuts around that was the arrival of Just In Time (JIT) compilation: The script will be translated at the time it is executed (and parts that never run will not require even that).
This sounds like a good idea. But (there always is a but and sometimes it can hit like Bud Spencer) this technology is breaking one of the more important methods to keep malware away: The separation of executable and writable memory. As long as it is not possible to either overwrite the executable code nor execute anything that is (modifiable) data a lot of possible entry points for malicious code are barred. But a JIT compiler is exactly that, It turns data into another representation and then executes that. And if the compiler has exploitable weaknesses it becomes a door opener for any kind of unpleasant things and after having found malware that was introduced to the workstations of lab equipment like chromatographs by playing multiplayer games on the Internet I don’t really believe in “this can’t happen” anymore.
At the same time the execution environment (aka as “web browser”) has become an integral part of the OT equipment and even if it is not validated device in food production or healthcare which caused many vendors to require certain closely specified browser versions that can’t be updated in a timely manner (or at all without the vendors’ permission). This situation is getting worse if multiple applications of different vendors are executed on the same “terminal”.
Take the step back to writing OS- and UI-specific applications again after having moved the pesky “user experience” thing to the web designers? Execute external programs from the web browsers?
It’s obvious that there is a need for a clean, sandboxed and safe execution environment for arbitrary code in the browser. The Java train has left the station years ago; while the Java VM (JVM) is a very good environment for secure code execution the language is… awkward. To avoid using it lots of new languages were invented and old languages (including even COBOL, Fortran and Rexx, but also Python) got compilers producing JVM “machine language” (JVM byte code). .Net was seen as too Microsoft-focused and never gained that much traction. But conceived in 2015 (20 years after JavaScript) and born in 2017 there is a new take on the same problem: WebAssembly. At it’s core it is a virtual processor that is easy to implement correctly on nearly everything that can be programmed at all (and the NASA Apollo Guidance Computer is demonstrating quite impressively why these interpreted byte codes can turn nightmares of CPUs into something really useful), it can be sandboxed in a way that anything going in and out of the box can be kept under control and it can interface well with JavaScript to move the GUI part completely outside the application logic that is running inside its one or many sandboxes. Originally intended for exactly this purpose, WebAssembly can also be executed in stand-alone environments (just like Java byte code is executed in stand-alone Java Runtime Environments) which is making it even more useful as the same code and data structures can be used on the server side of applications permitting moving the things that should not or can’t be done inside the user-facing application.
WebAssembly is language-agnostic. To quote webassmebly.org:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
You really want to write the application logic of your engineering station in Algol? Be my guest. You do not want to lose your investment in clean, not self-modifying ECMAScript? The same. Just to prove Nikolaus Wirth there is a Wasm execution environment written in Wasm. You have some .Net code that needs that needs to make the move? Even Microsoft’s Mono CLR is available as Wasm.
Summary: If you want your complex OT application running on the front end,If the beer is not making sufficiently sleepy I could use you as “spelling rectifier” 8-) ask your vendor about his security concept for browser-based software and how they are implementing it in a sustainable way.