Re: KASAN: use-after-free Read in hci_chan_del

Re: KASAN: use-after-free Read in hci_chan_del

[Jason A. Donenfeld]

Hi SyzScope,

On Fri, May 28, 2021 at 02:12:01PM -0700, SyzScope wrote:
 
> The bug was reported by syzbot first in Aug 2020. Since it remains 
> unpatched to this date, we have conducted some analysis to determine its 
> security impact and root causes, which hopefully can help with the 
> patching decisions.
> Specifically, we find that even though it is labeled as "UAF read" by 
> syzbot, it can in fact lead to double free and control flow hijacking as 
> well. Here is our analysis below (on this kernel version: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af5043c89a8ef6b6949a245fff355a552eaed240)
> 
> ----------------------------- Root cause analysis: 
> --------------------------
> The use-after-free bug happened because the object has two different 
> references. But when it was freed, only one reference was removed, 
> allowing the other reference to be used incorrectly.
> [...]

Thank you very much for your detailed analysis. I think this is very
valuable work, and I appreciate you doing it. I wanted to jump in to
this thread here so as not to discourage you, following Greg's hasty
dismissal. The bad arguments made I've seen have been something like:

- Who cares about the impact? Bugs are bugs and these should be fixed
  regardless. Severity ratings are a waste of time.
- Spend your time writing patches, not writing tools to discover
  security issues.
- This doesn't help my interns.
- "research project" scare quotes.

I think this entire set of argumentation is entirely bogus, and I really
hope it doesn't dissuade you from continuing to conduct useful research
on the kernel.

Specifically, it sounds like your tool is scanning through syzbot
reports, loading them into a symbolic execution engine, and seeing what
other primitives you can finesse out of the bugs, all in an automated
way. So, in the end, a developer gets a report that, rather than just
saying "4 byte out of bounds read into all zeroed memory so not a big
deal anyway even if it should be fixed," the developer gets a report
that says, "4 byte out of bounds read, or a UaF if approached in this
other way." Knowing that seems like very useful information, not just
for prioritization, but also for the urgency at which patches might be
deployed. For example, that's a meaningful distinction were that kind of
bug found in core networking stack or in wifi or ethernet drivers. I
also think it's great that you're pushing forward the field of automated
vulnerability discovery and exploit writing. Over time, hopefully that
leads to crushing all sorts of classes of bugs. It's also impressive
that you're able to do so much with kernel code in a symbolic execution
environment; this sounds a few steps beyond Angr ;-)...

My one suggestion would be that your email alerts / follow-ups to syzbot
reports, if automated, contain a bit more "dumbed-down" information
about what's happening. Not all kernel developers speak security, and as
you've seen, in some places it might be an uphill battle to have your
contributions taken seriously. On the other hand, it sounds like you
might already be working with Dmitry to integrate this into the
syzkaller infrastructure itself, somehow? If so, that'd be great.

Regards,
Jason

Re: KASAN: use-after-free Read in hci_chan_del

[Dmitry Vyukov]

On Mon, Jun 7, 2021 at 12:21 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi SyzScope,
>
> On Fri, May 28, 2021 at 02:12:01PM -0700, SyzScope wrote:
>
> > The bug was reported by syzbot first in Aug 2020. Since it remains
> > unpatched to this date, we have conducted some analysis to determine its
> > security impact and root causes, which hopefully can help with the
> > patching decisions.
> > Specifically, we find that even though it is labeled as "UAF read" by
> > syzbot, it can in fact lead to double free and control flow hijacking as
> > well. Here is our analysis below (on this kernel version:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af5043c89a8ef6b6949a245fff355a552eaed240)
> >
> > ----------------------------- Root cause analysis:
> > --------------------------
> > The use-after-free bug happened because the object has two different
> > references. But when it was freed, only one reference was removed,
> > allowing the other reference to be used incorrectly.
> > [...]
>
> Thank you very much for your detailed analysis. I think this is very
> valuable work, and I appreciate you doing it. I wanted to jump in to
> this thread here so as not to discourage you, following Greg's hasty
> dismissal. The bad arguments made I've seen have been something like:
>
> - Who cares about the impact? Bugs are bugs and these should be fixed
>   regardless. Severity ratings are a waste of time.
> - Spend your time writing patches, not writing tools to discover
>   security issues.
> - This doesn't help my interns.
> - "research project" scare quotes.
>
> I think this entire set of argumentation is entirely bogus, and I really
> hope it doesn't dissuade you from continuing to conduct useful research
> on the kernel.
>
> Specifically, it sounds like your tool is scanning through syzbot
> reports, loading them into a symbolic execution engine, and seeing what
> other primitives you can finesse out of the bugs, all in an automated
> way. So, in the end, a developer gets a report that, rather than just
> saying "4 byte out of bounds read into all zeroed memory so not a big
> deal anyway even if it should be fixed," the developer gets a report
> that says, "4 byte out of bounds read, or a UaF if approached in this
> other way." Knowing that seems like very useful information, not just
> for prioritization, but also for the urgency at which patches might be
> deployed. For example, that's a meaningful distinction were that kind of
> bug found in core networking stack or in wifi or ethernet drivers. I
> also think it's great that you're pushing forward the field of automated
> vulnerability discovery and exploit writing. Over time, hopefully that
> leads to crushing all sorts of classes of bugs. It's also impressive
> that you're able to do so much with kernel code in a symbolic execution
> environment; this sounds a few steps beyond Angr ;-)...
>
> My one suggestion would be that your email alerts / follow-ups to syzbot
> reports, if automated, contain a bit more "dumbed-down" information
> about what's happening. Not all kernel developers speak security, and as
> you've seen, in some places it might be an uphill battle to have your
> contributions taken seriously. On the other hand, it sounds like you
> might already be working with Dmitry to integrate this into the
> syzkaller infrastructure itself, somehow? If so, that'd be great.

We discussed this with authors, but no integration work is happening
right now yet.
Yes, it would be useful for syzbot to do this assessment automatically
for all bugs and, say, tag bugs on the dashboard (less noisy then
sending separate emails). If/when syzbot sends, say, monthly
per-subsystem summary, that priority info could also be included
there.

Re: KASAN: use-after-free Read in hci_chan_del

[Greg KH]

On Mon, Jun 07, 2021 at 12:21:12PM +0200, Jason A. Donenfeld wrote:
> Hi SyzScope,
> 
> On Fri, May 28, 2021 at 02:12:01PM -0700, SyzScope wrote:
>  
> > The bug was reported by syzbot first in Aug 2020. Since it remains 
> > unpatched to this date, we have conducted some analysis to determine its 
> > security impact and root causes, which hopefully can help with the 
> > patching decisions.
> > Specifically, we find that even though it is labeled as "UAF read" by 
> > syzbot, it can in fact lead to double free and control flow hijacking as 
> > well. Here is our analysis below (on this kernel version: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af5043c89a8ef6b6949a245fff355a552eaed240)
> > 
> > ----------------------------- Root cause analysis: 
> > --------------------------
> > The use-after-free bug happened because the object has two different 
> > references. But when it was freed, only one reference was removed, 
> > allowing the other reference to be used incorrectly.
> > [...]
> 
> Thank you very much for your detailed analysis. I think this is very
> valuable work, and I appreciate you doing it. I wanted to jump in to
> this thread here so as not to discourage you, following Greg's hasty
> dismissal. The bad arguments made I've seen have been something like:
> 
> - Who cares about the impact? Bugs are bugs and these should be fixed
>   regardless. Severity ratings are a waste of time.
> - Spend your time writing patches, not writing tools to discover
>   security issues.
> - This doesn't help my interns.
> - "research project" scare quotes.
> 
> I think this entire set of argumentation is entirely bogus, and I really
> hope it doesn't dissuade you from continuing to conduct useful research
> on the kernel.

Ok, I'd like to apologize if that was the attitude that came across
here, as I did not mean it that way.

What I saw here was an anonymous email, saying "here is a whole bunch of
information about a random syzbot report that means you should fix this
sooner!"  When there's a dump this big of "information", but no patch,
that's almost always a bad sign that the information really isn't all
that good, otherwise the author would have just sent a patch to fix it.

We are drowning in syzbot bugs at the moment, with almost no one helping
to fix them.  So much so that the only people I know of working on this
are the interns with with the LF has funded because no other company
seems willing to help out with this task.

That's not the syzbot author's fault, it's the fault of every other
company that relies on Linux at the moment.  By not providing time for
their engineers to fix these found bugs, and only add new features, it's
not going to get any better.

So this combined two things I'm really annoyed at, anonymous
contributions combined with "why are you not fixing this" type of
a report.  Neither of which were, in the end, actually helpful to us.

I'm not asking for any help for my interns, nor am I telling anyone what
to work on.  I am saying please don't annoy the maintainers who are
currently overwhelmed at the moment with additional reports of this type
when they obviously can not handle the ones that we have.

Working with the syzbot people to provide a more indepth analysis of the
problem is wonderful, and will go a long way toward helping being able
to do semi-automatic fixing of problems like this, which would be
wonderful.  But how were we supposed to know this anonymous gmail
account, with a half-completed google pages web site was not just a
troll trying to waste our time?

What proof did we have that this really was a correct report if a real
person didn't even provide their name to it?

thanks,

greg k-h

Re: KASAN: use-after-free Read in hci_chan_del

[SyzScope]

Hi all,
We are really thankful for all the suggestions and concerns. We are 
definitely interested in continuing this line of research.

Just to clarify:  SyzScope is an ongoing research project that is 
currently under submission, which has an anonymity requirement. 
Therefore we chose to use a gmail address initially in the public 
channel. Since Greg asked, we did reveal our university affiliation and 
email address, as well as cross-referenced a private email (again using 
university address) to security@kernel.org. We are sorry for the chaos 
of using several different email addresses. In the future, we will try 
to use our university address directly (we checked with other 
researchers and it seems to be okay).

On 6/7/2021 4:20 AM, Greg KH wrote:
> On Mon, Jun 07, 2021 at 12:21:12PM +0200, Jason A. Donenfeld wrote:
>> Hi SyzScope,
>>
>> On Fri, May 28, 2021 at 02:12:01PM -0700, SyzScope wrote:
>>   
>>> The bug was reported by syzbot first in Aug 2020. Since it remains
>>> unpatched to this date, we have conducted some analysis to determine its
>>> security impact and root causes, which hopefully can help with the
>>> patching decisions.
>>> Specifically, we find that even though it is labeled as "UAF read" by
>>> syzbot, it can in fact lead to double free and control flow hijacking as
>>> well. Here is our analysis below (on this kernel version:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af5043c89a8ef6b6949a245fff355a552eaed240)
>>>
>>> ----------------------------- Root cause analysis:
>>> --------------------------
>>> The use-after-free bug happened because the object has two different
>>> references. But when it was freed, only one reference was removed,
>>> allowing the other reference to be used incorrectly.
>>> [...]
>> Thank you very much for your detailed analysis. I think this is very
>> valuable work, and I appreciate you doing it. I wanted to jump in to
>> this thread here so as not to discourage you, following Greg's hasty
>> dismissal. The bad arguments made I've seen have been something like:
>>
>> - Who cares about the impact? Bugs are bugs and these should be fixed
>>    regardless. Severity ratings are a waste of time.
>> - Spend your time writing patches, not writing tools to discover
>>    security issues.
>> - This doesn't help my interns.
>> - "research project" scare quotes.
>>
>> I think this entire set of argumentation is entirely bogus, and I really
>> hope it doesn't dissuade you from continuing to conduct useful research
>> on the kernel.
> Ok, I'd like to apologize if that was the attitude that came across
> here, as I did not mean it that way.
>
> What I saw here was an anonymous email, saying "here is a whole bunch of
> information about a random syzbot report that means you should fix this
> sooner!"  When there's a dump this big of "information", but no patch,
> that's almost always a bad sign that the information really isn't all
> that good, otherwise the author would have just sent a patch to fix it.
>
> We are drowning in syzbot bugs at the moment, with almost no one helping
> to fix them.  So much so that the only people I know of working on this
> are the interns with with the LF has funded because no other company
> seems willing to help out with this task.
>
> That's not the syzbot author's fault, it's the fault of every other
> company that relies on Linux at the moment.  By not providing time for
> their engineers to fix these found bugs, and only add new features, it's
> not going to get any better.
>
> So this combined two things I'm really annoyed at, anonymous
> contributions combined with "why are you not fixing this" type of
> a report.  Neither of which were, in the end, actually helpful to us.
>
> I'm not asking for any help for my interns, nor am I telling anyone what
> to work on.  I am saying please don't annoy the maintainers who are
> currently overwhelmed at the moment with additional reports of this type
> when they obviously can not handle the ones that we have.
>
> Working with the syzbot people to provide a more indepth analysis of the
> problem is wonderful, and will go a long way toward helping being able
> to do semi-automatic fixing of problems like this, which would be
> wonderful.  But how were we supposed to know this anonymous gmail
> account, with a half-completed google pages web site was not just a
> troll trying to waste our time?
>
> What proof did we have that this really was a correct report if a real
> person didn't even provide their name to it?
>
> thanks,
>
> greg k-h

Re: KASAN: use-after-free Read in hci_chan_del

[Greg KH]

On Mon, Jun 07, 2021 at 11:26:26AM -0700, SyzScope wrote:
> Hi all,
> We are really thankful for all the suggestions and concerns. We are
> definitely interested in continuing this line of research.
> 
> Just to clarify:  SyzScope is an ongoing research project that is currently
> under submission, which has an anonymity requirement.

As documented, we can not accept anonymous contributions to the kernel,
so perhaps just wait until your paper is accepted?  However, we take
patches from researchers all the time under their real names while their
papers are being reviewed, so this "requirement" seems odd to me, who is
requiring this?

> Therefore we chose to
> use a gmail address initially in the public channel. Since Greg asked, we
> did reveal our university affiliation and email address, as well as
> cross-referenced a private email (again using university address) to
> security@kernel.org.

security@kernel.org is for fixing bugs reported to them that are not
public, it is not for any sort of "notification of affiliation".  See
the documentation for the details about what this alias is to be used
for please.

> We are sorry for the chaos of using several different
> email addresses. In the future, we will try to use our university address
> directly (we checked with other researchers and it seems to be okay).

That would be best, as obviously, and again, as documented, we can not
accept anonymous contributions to the kernel.

greg k-h

Re: KASAN: use-after-free Read in hci_chan_del

[Dan Carpenter]

This SyzScope stuff could be good in theory and it could be something
useful with more work.  But in real life terms do you know anyone who
looked at "use-after-free Read in hci_chan_del" and thought, "Oh that
sounds totally harmless."

regards,
dan carpenter

Re: [syzbot] KASAN: use-after-free Read in hci_chan_del

[syzbot]

syzbot suspects this issue was fixed by commit:

commit 43016d02cf6e46edfc4696452251d34bba0c0435
Author: Florian Westphal <fw@strlen.de>
Date:   Mon May 3 11:51:15 2021 +0000

    netfilter: arptables: use pernet ops struct during unregister

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1325d967d00000
start commit:   af5043c8 Merge tag 'acpi-5.10-rc4' of git://git.kernel.org..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=f9aa2432c01bcb1f
dashboard link: https://syzkaller.appspot.com/bug?extid=305a91e025a73e4fd6ce
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=130152a1500000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=102b1bba500000

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: netfilter: arptables: use pernet ops struct during unregister

For information about bisection process see: https://goo.gl/tpsmEJ#bisection