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
smime.p7s
Description: S/MIME cryptographic signature
