Thoughts on ath5k, Stability, and Linux (In)Security

I’ve continued to have serious issues related to Linux ath5k wireless so I’ve decided that I’ll upgrade my netbook to Windows 7 when it’s released. I was hoping that recent improvements in the ath5k code would fix what had plagued me before with frequent loss of detection of the Atheros card itself, which, as I’ve described before, continues even after rebooting into either Linux or Windows. That alone tells me something’s really, really bad with it.

I’ve been kind of restraining myself from going beyond that particular point about the gravity of the problem or what it potentially means. As I’ve already written, loss of detection of the card even after rebooting leads me to have concerns about physical damage to hardware. In case you haven’t noticed, every distro comes with a disclaimer that you’re on your own and developers take no responsibility for damage to your hardware. That’s always so comforting to know, that these people promise you the world but can’t stand behind their code.

The problem is capricious and can’t be tied to one event. That makes it difficult to initiate some specific sequence of events on my netbook to replicate the issue. At least that would give some guidance on what not to do — whether it’s a certain application, hitting certain sites, using a particular encryption protocol, etc.

Here’s what I haven’t said thus far. I wonder if it might actually be easier to recreate the issue outside of my netbook than on it.

Where there’s a “bug,” there’s often a vulnerability not far beneath. With the frequency of loss of wireless with this particular driver-card combination on my netbook, I wonder how difficult it would be to cause DoS (edit: whether limited to the wireless device, extending to the whole OS, or even pwnage/arbitrary execution) on the same network or even outside of it. If so, then there’s a much bigger and potentially more serious problem than instability.

This is only something I’ve pondered so far. I haven’t done anything (yet) to see if this is possible. It may not be any easier to cause the DoS externally than to set up a situation where the card panics and the OS no longer detects it. Either way, Linux is not proving a rock-solid option on my AA1.

My curiosity, though, is piqued by the possibility that I may be able to at least cause DoS through the instability of this driver (or the Linux 802.11 stack?). I’ve never been one to presume that Linux is inherently more secure than any other operating system. I’m certainly not going to start lying and join in the lie that it’s more stable than any other operating system. That’s especially true when it comes to my Atheros card: flawless and no crashing under Windows, unpredictable and buggy as hell under Linux.

One of the things I wrote last summer when Linus Torvalds mocked the OpenBSD people for their attention to security is that the OpenBSD team focuses on correctness of code because that makes security-related issues easier  to find. Where Linus is more concerned about fixing bugs, the OpenBSD team is concerned about doing things correctly from the start so there aren’t myriad little bugs to find because of sloppily-submitted code. One’s “bug” is another’s hole to pwn en masse.

I’ll probably continue looking to see if there are changes to the ath5k code and/or 802.11 code in Linux. I’ll also see if I can find another card with a better track record under Linux. Barring any changes, though, my Linux days are numbered.

Advertisements

Tags: , , , , , ,

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: