How about logging a JIRA ticket with the conversation and tagging it for say 2.4.0?
On 4 May 2013 02:49, Dennis Reedy <dennis.re...@gmail.com> wrote: > A suggestion. I think this is a very interesting thread, but I really want > to suggest that we stop. There have been so many changes put into 2.3.0 > that need to be reviewed, documented and released. Lets make a concerted > effort to get that done before we make more changes. > > Regards > > Dennis > > On May 2, 2013, at 1048AM, Peter Firmstone wrote: > > > > > > > On 3/05/2013 12:22 AM, Michal Kleczek wrote: > >> So the problems to solve are: > >> 1. Possible buffer overflow and DoS type of attacks - since we do not > authenticate the stream before deserialization of the first object an > attacker can possibly inject huge objects (of classes available locally) in > the stream (such as LinkedList of arbitrary size). > >> 2. Leverage of vulnerabilities in classes available locally during > object deserialization. > >> > >> Limiting the list of classes that can be instantiated before doing > codebase verification is a good idea that could possibly solve both issues. > That would be basically providing a small Trusted Computing Base for > security checking of downloaded code. > >> But that actually means that codebase annotations _should_ be objects > that implement their deserialization in a secure manner so that attacks > from point 1. are not possible. As of today we use java.lang.String which > does not put any constraints on its size. > > > > Objects themselves have no way of limiting the size of the stream > transferred, unless they only read a limited number of bytes and avoid > calling readObject() on the stream, but that's very restrictive and this > would place an unnecessary implementation burden on our trusted computing > base, which would have to be careful not to download excessive bytes too. > > > > We need to limit the bytes read from the stream until trust is verified, > we could do that by wrapping the InputStream passed to the > MarshalInputStream constructor and counting the bytes read until we reach > our limit, resulting in an IOException and closing the stream, otherwise > the proxy is verified and we set a boolean value to stop counting prior to > reaching the limit. > > > > So we are very close to the solution, but I don't feel that ah-ha moment > yet. I'm off to bed now to sleep on it. > > > > Cheers, > > > > Peter. > > > >> > >> To provide backward compatibility we could fall back to old > implementation in case the class is not part of TCB. We would only allow it > if the stream is authenticated beforehand. > >> > >> Michal > >> > >> On 2013-05-02 15:35, Peter Firmstone wrote: > >>> On 2/05/2013 9:32 PM, Michal Kleczek wrote: > >>>>> > >>>>> An attacker can use a serialization attack, without requiring jini, > to create a ClassLoader and start downloading classes out of band. > >>>> > >>>> Given you never execute untrusted code: how? > >>>> > >>> > >>> I'm glad you asked me this question, because I just stumbled over a > partial solution: > >>> > >>> http://www.ibm.com/developerworks/library/se-lookahead/index.html > >>> > >>> Ironically I went looking for an example on the web for you, but this > article instead, completely unexpected, this article is very good because > it describes the issues with serialization well. The article was only > written in January this year. > >>> > >>> Just possibly we could restrict the classes that MarshaledInputStream > can instantiate to only those required to perform proxy verification. > >>> > >>> Could we limit both the bytes read from the stream and the classes > (required for connection and proxy trust) deserialized from the stream > until proxy verification has been performed? > >>> > >>> The challenge is, how can we do this and retain backward compatibility > in marshalled object streams? > >>> > >>> If there's an answer to those questions, it's the security grail for > Jini the Sun team was looking for. > >>> > >>> Cheers, > >>> > >>> Peter. > >>> > >>> > >> > >> > > > >
