Advice for IoT vendors to improve security? Build and use modern compiler toolchains w/ safety features enabled. Read the CITL study that evaluated 1.3k IoT products across 15 years; showing the largest poor security issues and downward trends: cyber-itl.org/2019/08/26/iot…
If you could give one piece of advice to IoT vendors to improve their security as a whole, what would it be?
10
84
15
259
This isn’t as straight forward as it may seem. Many think ARM is the dominant architecture but it’s not. MIPS is more common for IoT by far. MIPS has by far the weakest basic security hygiene. Yellow bars are arch binaries (y axis right), red is SDLC hygiene (y, axis left)

12:15 PM · Aug 2, 2020

2
4
1
17
But on MIPS if a Linux Kernel if 2.4.3.4 thru 2.7 means your app will likely crash if you try to make the stack non-executable. So you need your IoT device to be at least Linux kernel 2.8 to support this **most basic exploit mitigation**!! But it gets even trickier...
3
1
0
14
Linux Kernel 4.8 and above support marking the stack non-executable (a super basic security/safety feature that all apps should have). Unfortunately the kernel fix enabling this introduces a new fixed address RWX mapping... defeating both DEP and ASLR. It gets trickier. Sigh...
1
1
0
10
So your IoT is on the most prevalent architecture (MIPS). You have a foundation of Linux w/ a kernel of 2.8 or above and you ***rebuild the Kernel removing floating point support*** to address all of this. Assuming your IoT even works now, you still need a build toolchain. ...
1
1
0
9
The most common GCC toolchain for MIPS, available as stable through the main distro package managers, can’t emit a binary with the stack marked as non-executable. So the toolchain for your commercial product needs to be built from a compiler in the unstable branch(?!). And,
2
3
0
15
with your toolchain for your commercial IoT product being built from the unstable/experimental GCC toolchain the default is still an executable stack. So you still need to explicitly enable this most basic security feature after all that. The take away?
2
1
1
11
Try to build your IoT devices/software on architectures having the most modern toolchain available, that creates safer binaries with just default settings. Presently that is ARM, which is a distant second to the much more prevalent deployment of MIPS (with all these issues).
1
2
0
16
That’s a lot to ask of IoT vendors just to get the simplest of exploit mitigation features (available elsewhere for 20+ years). And also put in simple unit tests to catch basic safety features being accidentally removed. Think such unit tests are silly? Check this out...
1
1
0
16
Here’s Ubiquity, a vendor I like, where they lost ASLR, Stack Guards, and RELRO over time for a product line. Simple security unit tests on binaries creates in the dev lifecycle would catch this.
2
4
2
29
It’s not just IoT vendors. Mozilla Firefox for OSX lost ASLR for a while. The team forgot about the issue and even challenged CITL’s (cyber-itl.org) finding, until they looked for themselves. They fixed it and I believe have unit tests to spot this going forward now.
3
6
1
28
All of this goes well beyond wacky IoT devices. Your wireless access points, routers, etc. are runnin on top of these same core systems. Not to mention more and more medical devices. EOF
1
1
0
24