LWN: Comments on "Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)"

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

PaXTeam — Sat, 09 May 2015 22:13:00 +0000

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)

nix — Sat, 09 May 2015 21:48:04 +0000

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)

PaXTeam — Wed, 06 May 2015 23:42:40 +0000

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)

cesarb — Wed, 06 May 2015 23:23:27 +0000

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

PaXTeam — Wed, 06 May 2015 11:59:01 +0000

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)

nix — Wed, 06 May 2015 11:02:21 +0000

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)

sorokin — Tue, 05 May 2015 11:15:08 +0000

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

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

paulj — Mon, 27 Apr 2015 20:52:03 +0000

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)

paulj — Mon, 27 Apr 2015 20:50:16 +0000

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)

paulj — Mon, 27 Apr 2015 20:42:03 +0000

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)

wahern — Mon, 27 Apr 2015 20:30:08 +0000

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.

Safe C?

gmatht — Mon, 27 Apr 2015 05:52:56 +0000

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)

tpo — Sun, 26 Apr 2015 22:16:27 +0000

> 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?

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

Wol — Sun, 26 Apr 2015 14:50:50 +0000

> sellers from whom you lease/purchase your phone will not honor warranties

One of the advantages of living in Europe. If a supplier tried to walk away from a hardware fault because you'd rooted your phone, they would get into hot water pretty quickly.

I think there's been cases like that, and it's been a slam-dunk for the consumer. "Flash the phone back to factory default, it's still broken, it's the supplier's problem" ...

Cheers,
Wol

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

paulj — Sun, 26 Apr 2015 09:09:55 +0000

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)

wahern — Sat, 25 Apr 2015 19:45:57 +0000

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)

ibukanov — Sat, 25 Apr 2015 16:32:56 +0000

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

Karellen — Sat, 25 Apr 2015 06:17:46 +0000

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)

ccchips — Sat, 25 Apr 2015 04:17:51 +0000

It might be worth noting I am not interested in Android phones. I try to use the dumbest phone I can find, and I prefer to use wifi-only tablets. I should say I am watching the Intel-based tablet space to see if operating-system installation would be easier on those at some time (even if it voids the warranty.) In such a case, I might consider a "free/open-source" version of Android if it had some straightforward way to apply security updates, or some version of Ubuntu or Mint.

I might also mention this; I used to be a Linux junkie, compiling my own kernels, sending patches for the tape driver, doing everything myself. I loved Slackware for that quality in those days. but frankly, I've become spoiled with Ubuntu LTS and Mint and Debian, and even if I weren't, it doesn't seem like fiddling with the source code should be necessary to get security updates, no matter what computer, be it a tablet, phone, desktop or whatever. And for tablets---they are really best for simple things like reading and watching video and getting the weather, so it would be nice to get security updates without a lot of fuss.

As to the previous comment; mishandling security support is a very irresponsible thing on the part of these tablet and phone manufacturers, and frankly I hope it bites them in the ass real hard someday.

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

NightMonkey — Sat, 25 Apr 2015 02:42:42 +0000

Yes, rooting is a way to *technically* solve some of these issues, but the fact that many (most?) sellers from whom you lease/purchase your phone will not honor warranties if they find your device has been rooted shows how committed to security updates the Android phone resellers are (and Google, for allowing this). That just stinks, and prevents you from taking charge of your own device without major penalties and loss of value.

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

wahern — Fri, 24 Apr 2015 19:28:26 +0000

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)

wahern — Fri, 24 Apr 2015 18:19:11 +0000

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)

Karellen — Fri, 24 Apr 2015 16:24:37 +0000

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)

tao — Fri, 24 Apr 2015 15:29:00 +0000

Well, not that it's a good excuse, but wpa supplicant was written in 2002, not 2015 :P

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

paulj — Fri, 24 Apr 2015 15:07:20 +0000

#include <rants/why-are-we-still-writing-bare-pointer-network-parsers.txt>

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.

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

dps — Fri, 24 Apr 2015 13:38:55 +0000

While it is more difficult to upgrade android, and even load custom firmware, it *can* be done if you root your device. Several things in google's android store actually require a rooted devices and so is some of the source code. Upgrading just wpa_supplicant should be eminently possible.

If a similar bug appeared on an i* device without a known root exploit you are at apple's mercy. I doubt windows phone support fixes from anybody except M$ but one might hope for more holes than iOS.

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

ccchips — Fri, 24 Apr 2015 13:23:12 +0000

Android!

This is one of the reasons I don't like Android. If you want to have a tablet that runs Android and you are looking for something low-cost, you aren't going to get security updates. This is because your Android comes from the manufacturer of the tablet, not from Google. I am very disappointed in this. For many, many years, I have expected to have access to security updates on the desktops I use, no matter if I'm running Windows, Linux, FreeBSD, or whatever.

I wonder if this issue will ever be addressed, considering that a great many Android tablets can't be re-loaded with a different operating system as easily as desktops can? I keep hoping for that capability to become ubiquitous, but that hope seems to be in vain.

P2P most serious, but DoS possible with P2P disabled

johill — Fri, 24 Apr 2015 10:59:17 +0000

Sorry for the dupe post - wrong button.

Also, with p2p disabled it's not possible to trigger this bug in any way as this code path would never be executed. With P2P compiled out the code doesn't even exist in the binary.

P2P most serious, but DoS possible with P2P disabled

johill — Fri, 24 Apr 2015 10:56:46 +0000

It's not a kernel bug :)

It's really just one bug. And the problem cannot happen with just a "crafted SSID". For it to happen outside of an actual P2P usage scenario, you still have to have a scan result with a P2P device address or device ID attribute.

P2P most serious, but DoS possible with P2P disabled

ledow — Fri, 24 Apr 2015 10:05:52 +0000

It does seem yet another one of those quite-simple things that should have been caught much earlier.

Is this in any way related to the similar Apple bug where you can send an iPad into a reboot-loop for all the time that it's near a rogue Wifi point?

P2P most serious, but DoS possible with P2P disabled

Duncan — Thu, 23 Apr 2015 23:11:59 +0000

Based on the article, there's either two related bugs, or two triggers for the same bug, depending on how you look at it.

The more serious bug/trigger is apparently in P2P support. It will allow information leakage and potentially allow code execution as well. This one is apparently avoided if P2P support is disabled.

But there's a less serious DOS possibility as well; a crafted SSID could crash WIFI. This one apparently doesn't require P2P and is thus possible regardless of whether it is enabled.

Comments at Ars suggest that unicode SSIDs are an easy way to exceed the buffer, and Alibaba as the source of the discovery would seem to support that. Additionally, a number of Ars users had previously found certain unicode (one commenter) and emoji (another, samsung smart tvs go into an infinite crash/reboot cycle) containing SSIDs did break wifi on some of their equipment, so they simply quit using those types of SSIDs. With this story they believe they now understand the cause.

But I simply RTFA (and comments) and don't claim to be a dev let alone a kernel hacker, so you may well know details I don't?

Regardless, safest to assume at least a DOS is possible without P2P enabled, until we know for certain otherwise.

Duncan

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

BenHutchings — Thu, 23 Apr 2015 15:43:48 +0000

The wpa_supplicant bug is apparently only in P2P support, so it can be mitigated by disabling that at compile-time or run-time. It seems to be disabled on some Android systems already for other reasons - my phone running CyanogenMod 11 has "p2p_disabled=1" in /etc/wifi/wpa_supplicant_overlay.conf.