Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]

Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]

[Jason A. Donenfeld]

Hi all,

With four security critical bug patches having finally been put in
Greg's for-linus branch [1][2][3][4], I'd like to turn attention back
at the bigger issue. Where is the maintainer of this driver during
these discussions? The MAINTAINERS file lists Shigekatsu Tateno, and
in a commit [5] from May of last year, Rupesh Gujare turned over
maintenance to him.

I ask because I also noted another important vulnerability in my
original patch series cover letter, with the hope that the actual
maintainer would take care of patching this, as it is likely a little
bit nuanced:

On Wed, May 13, 2015 at 8:33 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 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.

It seems a bit odd to not receive any review from the actual
maintainer, and seeing that there is still a pending security issue
that hasn't been addressed, I wonder if we should revisit what Dan
suggested last week:

On Thu, May 28, 2015 at 1:04 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Maybe we should just delete these ozwpan drivers entirely...  They were
> merged when Ozmodevices was its own company and I don't think anyone is
> working on them any more.

I know for a fact that the drivers *are* in use places, though not
necessarily with the upstream codebase. Also, it was more or less
exactly a year ago when Atmel appointed the new maintainer, which
makes me hope that somebody there still cares about them. But I'm not
sure exactly.

What's the best way to proceed? Is anybody in a position to reach out
and nudge the maintainer? Or is it just the case that Atmel's vacation
policy is awesome, and he's just been hanging out on the beach, and
I'm jumping the gun with this email?


Thanks,
Jason


[1] https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=d114b9fe78c8d6fc6e70808c2092aa307c36dc8e
[2] https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=b1bb5b49373b61bf9d2c73a4d30058ba6f069e4c
[3] https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=04bf464a5dfd9ade0dda918e44366c2c61fce80b
[4] https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/?id=9a59029bc218b48eff8b5d4dde5662fd79d3e1a8
[5] https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/commit/drivers/staging/ozwpan?h=staging-linus&id=96747a8f4e7d187f236ad392d86a37a4d1ba0b32

Re: Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]

[Greg Kroah-Hartman]

On Mon, Jun 01, 2015 at 03:34:57PM +0200, Jason A. Donenfeld wrote:
> Hi all,
> 
> With four security critical bug patches having finally been put in
> Greg's for-linus branch [1][2][3][4], I'd like to turn attention back
> at the bigger issue. Where is the maintainer of this driver during
> these discussions? The MAINTAINERS file lists Shigekatsu Tateno, and
> in a commit [5] from May of last year, Rupesh Gujare turned over
> maintenance to him.
> 
> I ask because I also noted another important vulnerability in my
> original patch series cover letter, with the hope that the actual
> maintainer would take care of patching this, as it is likely a little
> bit nuanced:
> 
> On Wed, May 13, 2015 at 8:33 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > 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.
> 
> It seems a bit odd to not receive any review from the actual
> maintainer, and seeing that there is still a pending security issue
> that hasn't been addressed, I wonder if we should revisit what Dan
> suggested last week:
> 
> On Thu, May 28, 2015 at 1:04 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > Maybe we should just delete these ozwpan drivers entirely...  They were
> > merged when Ozmodevices was its own company and I don't think anyone is
> > working on them any more.
> 
> I know for a fact that the drivers *are* in use places, though not
> necessarily with the upstream codebase. Also, it was more or less
> exactly a year ago when Atmel appointed the new maintainer, which
> makes me hope that somebody there still cares about them. But I'm not
> sure exactly.
> 
> What's the best way to proceed? Is anybody in a position to reach out
> and nudge the maintainer? Or is it just the case that Atmel's vacation
> policy is awesome, and he's just been hanging out on the beach, and
> I'm jumping the gun with this email?

I don't know, but I'm a bit loath to delete the driver from the tree as
then people will just continue to use the version with all of the bugs.

If Atmel doesn't want to maintain the code anymore, do you want to do
it?  You can always send patches for this issue, as you seem to have the
hardware and can do testing, which I can't.

thanks,

greg k-h

Re: Future of Ozwpan Driver - Maintainer? [Was: Re: [PATCH 0/4] ozwpan: Four remote packet-of-death vulnerabilities]

[Jason A. Donenfeld]

On Tue, Jun 2, 2015 at 3:35 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> I don't know, but I'm a bit loath to delete the driver from the tree as
> then people will just continue to use the version with all of the bugs.

Yea, I understand that. Though, I'm pretty sure that most users of
ozwpan use old forks tied to old kernels, and do not use upstream
anyway.

> If Atmel doesn't want to maintain the code anymore, do you want to do
> it?  You can always send patches for this issue, as you seem to have the
> hardware and can do testing, which I can't.

Thank you for the offer, and I would actually love to maintain a part
of the kernel. But I am likely the wrong man for ozwpan (inspite of
the Internet's claims of my wizardry [1]). The debugging I've done
thus far is on a readily available consumer embedded device, which I
was required to root and unsandbox and partake in other "security dark
magic" in order to get a decent debugging interface. My rig is rather
brittle and is likely to fall to pieces like aging solder at any
moment. I'd recommend this be maintained by someone with proper test
hardware and a suit of unit tests. This means: Atmel, or one of the
many clients to whom Atmel has sold high volumes of ozwpan chips. I'll
reach out where I can to see if I can find someone in a good position
to maintain it.

[1] https://twitter.com/drgfragkos/status/598776229282578432