Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 26 May 2018 06:53:09 -0700
From: Bryan Pendleton <>
To: Tomas Hoger <>
Cc:, security <>, 
	gregory draperi <>
Subject: Re: [ANNOUNCE] CVE-2018-1313: Apache Derby
 externally-controlled input vulnerability

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

Thank you for the follow-ups and discussion!


On Mon, May 21, 2018 at 5:57 AM, Tomas Hoger <> 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 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 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 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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ