[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANi-yg8cdZzBMZRv_siCMwt8gfLWrtPvyO_vGNgGvzcAC-QngA@mail.gmail.com>
Date: Mon, 14 May 2018 21:04:58 -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
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.
thanks,
bryan
On Mon, May 14, 2018 at 5:52 AM, Tomas Hoger <thoger@...hat.com> wrote:
> Hi Bryan!
>
> On Sat, 5 May 2018 07:52:08 -0700 Bryan Pendleton wrote:
>
>> CVE-2018-1313: Apache Derby externally-controlled input vulnerability
>>
>> Severity: Important
>>
>> Vendor:
>> The Apache Software Foundation
>>
>> Versions Affected:
>> Derby 10.3.1.4 to 10.14.1.0
>>
>> Description:
>> A specially-crafted network packet can be used to request the Derby
>> Network Server to boot a database whose location and contents are under
>> the user's control. If the Derby Network Server is not running with a
>> Java Security Manager policy file, the attack is successful. If the
>> server is using a policy file, the policy file must permit the
>> database location to be read for the attack to work. The default
>> Derby Network Server policy file distributed with the affected releases
>> includes a permissive policy as the default Network Server policy, which
>> allows the attack to work.
>>
>> Mitigation:
>> Users should specify an explicit security policy file, as described here:
>> http://db.apache.org/derby/docs/10.14/security/csecjavasecurity.html
>>
>> Derby release 10.14.2.0 disallows the specially-crafted network packet,
>> and also modifies the default Derby Network Server policy file to be
>> significantly less permissive (the default file access policy is now
>> limited to the derby.system.home directory and the directory from
>> which the Derby jar files were loaded). It is still recommended that
>> production installations of the Derby Network Server should specify
>> an explicit security policy file.
>>
>> Credit:
>> This issue was discovered by Grégory Draperi
>
> Can you clarify what upstream considers to be the fix for this issue?
> Some sources such as:
>
> http://www.systemtek.co.uk/2018/05/apache-derby-externally-controlled-input-vulnerability-cve-2018-1313/
>
> indicate that the fix is the change to the default security policy,
> i.e. DERBY-6987. However, the wording above seems to consider that as
> more of an additional hardening fix, and the actual security fix is
> change to handling of the ping command to disallow additional
> arguments, i.e. DERBY-6986.
>
> Related to the above is the question regarding the list of affected
> versions. Version 10.3.1.4 is listed as the first affected, however
> the "ping with arguments" should pre-date that version, and even
> DERBY-6986 indicates it's old code. However, 10.3.1.4 seems to be the
> first version to include the default security policy, which may be the
> reason why it's listed as the first affected.
>
> And one more clarification for those of us not familiar with Derby:
> What is the known impact of opening some untrusted database? Is it
> known to e.g. allow arbitrary code execution directly in Derby?
>
> Thank you!
>
> --
> 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.
