Slashdot Mirror


Code Execution Bug In Broadcom Wi-Fi Driver

2U*U2 writes to mention an EWeek article about an entry in the Month of Kernel Bugs. John Ellch has discovered a critical vulnerability in the Broadcom wireless driver: a driver used in machines from HP, Dell, Gateway, and eMachines. From the article: "[The bug] is a stack-based buffer overflow in the Broadcom BCMWL5.SYS wireless device driver that could be exploited by attackers to take complete control of a Wi-Fi-enabled laptop. The vulnerability is caused by improper handling of 802.11 probe responses containing a long SSID field and can lead to arbitrary kernel-mode code execution. The volunteer ZERT (Zero Day Emergency Response Team) warns that the flaw could be exploited wirelessly if a vulnerable machine is within range of the attacker."

6 of 157 comments (clear)

  1. Thanks by SnowZero · · Score: 5, Funny

    Thanks for mentioning the affected operating system(s). Oh wait, you didn't...
    Here, I'll help:
    Code Execution Bug in Broadcom Wi-Fi Windows Driver

  2. Well crap. by Merc248 · · Score: 5, Funny

    Checklist for today:

    1. Eat
    2. Rant on Slashdot
    3. Change SSID from "omgomgomgomgomgomgomg" to "omgomgomg"
    4. Sleep
    --
    "Hegelians, who love a synthesis, will probably conclude that he wears a wig." - Bertrand Russell
  3. Re:NDISWrapper by ettlz · · Score: 5, Informative
    Broadcom users on Linux should really be using the bcm43xx kernel module by now.
    Anyway the flaw wouldnt affect Linux systems. Why? Different kernel.
    NDISWrapper executes the Windows Kernel Mode NDIS driver in the Linux kernel's address space. So it might still result in code injection. It might even extend to FreeBSD when running bcmwl5.sys under its equivalent as well.
  4. More details at... by Wanker · · Score: 5, Informative
  5. Workaround for non-Linksys devices by Jacco+de+Leeuw · · Score: 5, Informative

    George Ou at ZDNet has published a procedure on how to use the Linksys drivers with devices from other vendors such as Dell and HP. Of course this is not an ideal solution but if it works it's better than nothing.

    --
    -------
    Warning: Slashdot may contain traces of nuts.
  6. Re:Please stop using C. by FireFury03 · · Score: 5, Insightful

    C is the source of all these problems. Please stop using it.

    It's not that simple. C is used in high performance code specifically because it's fast and compact. You get these improvements by avoiding needless length checking. Obviously there are cases where you _do_ need to length check buffers (and exploits are the result of not doing this), but you don't have to length check everything. If you ditch C in favour of a language that does the length checking for you then you will sacrifice speed and compactness since it will be checking _everything_.

    What language would you suggest is more suitable for writing high performance kernel code?