river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Future of River
Date Fri, 07 Oct 2016 07:08:07 GMT
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.

View raw message