|
> Considering the recent bug discovered in Go's runtime, we can say definitively (not merely "likely") that moving away from Go 1.7 would resolve at least one invalid memory write bug. If you're making the point that using Go or Rust doesn't make you completely immune to security problems, I agree. But on balance, I think it makes you significantly better off. As for this specific bug, I expect the fix to be backported to Go 1.7 if it hasn't been already, and ideally these devices would receive updates occasionally...although I know that isn't actually happening for many deployed devices... (btw, I'd say "likely" rather than "definitively". That looks like a bad bug, but I can imagine a reasonable system that it doesn't apply to. They might not have a goroutine whose stack ever grows ever select simultaneously on the same channel as another goroutine, for example.) > The most complex protocol typically often seen on IoT devices is HTTP. It's trivial to implement HTTP in C without any buffer overflows You might be able to write a buffer overflow-free HTTP implementation, but "trivial" is a funny word. Would you still call it trivial if I pointed you at a list of buffer overflow bugs in C HTTP implementations? Does your calling it trivial fix all the buggy devices? If not, what relevance does your calling it trivial have to the security properties of widely deployed implementations? These devices implement a variety of other protocols. I own some security cameras that implement at least: DNS, DHCP, UPnP, SNTP, RSTP, RTP, SNMP, SOAP, ONVIF, SMTP, SMB, SSH, a few custom protocols based on HTTP or directly on TCP. Some other likely protocols for IOT devices include SIP, IPP, and OAuth. And those are just off the top of my head. Maybe you consider each simpler than HTTP (and I'm uninterested in debating the ranking of protocol complexity), but collectively they represent a large increase in attack surface, and I'd be shocked if any of the protocols on that list didn't have widespread implementations with buffer overflows bugs. I hear your point about the lack of implementation diversity being a significant risk to using these languages, but I think you're underestimating the scope of the security problem. |