river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: [VOTE] Release Apache River 3.0.0
Date Fri, 07 Oct 2016 05:57:48 GMT
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. 
>> 
>> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message