Re: [ANNOUNCE] CVE-2018-1313: Apache Derby externally-controlled input vulnerability

[Bryan Pendleton <bpendleton.derby () gmail com>]

Yes, Tomas, that is a very good point; I agree completely.

Thank you for the follow-ups and discussion!

bryan

On Mon, May 21, 2018 at 5:57 AM, Tomas Hoger <thoger () redhat com> wrote:
> On Mon, 14 May 2018 21:04:58 -0700 Bryan Pendleton wrote:
>
> > Hi Tomas, thank you for getting in touch, and for the excellent questions.
> >
> > I think the problem here is primarily my lack of skill in clearly writing
> > disclosure information about vulnerabilities, so let me try to do my best
> > to clarify.
> >
> > Indeed, allowing the Derby server to open an untrusted database is
> > of serious concern, and, due to Derby's rich extensibility features, can
> > allow the execution of arbitrary *Java* code directly in Derby. So this
> > is an important concern.
> >
> > And yes, you are correct that the selection of 10.3.1.4 as the first
> > affected release is because the default security policy dates from
> > that release, and you are also correct that the "ping with arguments"
> > pre-dates that. We certainly hope that nobody is running such 11-year-old
> > software any more; if possible, we would really like them to upgrade.
> >
> > Regarding the question of which fix is the "actual security fix," I find
> > this a challenging question. In order to exploit the vulnerability, the
> > ping command must allow the specially crafted request packet, *and*
> > the security policy must allow the access to the untrusted database.
> > Closing *either* of those holes is enough to prevent that exploit; we chose
> > to close *both* of them with the 10.14.2.0 release.
> >
> > The Derby development team's primary recommendation is that
> > any Derby Network Server deployed in a production environment
> > should use an explicitly-developed custom security policy, and not
> > depend on the default policy; still, the new security policy that is
> > installed by default by 10.14.2.0 is considerably more secure than
> > the policy that was previously in place.
> >
> > I hope this helps. If I have misunderstood the intent of any of your
> > questions, please let me know.
>
> Thank you for your detailed reply.  It addresses my questions.
>
> FWIW, in this case, the change of the ping command handling is what I'd
> view as the security fix.  The change of the default security policy
> would not be sufficient in deployments where custom security policy is
> used and that policy is less restrictive than the new default policy
> (even though it's maybe more restrictive than the old default).
>
> --
> Tomas Hoger / Red Hat Product Security