xorl %eax, %eax

CVE-2010-4648: Linux kernel Orinoco TKIP Countermeasures Design Flaw

leave a comment »

I also found this an interesting bug. It was reported by David Kilroy and it affects Orinoco’s wireless extensions support which can be seen at drivers/net/wireless/orinoco/wext.c file. The following IOCTL handler does something which seems to be fine at first…

static int orinoco_ioctl_set_auth(struct net_device *dev,
                                  struct iw_request_info *info,
                                  union iwreq_data *wrqu, char *extra)
{
        struct orinoco_private *priv = ndev_priv(dev);
        hermes_t *hw = &priv->hw;
        struct iw_param *param = &wrqu->param;
        unsigned long flags;
        int ret = -EINPROGRESS;
   ...
        switch (param->flags & IW_AUTH_INDEX) {
   ...
        case IW_AUTH_TKIP_COUNTERMEASURES:
                /* When countermeasures are enabled, shut down the
                 * card; when disabled, re-enable the card. This must
                 * take effect immediately.
                 *
                 * TODO: Make sure that the EAPOL message is getting
                 *       out before card disabled
                 */
                if (param->value) {
                        priv->tkip_cm_active = 1;
                        ret = hermes_enable_port(hw, 0);
                } else {
                        priv->tkip_cm_active = 0;
                        ret = hermes_disable_port(hw, 0);
                }
                break;
   ...
        return ret;
}

We can read from the provided comment that if TKIP countermeasures are enabled it should shutdown the card. Now look at the code below. If it’s active it will enable it instead of disabling it! Of course, the patch was to reverse the two calls like this:

                        priv->tkip_cm_active = 1;
-                       ret = hermes_enable_port(hw, 0);
+                       ret = hermes_disable_port(hw, 0);
                } else {
                        priv->tkip_cm_active = 0;
-                       ret = hermes_disable_port(hw, 0);
+                       ret = hermes_enable_port(hw, 0);
                }

As we can read in the original email bug report…

Enable the port when disabling countermeasures, and disable it on
enabling countermeasures.

This bug causes the response of the system to certain attacks to be
ineffective.

It also prevents wpa_supplicant from getting scan results, as
wpa_supplicant disables countermeasures on startup - preventing the
hardware from scanning.

I think it’s an interesting bug.

Written by xorl

January 7, 2011 at 00:30

Posted in bugs, linux

Leave a Reply

Fill in your details below or click an icon to log in:

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