On sandboxes, and why I ... don't care.

[Andrew van der Stock <vanderaj () greebo net>]

Hi there,

I must have missed a memo or something. I don't know about you, but  
I've reviewed many J2EE apps which had far greater things wrong than  
not running in a verified / trusted environment. I've never seen an  
attack which is realistic or usable for such attacks.

If I find (say) 100 things wrong, the business can afford the time  
and resources to fix 65 of these and the inclination to fix none. Any  
fix is a good fix from my point of view, but I need to be careful in  
what I strongly recommend to be fixed, and what I'll let go through  
to the keeper.

I'm sorry, but I can't recommend turning on the verifier and asking  
the devs to go through the painful effort of figuring out exactly  
what perms their code will require when there are actual exploitable  
issues (those 65 - 80 or so) which may cause actual financial loss.  
Ditto asking for "final" and other modifiers to be used. Turning on  
the verifier / forcing the assertion of required privs requires a  
complete re-test. For many larger apps, testing can cost millions of  
dollars. How much has been lost with this attack? Ever?

Remember, the mitigant to many risks may not be a technical control;  
it may be reactive (audit), legal (T&C's / contracts), or it may be  
process driven, such as settlement periods.

I'm interested - has *anyone* seen an attack (.NET or J2EE) which  
aims at the trust model of the underlying VM? Has it lost anyone any  
money / reputation / shareholder confidence? I'm happy to hear if  
there has been, but otherwise, I'd like to think we have more  
important things to educate devland on than worrying about a risk  
which doesn't really rate.

thanks,
Andrew

Attachment: smime.p7s
Description: