river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: JDK 7 Enhancements just bit me again
Date Sat, 04 May 2013 20:08:39 GMT
Ok fair comment.

On 4/05/2013 3:54 PM, Dan Creswell wrote:
> 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.reedy@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
>> 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.

View raw message