On 13/03/2024 17:02, Peter wrote:
May I ask a stupid question?
I have developed a product which uses MbedTLS 2.16. I am on this mailing list so I get to see the various updates since.
And I wonder: is there any point in upgrading?
If your embedded product is a client, and usually behind NAT (or an equivalent firewall) and accessing some private server (or a trusted public server) on a schedule of its own choosing, then the whole attack surface is minimal.
Sorry, that's just not true. IoT devices are massively used as relays to attack local networks. Mirai (https://en.wikipedia.org/wiki/Mirai_(malware)) was a famous example recently, having infected millions of IP cameras. And this keeps happening https://thehackernews.com/2023/02/new-mirai-botnet-variant-v3g4.html and happening https://arstechnica.com/security/2023/11/thousands-of-routers-and-cameras-vulnerable-to-new-0-day-attacks-by-hostile-botnet/.
Surely IP cameras (those I have known) contain a server, which many users install on an open port. This was the principal usage model for the original AXIS cameras. You could even find them with a suitably formed google search!
If the camera was a client, uploading images or a video stream to a server (which has a properly secured user side) how could the camera be attacked? It will be behind NAT, for a start.
( )
Basically, as you can see, I see the only valid applications for MbedTLS in scenarios where a) the box is a client and b) you control the other end's server (or, if you don't control it, you are prepared to periodically revisit your code and fix it whenever the server's owner has changed the crypto suite or whatever).
A lot of devices running Mbed TLS are small servers to which even smaller devices connect to (e.g. a WRT or similar linux server that acts as a gateway for a bunch of microcontrollers).
OK, but the that is either a vulnerable scenario, or the server is on some private LAN.
ISTM that the general drift in the IoT sphere is indeed along the lines I describe. It "incidentally" also delivers a revenue stream because you can charge the customer for that server ;) Whereas if you just sell a box, you have no business model for funding long term functionality.
Well, I'm an Arm employee and our revenue is basically from the sales of boxes. Upgradability is a thing we're throwing in for free. Mbed TLS is part of Arm's Platform Security Architecture (PSA) https://www.arm.com/architecture/security-features/platform-security reference implementation. The reason firmware update is part of PSA is that we don't want our customers/users to be the next Mirai victims.
My point is that most/all of the perceived vulnerability is present only if the system is stupidly set up (e.g. an embedded box is a server and on an open port). And a client accessible on an open port is just silly (pointless).
The situation we have now is that some customer, who does not understand the issues, will constantly be demanding the latest MbedTLS version, in the belief that the box you are selling is somehow "insecure".
And this is very hard to support if you are a small company, say < 1M sales. I reckon to go from v2 to v3 will cost some 5 digits in implementation and testing cost, and this is repeated a few times a year. But the extra security is *nil* unless the system is stupidly configured, and then the "box" will still be hacked, just a bit later, by somebody just a bit more clever than the last guy.
MbedTLS is open source which obviously has advantages, but also has huge disadvantages: everybody knows where to start hacking. At work we have an open source online shop (Magento) which has a poor hacking history (basically the only way to run it is to use a 3rd party payment processor so your shop never sees CC details, so there is nothing for the chinese/russian hackers to steal). All open source forums (e.g. PHP-BB) have been repeatedly hacked. Very little OS "internet" code is secure; just the heavy duty stuff, with huge user communities, seems to work well.