What about using a language immune to buffer overflow for the embedded controller? I know such languages can be made. (For example, one could implement a Smalltalk using formal methods, with an eye towards eliminating buffer overflows.) I'm not sure there currently exists a language suitable to implement such embedded controllers.
(Smallest Smalltalk image I know of was 45k. Squeak can be stripped down to ~ 350k, which is about half the size of Perl's runtime footprint in the 1990's.)
The people implementing these images don't even care enough to have their code reviewed (the vulnerability here appears to have been trivially fuzzable). They aren't switching to Smalltalk to deal with a problem they haven't even considered.
I'm not a "security expert", but it seems to be problem #1 with your approach is that C just totally dominates the mindshare in the embedded space, and until you solve that problem and its underlying causes, you have lost before you start. The average developer simply doesn't think security is a problem unless you exploit it right in front of them, a goodly number of those people will still deny it's a problem, and a good fraction of those who do agree it's a problem will declare that only C has the performance they need, with no interest in either a debate about the matter or the presentation of a language just as performant as C but also more secure.
Personally, I value security, and I think the evidence at this point is that you have to be a freaking genius to almost correctly code C programs and that's just not scalable, and thus the first thing I'd do is cross C off my list and just live with the results... but then, I'm not an embedded programmer, either. It was time for C to be taken out back and shot in 1980, before the world was networked together, but here it still is, providing us exploits by the cartload. Hooray.
("What should have replaced it, then?" Pick your choice of safe C dialect, which is a productive Google term. I don't deny C's performance or nature as "portable assembler", what I deny is that either of those two things necessarily requires security vulnerabilities to come in by said cartload.)
I'm not a "security expert", but it seems to be problem #1 with your approach is that C just totally dominates the mindshare in the embedded space, and until you solve that problem and its underlying causes, you have lost before you start.
"My approach" is not to do all embedded development in Smalltalk. I'm only applying facts from the language I know the best (not only as a user but from an implementation standpoint) to discuss what must be possible.
I was taking your larger first sentence. You don't even necessarily have to freak out an embedded programmer to get closer to secure, there are a variety of "safe" C dialects. (I don't know enough about them to even begin to judge them, but I don't deny that it ought to be possible.)
But I do think once you shook The Establishment free of C that they would not necessarily move to C+-; there would be a window to wedge some other things in there.
What about using a language immune to buffer overflow for the embedded controller?
I don't do anything with embedded controllers; but on FreeBSD I'd say that buffer overflows are responsible for at most 10% of the security issues we run into.
Eliminating buffer overflows is good, but make sure that you don't miss the pine forest because you're spending all your time looking for oak trees.
Of course. My point was just that there's more to worry about than just buffer overflows, and switching to a language which help you avoid buffer overflows is a rather drastic step to take to address just one type of vulnerability.
(Smallest Smalltalk image I know of was 45k. Squeak can be stripped down to ~ 350k, which is about half the size of Perl's runtime footprint in the 1990's.)