Interfaces and Security

Small incarnations are some times best to illustrate cognate larger issues. Today, I literally came across such a small incarnation while passing the building of the "Bundesrat", Germany's Federal Council. In front of one of the entrances is an information kiosk system that allows browsing of a web site containing information nobody is interested in. While walking innocently by the kiosk system and noticing that, in contrast to many other public terminals, this one was actually turned on, not significantly demolished or graffiti decorated and did show the intended content, a message box appeared.

I'm quite used to computer systems crashing for no apparent reason other than my personal proximity, so I were not really surprised to see a Windows message box proclaiming that Internet Explorer had just died and asking if a report of the accident should be sent to Microsoft. This did spark a little interest, so I stopped and walked over to the kiosk box.

Kiosk systems are by design meant to hide the original operating system user interface from the person using the kiosk. I vividly remember many years ago, the direful task of creating such a kiosk system was given to me. To make a long story short, even with specialized kiosk software, it is almost impossible to setup a system in a way that the kiosk mode will provide real web browsing experience but the user will be unable to influence the underlying operating system. It has been shown countless times that there is almost always a way around it. By now, it has become a hobby for many people to break into kiosk systems in airport lounges during the 5 to 10 minute delay before boarding the plane. Actually, the delay is usually much longer, but the kiosk is just good for 5 minutes of fun. At one occasion, the airline lounge people just covered the kiosk by a hand-written "out of order" sign to prevent further misuse, since the kiosk would show an open cmd.exe shell (with NT Authority/SYSTEM privileges) instead of the airline's home page.

So it was no surprise that the little crash report dialog window did indeed provide the expected way around the user interface limitations put in place by the kiosk setup. In this case, it was by simply clicking on the "Microsoft data collection policy", which opens another instance of Internet Explorer. From here, it is just "File", "Open" and a short navigational challenge getting to c:\winnt\explorer.exe using a not-so-small finger and a touch screen that is wet from the rain.

The reason kiosk systems almost never provide the security their makers think they do is simple: Windows was never built to prevent authenticated users from accessing the user interface. While Vista improves significantly on the distinction between a logged on user and a process running under the user's context, even (some times especially) Vista relies on the fact that the OS and the processes running in it have real time access to user interaction functionality.

A kiosk system, on the other hand, must provide the user interface more in the way of a web server providing its content: if you are in doubt, just don't do it. Therefore, the decision to display anything to the user must be made by the kiosk software and not by any other part of the system. Or, in other words, the security functionality of the kiosk system lies in its ability to decide under which circumstances it should extend the possibility for interaction to the user. Which is of course not the way Windows is built.

I have worked with companies that made ATM systems. Due to their obviously higher interest in the security of their products, they invested a lot more time into this issue and basically ended up with an identical concept. The same applies to most ticket machines I have seen from the inside. While many of these systems are based on Windows as well (and some still on MS-DOS), the display and interaction decisions are centrally embedded in kernel space to prevent any process, may it be part of the system or not, from influencing the security relevant interface between the machine and the user.

Kiosk software following the approach of using a standard system and an arbitrary browser and then trying to hide everything else from the user will never work. That's simply because the software would now have to guard every possible way a process can open, modify or close a window on the system - very unlikely for a user land program. I have seen approaches of programs sending "minimize" window messages to every but their own window and claiming to have solved the problem, until they discovered stay-on-top modular message boxes.

It should (hopefully) be clear by now what larger issue I was referring to in the beginning: When designing and building a system, it must be clear which interfaces provide security and validation. Once these are identified and classified, the components providing said security must be designed. If the interface in question can be used by anything else than the product itself, the security components must be placed at a neuralgic point where they can guard the entire interface, not just the part that obviously belongs to the product. Or would you install a PHP remote command shell on the same web server that runs your online banking application?