[CVE-2017-15694] Apache Geode metadata modification vulnerability

[Anthony Baker]

CVE-2017-15694 Apache Geode metadata modification vulnerability

Severity: Medium

Vendor: The Apache Software Foundation

Versions Affected:
Apache Geode 1.0.0 through 1.8.0

Description:
When a Geode server is operating in secure mode, a user with write
permissions for specific data regions can modify internal cluster
metadata.  A malicious user could modify this data in a way that affects
the operation of the cluster.

Mitigation:
Users of the affected versions should upgrade to Apache Geode 1.9.0 or
later.

Credit:
This issue was reported responsibly to the Apache Geode Security Team by
Jason Huynh from Pivotal.

References:
[1] https://issues.apache.org/jira/browse/GEODE-3981
[2]
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-SecurityVulnerabilities

---
The Geode PMC

[DISCUSS] Add a test dependency to geode-core - ArchUnit

[Dan Smith]

Hi all,

Bill, Ernie, and I would like to add a new (apache licensed) test
dependency to geode-core - https://github.com/TNG/ArchUnit. This is a tool
that lets you write tests that make assertions about the interdependencies
of your code - for example enforcing that package A does not depend on
package B.

Initially we intend to add some tests about what parts of the system the
org.apache.geode.distributed.internal.membership package depends on, with
an eye towards making that code more independently testable (proposal on
that coming soon!).

Does anyone have an issue with adding this test dependency?

-Dan

Re: [PROPOSAL]: Improve OQL Method Invocation Security

[Dan Smith]

+1

This looks really good!

I put a couple of comments inline, and I have a few more general questions
here:
1. Is the RegionQueryInvocationAuthorizer different than our existing shiro
permissions? I thought users can already grant permissions for specific
regions. What does this add in addition to that?
2. I'm a little unclear on if your
MethodInvocationAuthorizer.authorizeMethodInvocation is supposed to take a
region or the target object. If it is really accepting a region, do we
actually have a region available in all cases? We could be invoking methods
on an object in lots of places in the query tree.
3. The DataAwareBasedMethodAuthorizer seems a bit vague on how it's
actually going to work. It also might be a security risk, since it will
allow users with DATA:READ permission to invoke any method on these objects.

-Dan

On Wed, Jun 19, 2019 at 11:34 AM Jacob Barrett  wrote:

> Thanks Juan!
>
> > On Jun 19, 2019, at 9:55 AM, Juan José Ramos  wrote:
> >
> > Hello all,
> >
> > I've removed all "biased" words I could find from the original document
> so
> > the *Proposal [1]* is ready for review and discussion now. All feedback
> is
> > welcome.
> > Best regards.
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security
> >
> >> On Fri, Jun 14, 2019 at 8:39 PM Juan José Ramos 
> wrote:
> >>
> >> Hey Jake,
> >>
> >> Thanks for bringing this up. As you might have found out already,
> english
> >> is not my native language, I actually had to do some research to find
> out
> >> *exactly what you meant* regarding the bias around the "whitelist" word
> >> :-|... It was an honest mistake and I sincerely apologize in advance if
> >> anyone got offended in any way.
> >> That said, I won't have time to go through the proposal and make the
> >> required changes until next week, so I'll keep the document hidden until
> >> all biased words are replaced.
> >> Cheers.
> >>
> >>
> >> On Sat, Jun 15, 2019 at 12:25 AM Jacob Barrett 
> >> wrote:
> >>
>  As part of GEODE-3247 <
> https://issues.apache.org/jira/browse/GEODE-3247>,
> >>> several options were analysed and, after considering the wealth of
> security
> >>> holes and the difficulty of determining which methods deployed by the
> >>> developer were intended to be available for queries and which were
> not, the
> >>> decision was made to tighten up the Security and, by default, disallow
> any
> >>> method call not explicitly whitelisted.
> >>>
> >>> Please avoid biased words, like whitelist, in source and proposals.
> There
> >>> are several other places in this document that use these terms. Can you
> >>> please update the document without them.
> >>>
> >>> Thanks,
> >>> Jake
> >>>
> >>>
> >>
> >> --
> >> Juan José Ramos Cassella
> >> Senior Technical Support Engineer
> >> Email: jra...@pivotal.io
> >> Office#: +353 21 4238611
> >> Mobile#: +353 87 2074066
> >> After Hours Contact#: +1 877 477 2269
> >> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> >> How to upload artifacts:
> >> https://support.pivotal.io/hc/en-us/articles/204369073
> >> How to escalate a ticket:
> >> https://support.pivotal.io/hc/en-us/articles/203809556
> >>
> >> [image: support]  [image: twitter]
> >>  [image: linkedin]
> >>  [image: facebook]
> >>  [image: google plus]
> >>  [image: youtube]
> >> <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
> >>
> >
> >
> > --
> > Juan José Ramos Cassella
> > Senior Technical Support Engineer
> > Email: jra...@pivotal.io
> > Office#: +353 21 4238611
> > Mobile#: +353 87 2074066
> > After Hours Contact#: +1 877 477 2269
> > Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> > How to upload artifacts:
> > https://support.pivotal.io/hc/en-us/articles/204369073
> > How to escalate a ticket:
> > https://support.pivotal.io/hc/en-us/articles/203809556
> >
> > [image: support]  [image: twitter]
> >  [image: linkedin]
> >  [image: facebook]
> >  [image: google plus]
> >  [image: youtube]
> > <
> https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
>

Re: "Output path is not specified for module" (IntelliJ)

[Eric Shu]

Here is my settings. I only set ‘inherit project compile path’ when it is
needed.
[image: image.png]

On Thu, Jun 20, 2019 at 1:28 PM Murtuza Boxwala  wrote:

> Eric,
>
> Can you please share a screen shot of your gradle preferences in Intellij
> (I attached mine, too).  I tried Jens’ solution and used the Gradle builder
> and the IntelliJ test runner and it works okay, but I don’t think I am
> getting the advantage of intellij’s continuous incremental building in the
> background.  This adds 10’ish seconds to my TDD loop because it has to keep
> compiling geode-core:test.
>
> I saw the options to ‘inherit project compile path’ but there were tons of
> modules and I am not sure if I have to set it on all of them.
>
> If anyone else has build and test working with IntelliJ and knows what I
> am doing wrong, please chime in.
>
> Thanks,
> Murtuza
>
> On Jun 6, 2019, at 8:12 PM, Eric Shu  wrote:
>
> I worked around this issue by choosing Inherit project compile output path.
>
> On Thu, Jun 6, 2019 at 3:16 PM Jens Deppe  wrote:
>
> I have only experienced this when I switch to building with IntelliJ (it is
> also dependent on what Intellij deems necessary to build). Building with
> gradle has never produced this. My setup is to build with gradle but run
> tests with IntelliJ. I've never had to do any kind of re-import for this.
>
> Re-import feels somewhat like an OS re-install. My suggestion would be: do
> a clean CLI gradle build first. Then do a full project rebuild in IJ.
>
> --Jens
>
> On Thu, Jun 6, 2019 at 12:06 PM Ryan McMahon 
> wrote:
>
> Fair warning - some have wiped their .idea file and it works temporarily,
> but inevitably will return.  I would recommend the setting changes as
> described above if it recurs.
>
> Ryan
>
> On Thu, Jun 6, 2019 at 12:04 PM Peter Tran  wrote:
>
> Awesome - a wipe of my .idea file worked. Thank you!
>
> On Thu, Jun 6, 2019 at 2:54 PM Jacob Barrett 
>
> wrote:
>
>
> This seems to happen frequently with 2019.1. The easiest way I found
>
> to
>
> fix this was to start over with the IJ project.  Some have had luck
> switching between the gradle builder and the IJ builder in the cradle
> configuration panel.
>
> On Jun 6, 2019, at 11:47 AM, Peter Tran  wrote:
>
> Hello,
>
> Has anyone had an issue in IntelliJ running tests with the error:
>
> "Cannot start compilation: the output path is not specified for
>
> module"
>
>
> I setup intelliJ using the BUILDING.md instructions and haven't
>
> come
>
> across
>
> this problem. I haven't updated intelliJ since the last time I ran
>
> tests
>
> successfully. I haven't changed my JDK and am experiencing it on
>
> develop
>
>
> Thanks
>
>
>
>
>
>
>

Re: "Output path is not specified for module" (IntelliJ)

[Jacob Barrett]

Murtuza, If you are using the Gradle building it will take longer to than the 
built in IntelliJ builder. Mixing the Gradle builder and the IntelliJ test 
runner seems odd to me. Using the Gradle test running will ensure the the test 
runs exactly as it does in the CI. The downside is that IntelliJ thinks its a 
great idea to invoke clean on the test code before running it so it must always 
recompile. 

-Jake


> On Jun 20, 2019, at 1:28 PM, Murtuza Boxwala  wrote:
> 
> Eric,
> 
> Can you please share a screen shot of your gradle preferences in Intellij (I 
> attached mine, too).  I tried Jens’ solution and used the Gradle builder and 
> the IntelliJ test runner and it works okay, but I don’t think I am getting 
> the advantage of intellij’s continuous incremental building in the 
> background.  This adds 10’ish seconds to my TDD loop because it has to keep 
> compiling geode-core:test.
> 
> I saw the options to ‘inherit project compile path’ but there were tons of 
> modules and I am not sure if I have to set it on all of them.
> 
> If anyone else has build and test working with IntelliJ and knows what I am 
> doing wrong, please chime in. 
> 
> Thanks,
> Murtuza
> 
> 
>> On Jun 6, 2019, at 8:12 PM, Eric Shu > > wrote:
>> 
>> I worked around this issue by choosing Inherit project compile output path.
>> 
>> On Thu, Jun 6, 2019 at 3:16 PM Jens Deppe > > wrote:
>> 
>>> I have only experienced this when I switch to building with IntelliJ (it is
>>> also dependent on what Intellij deems necessary to build). Building with
>>> gradle has never produced this. My setup is to build with gradle but run
>>> tests with IntelliJ. I've never had to do any kind of re-import for this.
>>> 
>>> Re-import feels somewhat like an OS re-install. My suggestion would be: do
>>> a clean CLI gradle build first. Then do a full project rebuild in IJ.
>>> 
>>> --Jens
>>> 
>>> On Thu, Jun 6, 2019 at 12:06 PM Ryan McMahon >> >
>>> wrote:
>>> 
 Fair warning - some have wiped their .idea file and it works temporarily,
 but inevitably will return.  I would recommend the setting changes as
 described above if it recurs.
 
 Ryan
 
 On Thu, Jun 6, 2019 at 12:04 PM Peter Tran >>> > wrote:
 
> Awesome - a wipe of my .idea file worked. Thank you!
> 
> On Thu, Jun 6, 2019 at 2:54 PM Jacob Barrett  >
 wrote:
> 
>> This seems to happen frequently with 2019.1. The easiest way I found
>>> to
>> fix this was to start over with the IJ project.  Some have had luck
>> switching between the gradle builder and the IJ builder in the cradle
>> configuration panel.
>> 
>>> On Jun 6, 2019, at 11:47 AM, Peter Tran >> > wrote:
>>> 
>>> Hello,
>>> 
>>> Has anyone had an issue in IntelliJ running tests with the error:
>>> 
>>> "Cannot start compilation: the output path is not specified for
 module"
>>> 
>>> I setup intelliJ using the BUILDING.md instructions and haven't
>>> come
>> across
>>> this problem. I haven't updated intelliJ since the last time I ran
> tests
>>> successfully. I haven't changed my JDK and am experiencing it on
> develop
>>> 
>>> Thanks
>> 
> 
 
>>> 
> 

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

[Jacob Barrett]

Are you adding this dependency to just the membership module? I am cool with 
that.

> On Jun 20, 2019, at 2:39 PM, Dan Smith  wrote:
> 
> Hi all,
> 
> Bill, Ernie, and I would like to add a new (apache licensed) test
> dependency to geode-core - https://github.com/TNG/ArchUnit. This is a tool
> that lets you write tests that make assertions about the interdependencies
> of your code - for example enforcing that package A does not depend on
> package B.
> 
> Initially we intend to add some tests about what parts of the system the
> org.apache.geode.distributed.internal.membership package depends on, with
> an eye towards making that code more independently testable (proposal on
> that coming soon!).
> 
> Does anyone have an issue with adding this test dependency?
> 
> -Dan

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

[Dan Smith]

We don't have a membership gradle module, just a package. We're adding this
to geode-core.

For a little more context - we are thinking about refactoring membership
(and/or maybe some other pieces) into separate gradle modules - proposal
forthcoming! However, as a first step we need to untangle those pieces of
code from the rest of geode-core. Rather than creating some long lived
branch we can incrementally untangle the code a piece at a time, on
develop. Having a way to track progress and enforce the direction of
dependencies on the way to a separate gradle module will help with that.

-Dan

On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett  wrote:

> Are you adding this dependency to just the membership module? I am cool
> with that.
>
> > On Jun 20, 2019, at 2:39 PM, Dan Smith  wrote:
> >
> > Hi all,
> >
> > Bill, Ernie, and I would like to add a new (apache licensed) test
> > dependency to geode-core - https://github.com/TNG/ArchUnit. This is a
> tool
> > that lets you write tests that make assertions about the
> interdependencies
> > of your code - for example enforcing that package A does not depend on
> > package B.
> >
> > Initially we intend to add some tests about what parts of the system the
> > org.apache.geode.distributed.internal.membership package depends on, with
> > an eye towards making that code more independently testable (proposal on
> > that coming soon!).
> >
> > Does anyone have an issue with adding this test dependency?
> >
> > -Dan
>
>

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

[Michael Oleske]

Seems alright to me given the context that you're trying to separate code
into modules (and want to make sure you're not including packages you
shouldn't).  Looking forward to see how the progress goes!

-michael

On Thu, Jun 20, 2019 at 4:35 PM Dan Smith  wrote:

> We don't have a membership gradle module, just a package. We're adding this
> to geode-core.
>
> For a little more context - we are thinking about refactoring membership
> (and/or maybe some other pieces) into separate gradle modules - proposal
> forthcoming! However, as a first step we need to untangle those pieces of
> code from the rest of geode-core. Rather than creating some long lived
> branch we can incrementally untangle the code a piece at a time, on
> develop. Having a way to track progress and enforce the direction of
> dependencies on the way to a separate gradle module will help with that.
>
> -Dan
>
> On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett  wrote:
>
> > Are you adding this dependency to just the membership module? I am cool
> > with that.
> >
> > > On Jun 20, 2019, at 2:39 PM, Dan Smith  wrote:
> > >
> > > Hi all,
> > >
> > > Bill, Ernie, and I would like to add a new (apache licensed) test
> > > dependency to geode-core - https://github.com/TNG/ArchUnit. This is a
> > tool
> > > that lets you write tests that make assertions about the
> > interdependencies
> > > of your code - for example enforcing that package A does not depend on
> > > package B.
> > >
> > > Initially we intend to add some tests about what parts of the system
> the
> > > org.apache.geode.distributed.internal.membership package depends on,
> with
> > > an eye towards making that code more independently testable (proposal
> on
> > > that coming soon!).
> > >
> > > Does anyone have an issue with adding this test dependency?
> > >
> > > -Dan
> >
> >
>

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

[Jacob Barrett]

Gotcha! Sounds good.

> On Jun 20, 2019, at 4:35 PM, Dan Smith  wrote:
> 
> We don't have a membership gradle module, just a package. We're adding this
> to geode-core.
> 
> For a little more context - we are thinking about refactoring membership
> (and/or maybe some other pieces) into separate gradle modules - proposal
> forthcoming! However, as a first step we need to untangle those pieces of
> code from the rest of geode-core. Rather than creating some long lived
> branch we can incrementally untangle the code a piece at a time, on
> develop. Having a way to track progress and enforce the direction of
> dependencies on the way to a separate gradle module will help with that.
> 
> -Dan
> 
>> On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett  wrote:
>> 
>> Are you adding this dependency to just the membership module? I am cool
>> with that.
>> 
>>> On Jun 20, 2019, at 2:39 PM, Dan Smith  wrote:
>>> 
>>> Hi all,
>>> 
>>> Bill, Ernie, and I would like to add a new (apache licensed) test
>>> dependency to geode-core - https://github.com/TNG/ArchUnit. This is a
>> tool
>>> that lets you write tests that make assertions about the
>> interdependencies
>>> of your code - for example enforcing that package A does not depend on
>>> package B.
>>> 
>>> Initially we intend to add some tests about what parts of the system the
>>> org.apache.geode.distributed.internal.membership package depends on, with
>>> an eye towards making that code more independently testable (proposal on
>>> that coming soon!).
>>> 
>>> Does anyone have an issue with adding this test dependency?
>>> 
>>> -Dan
>> 
>>