[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 26 May 2018 06:53:09 -0700
From: Bryan Pendleton <bpendleton.derby@...il.com>
To: Tomas Hoger <thoger@...hat.com>
Cc: oss-security@...ts.openwall.com, security <security@...che.org>,
gregory draperi <gregory.draperi@...il.com>
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!
bryan
On Mon, May 21, 2018 at 5:57 AM, Tomas Hoger <thoger@...hat.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
