lkml.org 
[lkml]   [2015]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities
    Date
    The ozwpan driver accepts network packets, parses them, and converts
    them into various USB functionality. There are numerous security
    vulnerabilities in the handling of these packets. Two of them result in
    a memcpy(kernel_buffer, network_packet, -length), one of them is a
    divide-by-zero, and one of them is a loop that decrements -1 until it's
    zero.

    I've written a very simple proof-of-concept for each one of these
    vulnerabilities to aid with detecting and fixing them. The general
    operation of each proof-of-concept code is:

    - Load the module with:
    # insmod ozwpan.ko g_net_dev=eth0
    - Compile the PoC with ozprotocol.h from the kernel tree:
    $ cp /path/to/linux/drivers/staging/ozwpan/ozprotocol.h ./
    $ gcc ./poc.c -o ./poc
    - Run the PoC:
    # ./poc eth0 [mac-address]

    These PoCs should also be useful to the maintainers for testing out
    constructing and sending various other types of malformed packets against
    which this driver should be hardened.

    Please assign CVEs for these vulnerabilities. I believe the first two
    patches of this set can receive one CVE for both, and the remaining two
    can receive one CVE each.


    On a slightly related note, there are several other vulnerabilities in
    this driver that are worth looking into. When ozwpan receives a packet,
    it casts the packet into a variety of different structs, based on the
    value of type and length parameters inside the packet. When making these
    casts, and when reading bytes based on this length parameter, the actual
    length of the packet in the socket buffer is never actually consulted. As
    such, it's very likely that a packet could be sent that results in the
    kernel reading memory in adjacent buffers, resulting in an information
    leak, or from unpaged addresses, resulting in a crash. In the former case,
    it may be possible with certain message types to actually send these
    leaked adjacent bytes back to the sender of the packet. So, I'd highly
    recommend the maintainers of this driver go branch-by-branch from the
    initial rx function, adding checks to ensure all reads and casts are
    within the bounds of the socket buffer.

    Jason A. Donenfeld (4):
    ozwpan: Use proper check to prevent heap overflow
    ozwpan: Use unsigned ints to prevent heap overflow
    ozwpan: divide-by-zero leading to panic
    ozwpan: unchecked signed subtraction leads to DoS

    drivers/staging/ozwpan/ozhcd.c | 8 ++++----
    drivers/staging/ozwpan/ozusbif.h | 4 ++--
    drivers/staging/ozwpan/ozusbsvc1.c | 11 +++++++++--
    3 files changed, 15 insertions(+), 8 deletions(-)

    --
    2.3.6



    \
     
     \ /
      Last update: 2015-05-13 21:21    [W:4.186 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site