Re: Re: More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit meth

["PaX Team" <pageexec () freemail hu>]

On 26 Jun 2017 at 16:59, Kurt Seifried wrote:
> On 2017-06-26 3:50 PM, PaX Team wrote:
> > On 26 Jun 2017 at 13:47, Kurt Seifried wrote:
> >
> > > I think we can agree as a community of professionals that insults and name
> > > calling are unnecessary and also not very effective.
> > I completely agree with you but then I can't explain why you chose to insult
> > our projects last week and still have not remedied it (both the CVE and your
> > insulting tweet are still up). I find it curious how you can preach about
> > professionalism after being the very instigator of the recent splat (heck,
> > instead of answering, you called it a conspiracy theory when I asked you in
> > private why you issued the CVE to begin with which then forced us to take
> > the issue public).
> So as per the private email thread we had previously I'm not going to be
> interacting with you beyond what is strictly neccesary for CVE and other
> professional purposes.

Since your professional job is to issue CVEs and you did so in our case based
on an erroneous judgement call, I believe it falls into this category.

> One the CVE REJECT side, CVE-2017-1000377 looks legitimate,

You have yet to explain why it is so. The Qualys advisory and their explicit
reject requests state the exact opposite.

> although I'm inclined to agree with Qualys and REJECT it so that you stop emailing.

I will stop emailing you when you live up to your professional obligation
and make sure that the CVE you issued in error is rescinded.

> I did contact MITRE, I haven't had time to reply to them yet (they are
> also wondering why the CVE needs REJECT'ing), as such I think it may be
> best to recuse myself from this specific CVE and let you handle this
> with MITRE. I have also previously told you how to go about doing this.

You said that the requestor has to ask for the rejection. Since you are the
requestor, only you can do so though you tried to drag Qualys into this.
They still made the reject request a week ago but you haven't acted on it
yet despite your promise to do so. Now you're telling us that we have yet
something else to do? Please elaborate as your past communications didn't
explain any further.

> I will say that CVE identifiers doesn't just cover full code execution
> flaws, but also covers situations where for example a security property
> is claimed but is not as effective as we thought (e.g. the stackguard
> page size in this case). Many CVE's are not fully exploitable on their
> own but are part of an exploit chain.

What security property did we claim for the kernel enforced heap-stack
gap size? Can you recite anything we said anywhere about that supports
your claim?

cheers,
  PaX Team