netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: shigekatsu.tateno@atmel.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, oss-security@lists.openwall.com
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities
Date: Wed, 13 May 2015 20:33:30 +0200	[thread overview]
Message-ID: <1431542014-3239-1-git-send-email-Jason@zx2c4.com> (raw)

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

             reply	other threads:[~2015-05-13 18:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 18:33 Jason A. Donenfeld [this message]
2015-05-13 18:33 ` [PATCH 1/4] ozwpan: Use proper check to prevent heap overflow Jason A. Donenfeld
2015-05-15 15:02   ` David Laight
2015-05-16 10:20     ` Charles (Chas) Williams
2015-05-13 18:33 ` [PATCH 2/4] ozwpan: Use unsigned ints " Jason A. Donenfeld
2015-05-13 18:33 ` [PATCH 3/4] ozwpan: divide-by-zero leading to panic Jason A. Donenfeld
2015-05-13 18:33 ` [PATCH 4/4] ozwpan: unchecked signed subtraction leads to DoS Jason A. Donenfeld
2015-05-13 18:43 ` [oss-security] [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities Greg KH
2015-05-13 18:48   ` Jason A. Donenfeld
2015-05-13 18:53     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1431542014-3239-1-git-send-email-Jason@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oss-security@lists.openwall.com \
    --cc=shigekatsu.tateno@atmel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).