lkml.org 
[lkml]   [2015]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [oss-security] [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities
On Wed, May 13, 2015 at 08:33:30PM +0200, Jason A. Donenfeld wrote:
> 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(-)

Any reason you didn't cc: the maintainer who could actually apply these
to the kernel tree?

Please use scripts/get_maintainer.pl to properly notify the correct
people.

thanks,

greg k-h


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