Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Subject: Future of River
To: dev@river.apache.org
References: <077a640e8c46a426892bb5e06cc160fa@org.tizen.email>
From: Patricia Shanahan <pats@acm.org>
Message-ID: <0d9a1a8b-ad30-0b29-e919-291b59868adf@acm.org>
Date: Fri, 7 Oct 2016 00:08:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <077a640e8c46a426892bb5e06cc160fa@org.tizen.email>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Fri, 07 Oct 2016 07:08:27 -0000

This message is to change the subject line. These comments are far too 
important to be mistaken for being part of wrapping up the 3.0 release.

On 10/6/2016 10:57 PM, Peter wrote:
> To answer my own question, a list of items that require attention:
> 1. Modular build.
> 2. Improved IPv6 support
> 3. Update to TLS v1.2 and update constraints.
> 4. Investigate Maven codebase provisioning, do we need to use the Maven ClassWorlds ClassLoaders, what about proxy identity?
> 5. Fix security.
> 6. Update website.
> 7. Development guide for River devs.
> 8. Redundancy?
> 9. Update user docs, perhaps update Jan Newmarch's book?
>
> Cheers,
>
> Peter.
>
>
>
>
> Sent from my Samsung device.
>
>   Include original message
> ---- Original message ----
> From: Peter <jini@zeus.net.au>
> Sent: 07/10/2016 12:25:01 pm
> To: dev@river.apache.org
> Subject: Re: [VOTE] Release Apache River 3.0.0
>
> The question is of course where to next?
>
> As people are aware I've been working on addressing security issues and
> how to make River better and more secure.  I've been working on this
> outside the project because my attempts to discuss it caused heated
> arguments.  I figured that if I could demonstrate a working example that
> people could try out, it could allevieate any misunderstandings that may
> have developed due to language or culture differences.
>
> River's approach to security (a result of the Jini Davis project) is
> quite complex and contains a flaw borne out of two limitations around
> the time it was developed:
>
>    1. The assumption that the Java sandbox and java serialization was
>       secure (we know today this isn't the case).
>    2. Interfaces cannot be changed (no longer true with java 8), in this
>       case ServiceRegistrar was designed prior to the later added on
>       security features.
>
> What's wrong with River's approach?
>
> Answer:  It validates and authenticates after downloading code and
> deserializing untrusted data, using the proxy trust framework, by asking
> an already downloaded and deserialized service proxy for a bootstrap
> proxy, the client code then uses the boostrap proxy to determine if the
> service proxy can be trusted.  Too little too late.  Why not instead
> recieve a bootstrap proxy, deserialized using input validation, without
> code download, authenticate the remote endpoint, then ask the bootstrap
> proxy for the service proxy?
>
> The trouble with the existing approach today is an attacker has
> opportunity to take control of a computer using deserialization alone.
> For those who think a network firewall is sufficient protection and the
> flawed security design isn't an issue on local networks, even in air
> gapped networks, an attacker can leave a USB key in a car park
> containing malware that looks for network transmissions that contain
> java serialized data, hoping that someone will pick it up and plug it
> into their pc, the malware will send serial data containing a gadget
> attack to a listening network port that accepts java serial data and
> take over the infected computer.
>
> All network communications using standard java serialization must be
> both authenticated and encrypted, prior to reading in any data to ensure
> that the data is trusted.
>
> I think we can all accept that these vulnerabilities exist and googling
> java serialization gadget attacks should convince even the most doubtful
> sceptic.
>
> Relevant links:
> https://www.apache.org/dev/committers.html#apache-way
> http://www.apache.org/security/committers.html
>
> I would like the opportunity to explain more, and go through working
> examples of solutions before we start arguing about whether we should
> solve these problems.  Anyone reading the Apache Way will realise that
> security is a mandatory feature of Apache Software and therefore we
> should consider how we should fix existing security issues in River and
> while doing so, take the opportunity to make security simpler to
> implement.  Arguments should not be about the relevance of security
> issues, but rather the suitablility of solutions.
>
> Regards,
>
> Peter.
>
> On 6/10/2016 2:04 PM, Bryan Thompson wrote:
>>  Excellent.  A great step.
>>  Bryan
>>
>>  On Wednesday, October 5, 2016, Peter Firmstone<peter.firmstone@zeus.net.au>
>>  wrote:
>>
>>>  Results:
>>>
>>>  3 binding votes
>>>  1 non binding
>>>
>>>  None against.
>>>
>>>  The artifacts have been published, we need to wait 24 hours before
>>>  announcing.
>>>
>>>  Regards,
>>>
>>>  Peter.
>>>
>>>  Sent from my Samsung device.
>>>
>>>
>
>
>