Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica) [LWN.net]

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Posted Apr 24, 2015 16:24 UTC (Fri) by Karellen (subscriber, #67644)
In reply to: Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica) by paulj
Parent article: Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

The thing is, C and C++ implementations need not *necessarily* use bare pointers, and are therefore not inherently unsafe. Yes, the C and C++ standards are written so that performant bare-metal implementations can be written, but the abstract machines described by the standards could be implemented in any number of ways.

It would be entirely possible to create a new C or C++ ABI, to on existing hardware, which used an extended opaque pointer type and did run-time bounds checking on *all* pointer accesses. And which exit()s on any out-of-bounds read/write. Heck, we could even check all pointer arithmetic, asserting if a pointer was even generated which pointed before the start of any array, or after-the-one-after-the-end of any array (and not NULL).

No, it programs compiled for this new ABI wouldn't be as quick as if they were compiled for the "bare metal" ABI, but at least we'd have the choice. We could compile *all* our existing C and C++ code - libraries and applications - either for speed or for safety. We don't need to rewrite everything in a safe language, we could just create a safe implementation of our existing one.

Oh, if only I had six months to a year free to play with the idea myself... :-)

to post comments

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Posted Apr 24, 2015 19:28 UTC (Fri) by wahern (subscriber, #37304) [Link] (2 responses)

Both clang and GCC have AddressSanitizier.

TCC has (or had) a very sophisticated bounds checking mode which is much more strict than AddressSanitizer. See http://bellard.org/tcc/tcc-doc.html#SEC21.

For example, TCC bounds checks not only pointer dereferences, but pointer derivation. The following program succeeds with AddressSanitizer, but will abort at run-time with TCC

int main(void) {
        char buf[] = "0123456789", *p;

        p = &buf[sizeof buf];
        while (--p >= buf)
                putchar(*p);

        putchar('\n');

        return 0;
}

because the final --p evaluation derives an undefined pointer value--one element before the beginning of buf, whereas in C p can only point to an element within buf, or one past buf, regardless of whether you ever dereference it.

Unfortunately, the -b option appears to have been removed from the current release of TCC. It's not recognized with the version packaged for Ubuntu. You may need to download Fabrice Bellard's original code to see it in action. it might be worthwhile to resurrect it. Probably it was too much trouble to maintain when they added 64-bit support.

AFAIU, IBM mainframes use fat pointers, which encode type and capability information enforceable by the hardware. So C pointers are 128-bit, even when the hardware ISA is 32-bit or 64-bit. It's been this way since the 1970s, I think.

Apple's latest compilers for Objective-C and Swift use fat pointers to implement automated reference counting. They use the spare bits in the x86-64 and ARM64 pointer representation--the bottom bit(s), and top 16 bits of 64-bit pointers.

It would be cool if GCC or clang had built-ins to declare when and where to use fat pointers using type attributes. Then code could, at least on some architectures and for small'ish objects, have automated, fast bounds checking across different compilation units, without the burden of managing additional data structures to store and retrieve this information.

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Posted Apr 25, 2015 6:17 UTC (Sat) by Karellen (subscriber, #67644) [Link] (1 responses)

Cool. I didn't realise TCC did that - thanks for the info.

But, although I've not looked into it, I'm fairly sure that those pointer protections can't escape the current function. If the "while" loop was in another function (or especially in another translation unit) and "p" and "buf" were passed in as parameters, I seriously doubt that TCC would be able to catch the underrun.

IBM's implementation sounds more like the sort of thing I was thinking of.

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Posted Apr 25, 2015 19:45 UTC (Sat) by wahern (subscriber, #37304) [Link]

Correct, TCC only adds instrumentation to the code that it compiles and for the objects that it allocates.

Regarding the IBM stuff, I think what I'm remembering is

http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set
and
https://www.ibm.com/developerworks/community/files/basic/...

Basically, the IBM compilers for this environment translate C, Fortran, Cobol, etc programs to an intermediate representation, TIMI. When you first execute it on a new system, the OS translates TIMI to native code. When you move to new hardware, you just copy the program and the TIMI representation is automatically translated to the new instruction set. I guess it's one of the reasons so many ancient IBM mainframe and minicomputer programs continue to be migrated to newer and newer hardware, instead of being relegated to an emulator and abandoned as too slow.

I'm unclear on how and whether the full 128-bit pointers are used from C code, by the C compiler, or in the runtime environment. AFAICT, in TIMI pointers are more like file handles in the sense that they describe an object and control how you can manipulate the object. And the hardware protects the tagging bits, so you can't derive pointers to random resources.

A pointer could reference a program, an instance of a program, file, a service, or in the case of a running C program a heap object returned from malloc. But it's not clear to me if these capabilities are used to, e.g., restrict buffer overflows. For all I know all data pointers in a running C program simply index a single virtual address page map "object" assigned to the program instance, not unlike the way it works on x86 hardware.

It's really fascinating. Perhaps someone reading this could chime in. It basically sounds like the kind of persistent object store and addressing model that people claim will be arriving in the future, except these machines and the architecture have been around for over 30 years.

It makes sense now why IBM was so quick to jump on the Java bandwagon. They have this incredibly sophisticated hardware architecture that is well-suited for implementing, integrating, and running JREs.