Recently I was evaluating the Thin Client solution from Sun, "Sun Ray", and one thing caught my attention.
The Sun Ray clients run only a firmware, without OS. The firmware is responsible for getting the initial settings from a DHCP server, incluing the address of the Sun Ray Server. Once the client establishes a conversation with the Server it uses a X11 emulation over UDP, using a Sun protocol called ALP (Appliance Link Protocol). If there is a firmware upgrade the client downloads it from the server when powering up.
Hey! So the client receives the information about who is the Server from a DHCP response. Yes, and this is server is the one who sends the new firmware. Then, if anyone can forge a DHCP response, he can then send a contaminated firmware to the client. Is anyone looking at the Sun Ray firmware characteristics to find how much one can hack with it? The clients has a syslog reporting feature, for example. What if someone alters the firmware in a manner that the client sends the keystrokes to a syslog server? Wow.
Well, I think that network based (switches features) controls can be used to avoid those bogus DHCP responses, but I really don't know if there is such granularity today.
And what if my network uses 802.1X authentication? Obviously it will need to be disabled where the Sun Rays are being used. Bad thing. However, I think the risk from this issue can be truly reduced by ACLs and PVLANs.
One of the sales arguments from this solutions is security. Using Java Cards for logon and so on. But what about these network level issues? If the device does not havr any static setting (another sales argument), even a server identity check is hard to be implemented. Perhaps using some kind of challenge-response with the Java Cards, I don't really know if it's possible.
Well, these are some of my random thoughts about this subject. If anyone out there has already made an anlysis on those issues, I'd really like to know the conclusions.