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. >>> >>> >> >> >
