On 2013-05-01 23:21, Peter wrote:
The annotation must be deserialized, serialization itself is insecure, we need
to authenticate using a secure connection, prior to deserializing that
annotation.
In my scheme you _do_ authenticate before deserializing the annotation.
By means of ProxyTrustVerifier that verified the annotation of annotation.
To deserialize an object we need to have code already in memory. The
whole point is to make sure this code is trusted prior to execution. It
can be:
1. local (trusted by definition)
2. downloaded from a trusted source (eg. an SSL connection to a trusted
Registrar and http server)
3. downloaded from untrusted source and verified prior to execution
Actually the whole idea of code signing is that you can download code
from an untrusted source and still be able to verify it.
In Jini we already have something equivalent but we verify objects
(code+data). ProxyTrustVerifier makes sure a trusted party (possibly
even a trusted third party) can verify _any_ object (in particular a
service proxy). Once you represent downloaded code as an object you can
use existing mechanisms to verify code. That way it does not matter
where the object (be it a service proxy or a codebase annotation) comes
from. It could have been sent as an email attachment - how it is
downloaded is orthogonal to the fact that we never execute untrusted code.
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?
All the attacker needs is privileged context (how many people grant
AllPermission to their own code), then the attack works.
It can be avoided by using the principal of least privilege, provided there are
no vulnerable jvm classes, but I don't know anyone who actually practises least
privilege principles.
Peter.
--
Michał Kłeczek
XPro Quality Matters
http://www.xpro.biz
