Thread by @ErrataRob

1/ This paper is a prime example of the arrogance that plagues our industry. Those features are harder to adopt, have greater downsides, fewer upsides, and aren't quite the standard they claim.
cyber-itl.org/assets/papers/…

2/ It's like yelling at Little League players for not performing at the same standard as Major League baseball. After all, if players earning $1 million per year can do it, why not a 13 year old???? It's so obvious, especially if you've never played baseball yourself.

3/ The biggest difficulty vendors have is hiring good people. There are fewer engineers that truly understand this than there are Major League baseball players. Ultimately, these devices are engineering using toolkits provided by others.

4/ The latest toolkits are pretty good and have many of these features by default. However, the hardware and software in many of those devices started development 5 years ago when such things weren't standard.

5/ MIPS CPUs have a lot more difficulties than those mentioned in the paper. In my tests, even with ASLR enabled, I'm going only 8 bits of entropy, compared to the latest Ubuntu which gets 30 bits.

6/ With 8 bits, hackers can still exploit a lot of devices, just 1 in 256. Since services are generally restarted, that means exploiting every device, just with 256 attempts. Compared to Ubuntu, which requires a billion attempts due to ASLR.

7/ Yes, the paper seriously compared system running the latest high-end 64-bit CPUs capable of 30 bits of ASLR against low-end CPUs in IoT devices capable of only a few bits of ASLR.

8/ A lot of these features, such as the relocation tables, are much less expensive on modern desktop/laptop/server CPUs then they are on old embedded MIPS CPUs. There is a cost to adding them.

9/ I don't know what non-executable stacks aren't enabled more often. But there are reasons, and not simply because engineers are lazy and dumb.

10/ These home devices don't have a lot of storage/memory. A lot of devices come with 4-megabytes of flash and 8-megabytes of RAM, compared to laptops or you iphone that has a THOUSAND time more than that.

11/ glibc, the standard library for Linux (and the reason it's called GNU/Linux), is 2-megabytes. These home devices use alternative libraries that are only 500-kbytes in size -- which don't have the heap/stack protections of glibc.

12/ These alternatives to glibc, namely uClibc and musl, have gotten better recently, with more of these protections. But they still lag behind glibc, and the older versions in these devices probably didn't have the latest features.

13/ I can see the paper looked at FORTIFY_SOURCE, which in my tests, only works with glibc, and not the libraries used in these routers.

14/ Hardware is evolving. New ARM designs are replacing older MIPS designs. The standard ARM processor for home devices are quickly moving to 64-bit variants (like the one in the Raspberry Pi), so we'll get effective ASLR that isn't possible today.

15/ Hardware is also evolving away from the tiny SPI flash memories of only a few megabytes to eMMC memories that can cheaply do hundreds of megabytes, so we'll see the small libraries expand with security features, or just a switch to glibc.

16/ Which isn't necessarily a good thing for security: home devices are quickly becoming a monoculture based on roughly the same ARMv8 CPUs, glibc, and Linux. The way this paper says IoT needs to follow the "standard" can only be solved by monoculture.

17/ BTW, I wrote a simple program for testing entropy. It's how I know that MIPS Linux is getting only 8 bits of entropy in some cases:
github.com/robertdavidgra…

18/ This is the output on a small MIPS based router, where libc has only 9 bits of entropy, meaning 1/512 attacks will succeed, or it takes on average 512 attacks in order to succeed once.

19/ The original paper was unclear about what "ASLR" means. What they really meant was whether executables/libraries were built to be "position independent". You get randomized layout of heap and stack regardless of how the code is laid out.

20/ Compiling my entropy measuring program without position-independence causes it to be always laid out in the same position, though other memory segments can still be randomized:

21/ What this example shows is that when exploiting a stack buffer-overflow, the chief deterrent is the 19 bits of stack ASLR, not the added 9 bits of executable ASLR.

22/ Devices aren't insecure because they lack a specific "hygiene" feature you think they ought to have. They are simply a little bit less secure. This is the problem with CyberITL: they demand unreasonable amounts of security for no particular reason that they can quantify.

23/ Security "hygiene" is a good analogy: it's demanded because it's "moral" not because it's "effective". Organizations like CyberITL are pushing for a moral Internet, not a secure one. They are ignoring actual security.