river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Future of River
Date Sat, 08 Oct 2016 12:35:10 GMT
Thanks Patricia.

It would be nice if we could hear a little about what people want for 
River going forward.



On 7/10/2016 5:08 PM, Patricia Shanahan wrote:
> 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