river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Wed, 26 Feb 2014 12:09:55 GMT
Peter,

I think you dont remember the idea. It's been a long time.
It DOES prevent untrusted code from executing because a codebase annotation
is verified BEFORE it has a chance to load code.

Regards,
Michal
26 lut 2014 12:31 "Peter" <jini@zeus.net.au> napisał(a):

> ----- Original message -----
> > > This. I like this. How would this work, would it be an Entry, an
> > > attribute of the service (perhaps similar to the ServiceUI factory?).
> >
> > My PoC is attached to one of the issues in Jira (I'll try to find it
> > tomorrow once I have some more time). It was discussed some time ago on
> > this list mainly with Peter.
>
> In our previous discussion, the aim was to determine a way to ensure that
> no untrusted objects could be deserialised and thus prevent DOS attacks.
>
> Because ProxyTrustVerifier checks are performed after deserialisation,
> this wasn't a good solution for that specific problem.  That doesn't mean
> to say it wouldn't be useful for other purposes.
>
> The solution to avoid downloading untrusted objects, is to prevent
> deserialisation of untrusted classes, by checking the serialization byte
> stream and limiting deserialisation to a specific list of local classes
> until after trust can be established.
>
> I think this combined with Dennis' method of provisioning codebases and
> secure endpoints would be a very difficult to crack security layer.
>
> That doesn't mean that object based annotations cannot be used, making the
> annotation field a String doesn't mean you can't deserialise any Object, it
> just means that after an object other than String is deserialised, a
> ClassCastException will be thrown, by that time an attacker may have
> already created a ClassLoader, if deserialisation is performed in
> privileged context.
>
> Once we depreciate RMIClassLoader and replace it with RiverClassLoading,
> then we could allow annotations to be objects.  After all, codebase
> annotations are also part of the serialised stream, so we can secure them
> by limiting them to a known trusted subset of classes as stated above.
>
> Regards,
>
> Peter.
>
>
> > Basically the idea is to change codebase annotation from
> > java.lang.String which needs to be interpreted by the client to an
> > object implementing an interface.
> > This object can be verified in exactly the same way as normal proxies
> > are verified ( by a TrustVerifier - in particular the ProxyTrustVerifier
> > ). All that happens during deserialization.
> > It does not have anything to do with Entries since it is implemented at
> > the layer below that - hence is available for _all_ downoladed code (for
> > RemoteEventListeners as well :-) )
> >
> > Regards,
> > Michal
> >
> > --
> > Michał Kłeczek
> > XPro Quality Matters
> > http://www.xpro.biz
> >
>
>

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