Translate

Friday, 7 February 2014

Raymarine Reply

kplex user Cardo posted a link to the previous article on Raymarine's Facebook page.  Not only did this elicit a response from Raymarine's product support manager, he also copied the response to me in email.

The main part of the reply was a defence of Raymarine's wireless security, which I didn't criticise, saying only:
All wireless security was off on the MFDs, presumably for show convenience as according to the manuals this is not the default. 
My actual criticism was of the apparently redundant services running on the MFDs, but Raymarine's response is to assure us that these are all either part of "show mode" or deliberately enabled as part of the system's operation.  The services have been tested and are all "benign".  This does slightly miss the point that the objective of running  fewest possible services is not to avoid those with known problems but to minimise the threat from the problems which you don't know about yet and can't test for.

The other part of my criticism and what actually prompted me to write in the first place was the way in which mails to Raymarine simply weren't replied to.  Did they really have to wait for someone to post something on social media to get back to me rather than just replying to me in private in the first place?

I'll have to wait to see how one of these systems looks different in "normal" operation, but if anyone has one of these MFDs please do sick nmap on it and post the results as a comment.

My guess about this being an off-the-shelf OS with services accidentally left running was incorrect.  These services were deliberately enabled.  I still find the idea that telnetd and sshd and ftpd are all required intriguing.  Perhaps also whatever processes require NFS file sharing could enable the processes only when they have something to share and leave them disabled the rest of the time?

As well as my Facebook reply, I also replied (at slightly greater length) by email and got a response re-iterating that all running services were necessary and that reasons why could not be discussed as the workings of Raymarine's software were confidential.  The issue of default passwords which I raised in both replies was not addressed.

So how much of a problem is this?  Recent reports have publicised "smart" devices such as fridges and TVs being targeted to be used as spam relays.  A Raymarine MFD isn't a dumb piece of electronics, it's a full blown computer.

To a large extent though Raymarine are right: this is a lot of fuss about nothing.  The effect of idle, unused services like this on performance will be negligible.  On the security front their MFDs have been engineered as a gadget which is not designed to be deployed in a "hostile" environment and in the main this is a fair assumption.  The wireless networking on Raymarine's MFDs are not designed to play well with an existing wireless network which may be connected to the network: They create an isolated one for the specific reason of communicating with devices running Raymarine's own and partners' apps.  Bad news for owners who then need to flip between wireless networks to view their instruments and browse the web, but also bad news for potential malware writers wanting to turn your MFD into a spam bot.  Malware which first infects a user's PC, then targets the MFD (probably a different OS and architecture) then adjusts the routing table on the off chance that the user has connected their MFD's ethernet to an Internet connected network is, frankly, tenuous.  Most consumers would doubtless prefer rich functionality over unnecessarily paranoid security.  Really this is not something to get worked up about.

It's only a matter of time however before connecting a boat's network to the Internet becomes the norm and MFDs start to be able to leverage data from the Internet in their operation (Grib downloads? Software updates?).  Time will tell if the MFD of tomorrow looks a little more secure to the casual observer.

No comments:

Post a Comment