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) [Link] (3 responses)

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... :-)

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.

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

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

Abstraction layers, such as a parser generator, create dependencies, which are a headache. They create a level of opaqueness and complexity that hinders review and complicates debugging. And perhaps most importantly, they complicate integration.

For example, often times you have a catch-22: you need to buffer chunks before feeding it to the engine. But how do you buffer and delineate the chunks? You still have to hand-roll some kind of parser. And sometimes you need to maintain parallel state, requiring the ability to access ad hoc state transitions during the parse to transform the data to your internal data structure.

Something like YACC would never work in a kernel context, because YACC requires specific patterns of buffering and control flow that are impermissible or impossible in the kernel, or at least in the context of a device driver.

One noteworthy exception to common issues with state machine generators is Ragel. Ragel is restartable and can be fed a stream byte-by-byte, yielding and resuming the machine between each byte. It uses no dynamic memory, and the state for a DFA is a single, non-static integer. Everything else is handled by user-defined C code which you embed within the machine definition. Ragel introduces zero integration problems, technically speaking. It can work with any control flow and I/O model--push, pull; blocking, non-blocking; buffered, unbuffered; etc.

But even with Ragel it often makes sense to break up the machine into several smaller machines, especially for heavily recursive structures. (Ragel supports these, but it really drives up the complexity). And those smaller machines are often so simple that the cost+benefit of something like Ragel is diminished.

Remember, there'll never be a perfect, bug-free solution. You have to balance the presumptive reduction in bugs with the added difficulty of discovering and fixing what bugs might remain. You need eyeballs to fix bugs, and the more complex and layered the system, the fewer eyeballs there'll be.

Anyhow, if people are incapable (for whatever reason: time, experience, laziness) to implement concise, explicit state machines using switch statements, which are quite easy to do with practice, how successful would be a solution which requires learning and applying a large and significant new set of skills and practices, a la a complex abstraction like a generator.

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

Posted Apr 25, 2015 16:32 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (6 responses)

> there'll never be a perfect, bug-free solution.

Bugs themselves do not matter, the important metric is the scale of their consequences. If some library/framework/language leads to 10 times more bugs but those at worst leads to abort() calls, it is still a good tradeoff if it protects from arbitrary code execution bug.

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

Posted May 6, 2015 11:02 UTC (Wed) by nix (subscriber, #2304) [Link] (5 responses)

It *very* much depends on the application whether ten denial of service attacks are better or worse than one arbitrary code execution (though of course an attacker could leverage the latter into the former, it is not a *guarantee*, so it may be that the tradeoff is better. Service guarantees for existing users sometimes matter a lot more than a guarantee that a single bad actor can't get away with anything.)

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

Posted May 6, 2015 11:59 UTC (Wed) by PaXTeam (guest, #24616) [Link] (4 responses)

a failed code execution attempt will result in a DoS otherwise it's worse than DoS (if you worry about the set then by definition you worry about any subset as well, it's simple logic). and in case of successful code execution there're no 'service guarantees' either.

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

Posted May 6, 2015 23:23 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

> a failed code execution attempt will result in a DoS otherwise it's worse than DoS

Not necessarily. For instance, the attacker might succeed in overwriting some data which later isn't used at all, or is used in a harmless way.

Perhaps the code being attacked was something like "if the value at this field is 7, that other field is a function pointer you should use right now, else do nothing; after that, reinitialize all the fields with valid data from elsewhere", and the attacker misaligned the padding and wrote 7 to the wrong field (suppose for the sake of argument that the vulnerability being used doesn't allow for a write outside the object bounds, or a write at any other time than just before that test for 7, and there's no multithreading involved). Unless the attacker hits the correct field with a 7, we have a failed code execution, but which doesn't result in a DoS.

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

Posted May 6, 2015 23:42 UTC (Wed) by PaXTeam (guest, #24616) [Link]

a failed code execution attempt is when the redirected code execution flow doesn't hit the intended target and tries to execute unmapped memory or unintended instructions that will very likely crash in short order. modifying data is not 'code execution attempt' per se, there has to be a moment when intended control flow is hijacked.

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

Posted May 9, 2015 21:48 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

In the case of a successful code execution there are indeed no guarantees, but by this point you are simply left asking: is your typical attacker interested in crashing us, or in spying on us or sending spam through us? And with the exception of ransomware the typical attacker would like to either remain unnoticed or keep the system working well enough that he can do his nefarious deeds. So it is *quite likely* that the thing will still be working.

To give a limit case of sorts, I would be very unhappy to fly in a jet with an avionics system vulnerable to arbitrary code execution, but if I had to, I'd hope like hell that any attacker was going to parlay his arbitrary code execution attack into something *other* than a DoS. In this sort of situation DoSes really are strictly worse: even though in terms of *attack classes* they are a subset of arbitrary code execution attacks, in terms of consequences they are very much not. I don't care if the aircraft I am on is sending spam or has someone peering through its cameras. I do care very much if it falls out of the sky.

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

Posted May 9, 2015 22:13 UTC (Sat) by PaXTeam (guest, #24616) [Link]

real life examples are a very bad match to the digital world, yours is no exception. you're conflating an attack on a computer system with possible effects of that computer system on the real world. of course that can be set up in arbitrary ways so it is quite pointless to try to prove a point since you might as well prove the exact opposite with the same example (would you not have preferred a DoS if it was flight 11 or 175?).

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

Posted Apr 26, 2015 9:09 UTC (Sun) by paulj (subscriber, #341) [Link] (4 responses)

I'm not advocating that network protocol parsers should be written in formal, complicated parser generators.

I'm saying it's inexcusable not to use a bounds-checking abstraction layer. E.g. a simple bound-tracking array/stream abstraction, that tracks state such as the length of valid data and the next position to read from. Trivial to write and use.

So, given:

struct foo {
int len;
void *data;
};

…

instead of something like:

int *buf = <untrusted network input>;
int len = ntohl(buf[0]);
struct foo *foo = malloc (sizeof(struct foo) + len);
foo->len = len;
memcpy (foo->data, buf[1], foo->len);

you instead do something like:

struct barray *buf = barray_new ();
<read network input into the barray>

int len = barray_read4 (buf);
struct foo *foo = malloc (sizeof(struct foo) + len);
foo->len = len;
barray_cpy (foo->data, buf, foo->len);

The former is obviously a giant security hole. The latter way at least can safely abort and turn a remote exploit into (at worst) a DoS, regardless of other problems (e.g. signed length).

This class of bug comes up again, and again, and again (e.g. Heartbleed, this article), yet it's so damn easy to mitigate it. However, it's 2015 and lots of code still isn't doing this. Even if it was originally old, once exploited, the fixes are band-aids and *still* using these generally much more unsafe practices!

It's trivial to add a checked, bounded buffer abstraction when fixing these. Admittedly it's a verbose change to have to make that will touch a good few lines, but you don't need to think much about the changes. Coccinelle could probably handle a lot of the changes!

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

Posted Apr 27, 2015 20:30 UTC (Mon) by wahern (subscriber, #37304) [Link] (3 responses)

The problem with using a library with specialized data structures is that it complicates crossing interface and component boundaries unless _everybody_ uses that same library.

Count how many "safe string" libraries are out in the wild just for C code. It's ridiculous. The ratio of such libraries to users is probably very near 1.0.

So I still think your suggestion is untenable in the real world.

The particular bug in this instance was a rather glaring unchecked memcpy. Why fantasize about using an automated tool to help refactor _all_ such code to theoretically solve _all_ such problems when well-known and existing automated tools (or even just a rigorous OpenBSD-style audit) could have easily discovered this particular unchecked comparison? _Anybody_ could have done that check without having to push any changes upstream or convince anybody of the superiority of any solution. But few people are.

Basically, it seems to me the heart of the problem isn't lack of tool sophistication. It was simply lack of anybody caring. If people don't care enough to review the code, why would you think adding even more complexity to the equation--which requires solving the cat herding problem--would be even remotely practical?

BTW, as the OpenBSD folks explained, one of the biggest issues in the Heartbleed case was the allocation abstraction layer that OpenSSL used. OpenBSD's normal audit process and bug mitigation measures likely would have caught the bug at it's inception. Which goes to my argument about the benefit of adhering to simplicity and sticking to common interfaces. Even if those interfaces are suboptimal, the fact that everybody is already using them means you benefit from more eyeballs and more sweat equity.

In the context of C code (i.e. excluding better languages--supplementation or wholesale switch) there are only two choices: 1) transparency, or 2) see #1. Transparency requires simple code using least common denominator best practices. It's the most effective way to improve the C ecosystems in _practice_ because it's the most effective way to ensure that your code can be easily audited, either by other humans or with automated tools. This has _proven_ to work better than dreaming and arguing about architecting better solutions.

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

Posted Apr 27, 2015 20:42 UTC (Mon) by paulj (subscriber, #341) [Link]

It's hardly untenable, because:

1. A simple bounded, checking buffer is pretty trivial to write. A 1.0 implementation:user ratio is fine, it's so simple. (Or otherwise use Quagga's, though there's a bit of cruft in its one to strip out - but it's not exactly a large or complex bit of code).

2. It's worked pretty for well for Quagga and GNU Zebra before that.

Quagga has had a good number of DoS bugs, which otherwise would have been remote exploits, thanks to it generally using a simple bounded buffer in between IO and parsing. At least, in its 2 most widely used daemons.

There's still a good bit of network facing parsers that don't use that abstraction, but in less widely used stuff usually. Which we have to eradicate.

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

Posted Apr 27, 2015 20:50 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

Oh, and on your other point. You're saying we should rely on human eyes catching bugs on parameters to memcpy's not having been checked properly earlier. We know this doesn't work.

Code that relies on humans mentally analysing C parsers of untrusted input to make sure that every bit of pointer arithmetic and memory writes that could be affected by the input will always be safe is code that will have lots of remote exploits. We know this.

If you want to make code secure, you *must* let the computer help you. Even without fancy compilers, it is still trivial for a programmer to place a simple bounded-buffer between the IO and the parser, to ensure that basic constraints like "Don't read or write outside the allocated buffer" are *ALWAYS* met OR the programme terminates *safely*.

It's trivial to do. Why not do it?

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

Posted Apr 27, 2015 20:52 UTC (Mon) by paulj (subscriber, #341) [Link]

Oh, and compilers can now also do this instrumentation. GCC 5 has new sanitisers that can I think (mentioned elsewhere). However, I suspect it might still be faster to use an explicit bounded buffer around just the key bits of IO.

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

Posted Apr 26, 2015 22:16 UTC (Sun) by tpo (subscriber, #25713) [Link] (2 responses)

> It's 2015. Why are we still writing parsers for untrusted, remote input data with direct memcpy's based on remote supplied fields?
>
> Really, it's not difficult to write a bounds-checking abstraction layer and direct IO through it.

So I've been giving systems engineering lectures for a dozen of years. My aim always was to have the students learn C in order to be able to 1) understand existing systems, code and history and 2) also to understand why never ever to use that language, since writing a secure program in it is near impossible (+- ε ≥ 0).

After 45 years of consistent train wreckage C/C++ is *still* the only systems engineering language though (not sure how much of OSX is written in Objective-C).

During all of my time of teaching about C I've been wondering whether it would be possible to define a "secure C" (sub)set consisting of (best practice) rules and to implement wrappers (data structures and methods) around pointer handling, arrays and memory management and other dangers?

Most efforts of "improving C" seem to have resulted in new languages (Ada, Objective-C, C++)... or have concentrated on some constrained problem (Gtk, Gobject...).

My impression always was that with the vast majority of standard C library/POSIX functions being insecure providing a "secure subset + wrappers" would be a nonsensical undertaking.

Maybe not though. Does such a thing - an easy to use set of secure rules and a secure, comprehensive runtime environment - exist? Maybe even with a --strictly-secure-gcc-clang-...-features compiler switch?

Safe C?

Posted Apr 27, 2015 5:52 UTC (Mon) by gmatht (subscriber, #58961) [Link]

There is MISRA C. It is not clear to me whether the objective machine checkable rules of MISRA C are sufficient to prevent undefined behaviour, however.

Rust seems like the most promising systems language. Superficially similar to C++ with all the unsafe bits pushed into "unsafe" blocks, and a bit of functional sugar for those who want it. No need for GC, and zero runtime overhead wrappers around C libraries.

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

Posted May 5, 2015 11:15 UTC (Tue) by sorokin (guest, #88478) [Link]

> During all of my time of teaching about C I've been wondering whether it would be possible to define a "secure C" (sub)set consisting of (best practice) rules and to implement wrappers (data structures and methods) around pointer handling, arrays and memory management and other dangers?

I think this is more or less what C++ does. For example one can consider std::string as safe and convenient wrapper around strxxx functions.