The purpose of this page is to document all of the information that
I have been able to gather about this phenomenon as well as to document
any progress that I have managed to make with various different
manufacturers whose products demonstrate this bug. The intent is
to make
this information as public as possible, both to help out others who
have been affected by this bug as well as to put some pressure on the
manufacturers to fix their products.
What you can expect to find throughout the remainder of this
document is a brief description of the symptoms of the problem, a list
of devices that are defective in this manner, information about
progress being made to resolve the bug in specific devices, and finally
a detailed look at exactly what is happening behind-the-scenes along
with Kismet captures of the raw 802.11 frames to help with the
demonstration.
I want to publicly thank and acknowledge the good folks at Tranzeo Wireless for all of their
help in trying to track down and help diagnose this problem, and for
being
all around awesome guys to work with.
11/11/04 -
Agere,
sadly, will not
release a flashable fix for the
"hijacking vulnerability" bug for Hermes 1 clients! Fixed
a typo regarding the new RAM-downloadable firmware revision that comes
with the new drivers for Hermes 2 cards (1.68 -> 1.64).
11/07/04 -
11/03/04 -
11/02/04 -
10/29/04 -
If certain buggy clients are within range of certain buggy access
points, they will more often than not associate to the buggy access
point even if the SSID specified for the client to connect to does not
match that of the buggy access point. For example, if I have 1
buggy 802.11 client within range of 1 buggy access point with SSID buggy and 1 properly behaving
access point with SSID compliant,
if I instruct the buggy client to connect to compliant, it will (depending
on certain factors) most likely end up associating to buggy, even though the client
was explicitly told to connect to compliant.
Thus the use of the term "hijack." The association attempt has
been "intercepted" by the one access point even though it was not
intended for it.
Furthermore, if an SSID is specified in a buggy client for an SSID
that does not exist, it will associate to the buggy AP, which doesn't
just merely hijack connections to valid APs, but ALL association attempts regardless
of their validity.
I hope that the reasons why this is a problem are fairly clear. When this bug is in effect, if someone has multiple APs (either all buggy or a combination of buggy and non-buggy), there is no guarantee that you will connect to the one that you want to connect to. This is a nuisance, especially if the one that you want to connect to (but didn't, because the association was hijacked by the other AP) is the logical choice given each AP's distance from the client.
This bug is more
than just a mere nuisance for WISPs (wireless ISPs), though. If
the WISP's own 802.11 access points that their customers associate to
are not buggy and fully compliant with the spec, but a neighbor between
the customer and their shot to the WISP's tower is running one of these
broken
access points, the customer's connection to their
ISP could be hijacked by this neighbor's AP if the signal is strong
enough. We here at First Step
Internet have now had to deal with this problem on more than one
occasion, and it is quickly becoming old both for us as well as for our
customers. In order to work around the problem for the customers
that have encountered this problem, we've had to replace gear and in
some cases even go with a non-802.11 solution.
This scenario should never
be
allowed to occur. The fact that it does indicates that something
is
quite obviously broken. If you specify an SSID to connect to, the
only
time that an association should occur is if there is an access point in
your vicinity that is programmed to answer to that SSID. The
client
should not associate to an
access point with an SSID other
than the one that was specified, and if there is no access point around
that answers to that SSID, then the client should not associate to
anything, period.
I've been trying to germinate some discussion about this issue on a
couple different public forums. Here are some links to places
where this issue has received some attention:
The following APs/routers and wireless clients have demonstrated
this problem in tests as well as in the field. I will continue to
maintain this list and provide you with updates as I discover how the
manufacturers have been trying to deal with fixing the problem.
Please e-mail me if you run
across a device that should be added to this list or if you have
further information about one of the devices already listed here:
News:
10/29/04 - I e-mailed my Tier 2 contact at Netgear, asking him to re-open my trouble ticket and pass on the URL of this website to engineering.
The WGR614 v4 wireless router is an 802.11g/b access point, router,
and ethernet switch whose wireless functionality is based off of the Marvell Libertas
chipset. Interestingly, one of the Tranzeo guys that I have been
communicating with mentioned to me first that "there is a register in
the Marvell chipset that can create this behavior." After he told
me this, I did some research to find out which chipset was being used
inside this particular model of Netgear router, and sure enough, what
do I find but that the Libertas is being used in this very same
revision of the WGR614. Presumably, if it is just a
single register that needs to be set, Netgear could theoretically fix
this behavior in their firmware pretty easily. It does disturb me
to hear, though, that Marvell included such an exploit in their chipset
and labelled it as a "feature." If I were to hazard a guess, it
would be that the default action of the Libertas chipset when working
as an AP is to have this "feature" enabled unless that register is
initialized with a specific value meant to disable it.
As of 10/07/04, I have opened a trouble ticket with Netgear Support about this very issue. My ticket number is 1008121. For the most part, I can report that the Netgear support personnel have been pleasant enough to deal with; I was especially pleased with the quickness and courteousness of the response that I did get from a Level 2 representative so shortly after filing the bug with them. However, on the negative side, I have not heard much from them after my case was escalated to engineering, and have been given no ETA as to when I can expect the problem to be resolved. I am still optimistic, though, based on my experiences thus far with Netgear Support, that they will eventually manage to come up with a solution.
News:
11/02/04 - I sent Linksys a bug report and the URL to this site
through their web site's technical support request form.
The Linksys WAP11 v2.8 wireless access point is an 802.11b wireless
access point and wireless <-> ethernet bridge whose wireless
functionality is based off of the ADMtek ADM8638 chipset. We
first discovered that WAP11s have this great "feature" after it did
this in the field to a customer of ours; in fact, this was our very
first exposure to the problem at all. After we ran across it and
decided to try and replicate the problem internally, we found that we
had 2 WAP11s at our disposal for testing, a v2.2 and a v2.8, and the
2.2 did NOT hijack the Hermes and Prism clients, and I believe that the
2.2 is based on Atmel. (You cannot identify a v2.8 WAP11 by a
version number on the packaging...the v2.8 has a Cisco logo on it and
is labelled "Wireless-B
Access Point" rather than "Instant Wireless Access Point".) I
currently know next-to-nothing about the ADMtek chipset and whether its
hijacking actions would be considered a bug by its manufacturer or a
"feature" much like the Marvell, but it does show nearly the exact same
symptoms as the Netgear product does.
I have not yet opened up a trouble ticket with Linksys, so I cannot
comment on their support mechanism or willingness to help yet, but I
will be doing so shortly.
Just yesterday (10/28/04), I also encountered another Linksys product that hijacks 802.11 connections. I'm not sure what exact model it was. The only information that I have at this time is that it hijacked my connection while I was trying to troubleshoot one of our own access points, that its MAC began with 00:0F:66 (Cisco-Linksys), and that the access point identified itself to me as "Marvell" (this is the AP name, not the SSID). Marvell...Hmmmmm...
News:
Nothing to report thus far!
We don't really have much to report on the D-Link front, except that we know at least some D-Links do it, and we know this because when we look at the BSSID that devices which have been hijacked are reporting themselves as being associated to, we see a MAC address that begins with 00:0F:3D, and when we look that up in the OUI Database, we see that the manufacturer of said device is D-Link.
I will not be opening up a trouble ticket with D-Link on this issue
yet until I can determine exactly which models of their devices have
this defect in order to be fair to their support department. :-)
News:
11/06/04 - Updating
your Prism card's firmware.
The Prism chipset, previously owned by Intersil and now owned by
Conexant (yes, that
Conexant...the former Rockwell, manufacturer of modem chipsets) is a
nice, stable, widely-used and well-proven 802.11 chipset that multiple
manufacturers use in their products. Unlike the more popular
host-controlled designs of today (like Atheros), this chipset functions
autonomously from the host and its
functions are controlled by firmware on the card itself. (Some
Prism 3 cards don't have an EEPROM, but still have RAM that the
firmware is loaded into and then executed by the driver during card
initialization.) So I guess that you could call this the
"hardware modem" of 802.11 chipsets (in contrast with WinModem-esque
designs like Atheros, which, to be fair, does have its
advantages...Atheros is more flexible and programmable than
firmware-based designs like Prism).
Only certain wireless clients will allow themselves to be hijacked
by these access points listed earlier in this document, and the Prism
II and 2.5 chipsets are unfortunately among those
numbers. The wireless cards/chipsets are not the only devices at
fault, though: the Prism-based cards won't allow themselves to be
hijacked by just ANY access points, just by the ones mentioned above,
so obviously those access points are doing something non-kosher as well.
The good news is that if you find that your Prism-based card has
this bug, you can fix your card yourself immediately because the bug in
question has been squashed by the Prism firmware developers in later
firmware versions. I have successfully tested Secondary Station
firmware version 1.7.1 for Prism II as well as 1.8.0 for Prism 2.5, and
in both cases the card did not allow itself to fall victim to the buggy
access points after the firmware was upgraded on the card. For
information and instructions on how you can upgrade your card's
firmware, I recommend visiting Jun Sun's
page on flashing
Prism chipsets.
News:
11/11/04 - The latest news from my Agere contact is that they "can
not spend time looking into legacy versions of Hermes1 firmware for
this issue," meaning that they are not willing to release a version of
the fix that does not require a tertiary firmware download to
use. Naturally, this comes as disappointing news to me, as I am
sure it also is to you; I was hoping that they would recognize this as
the serious problem that it is and take ownership of the issue.
This considerably decreases our confidence in Agere and in their
products or products based on their technology, which we can no longer
in good conscience recommend any longer.
11/05/04 - A (partial) fix is
available! I discovered something interesting last night: multi-vendor
drivers from Agere which are newer than any drivers that Proxim has
up for download on their web site. Even better, these drivers
have embedded in them a Variant 2 (RAM-downloadable/"tertiary") station
firmware revision that actually fixes this bug! The
version number of this firmware (9.42) suggests that it is quite a bit
newer than the last official Variant 1 (flashable/"secondary") station
firmware released by Agere, 8.72 (which is also the same Variant 2
version embedded in Proxim's "newest" drivers available from their
site). Those of you who need to merely have the "hijacking" bug
fixed on their Windows-based platform should upgrade to these drivers
(and don't forget the new Client Manager, too). Those of you,
though, who are using their ORiNOCO cards in non-PC devices (such as
YDI's EtherAnts) will have to wait until Agere and/or Proxim releases a
flash updater that can permanently flash this new firmware on the
card. The RAM-downloadable Hermes 2 firmware was also updated
from 1.24 to 1.64 and, just like the newer Hermes 1 firmware, fixes the
bug for the Hermes 2 chipset.
11/04/04 - I've been exchanging e-mail with one of the engineers
over at Agere. Once I know something more, I'll update the site.
11/03/04 - I have not heard word one from Proxim support ever since
my last attempt to contact them. However, thanks to a new friend
I made on the broadbandreports.com
forums, there may be some promising developments brewing over at
Agere. I'll update this section once I know something more
definitive.
10/29/04 - I e-mailed Proxim support again asking them to re-open my trouble ticket and to consult this web site for details on how to reproduce the bug.
The Hermes chipset, as it is commonly called, officially goes by the WaveLAN moniker in Agere's marketing literature. Or, at least it used to. I just received word from Agere that they expect to have completed their exodus from the Wi-Fi market within a year or so. I was under the impression that Agere would hold on to the chip fabrication end of things when Proxim took over the ORiNOCO line, but apparently the whole business, chipsets and branding and all, was sold completely over to Proxim.
Hermes is a bit unusual in that for the majority of its life,
Lucent/Agere produced the chipset as well as the products that were
based on it (the ORiNOCO line of products) rather than reselling the
chipset
parts to other manufacturers. The Hermes design is very similar
to the Prism design; in fact, they share
a common heritage (along with
Symbol and Aironet), which could explain why they both have this
bug. There are two versions of this chipset, commonly referred to
as Hermes I and Hermes II (there is also another "variant" called Ruby,
but I've not been able to find much information on exactly what Ruby
is; my impression is that it is merely a small revision of Hermes
I, but people with more information should feel free to contact me about it). Some
(read: YDI) believe that Hermes II
does not have the bug that makes
it vulnerable to the hijacking, but I am the unfortunate owner of a
Hermes
II-based PCMCIA card (a Proxim-labelled ORiNOCO 802.11b "Silver" PCMCIA
card, Proxim model 8421-WD/Agere model 0110-PC,
FCC ID: IMRPC2411B), and I can tell you matter-of-factly that it
does indeed allow itself to be hijacked by the routers listed on this
page.
In order to figure out just what the heck is going on between these
cards and these access points, and in order to determine whose fault it
is, I set up a testing environment that allowed me to confirm the
presence of the bug and watch what was happening on a layer 2
level. What follows is a description of the tests that I ran and
a brief analysis of what the problem appears to be.
Here are the conditions under which these tests were conducted:
I produced four dumpfiles with Kismet aiming to show how different
clients and access points interact with each other during the
association process. You may download them here:
I haven't yet tried to test a pre-bugfix Prism firmware in place of
the ORiNOCO. Results, I'm guessing, would be very similar if not
the same.
In order to view these dumpfiles, I highly recommend the free Ethereal network protocol analyzer.
Kismet logged all 802.11 management frames between the client and the
APs including all of the Beacon frames, but because of their sheer
numbers, you may find it difficult to
wade through them all in order to get a "big picture" sense of what the
log files are showing. In Ethereal, you can filter out the
Beacons by
using the filter expression "not
wlan_mgt.fixed.beacon" Please note, though, that when you
do this, you will also end up filtering out all of the Probe Response
frames as well; presumably Ethereal does this because a Probe Response
packet is essentially a unicast Beacon frame. You will need to be
able to view these Probe Response frames, because they are key to what
is happening between the buggy clients and the buggy APs, so you will
not want to have the Beacon filters engaged all the time.
| Steps
to 802.11 Association |
|
| Action |
Expected Result |
| 1. APs send out beacons. |
1. Clients become aware of
AP. |
| 2. Client sends out Probe
Request frame. |
2. AP receives Probe and
prepares appropriate response. |
| 3. AP sends out Probe
Response
frame. |
3. Client receives answer
from
AP. |
| 4. Client sends out
Authentication frame. |
4. AP receives request and
prepares appropriate response. |
| 5. AP sends out
Authentication
frame. |
5. Client receives
acceptance or
denial for authentication. |
| 6. Client sends out
Association
Request frame. |
6. AP receives request and
prepares appropriate response. |
| 7. AP sends out Association
Response frame. |
7. Client has completed the
association process to the AP. |
It appears to me, after looking at the logs, that both devices are
at fault here: the AP for answering
all probe requests and the client for accepting
any probe responses. My conclusions here seem to be in line with
the conclusions that YDI themselves reached as detailed in this
post to the isp-wireless
mailing list (which I also referenced earlier). The unfortunate
combination of the two (buggy AP and buggy client)
ensures that in a good many cases, the client won't talk
to anything other than that AP if that AP is present.
My guess is that the client is only being discriminatory about Probe
Responses that it accepts based on the destination MAC address;
remember that Probe Responses are just unicast versions of Beacon
frames, so the ORiNOCO/Hermes and old Prism cards are just assuming
that since the Probe Response was sent specifically to them that it
must have been from the AP it probed for, and thus they do not bother
to look at the SSID listed in the contents of the Response packet until
after they have already accepted it and it comes time to make the
association request.
Please send me questions/comments/corrections/updates!
--
Nathan Anderson
First Step Internet, Inc.
nathana@fsr.com
(Last updated 11/11/04)
This page has been viewed times
since 10/29/04