Just because no-one has told you, or you haven't seen it doesn't mean
it doesn't happen.
It's pretty concerning to me, as a java programmer, that the verifier
is off by default and hence any jar running can run free or the
contraints I've tried to enforce. Or that another j2ee app could
possibly be viewing the data I was processing in a shared-hosting
environment.
I hardly think it's something to disregard because you don't care
about it. It's probably not a discussion that belongs on webappsec
anyway.
And further, if your code _doesn't_ run properly with the verifier,
then what the hell are you doing? Something you shouldn't be, that's
for sure. If you want to modify private fields legitimately use
reflection, otherwise ....
-- Michael
On 3/30/06, Andrew van der Stock <vanderaj@greebo.net> wrote:
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
-------------------------------------------------------------------------
This List Sponsored by: SpiDynamics
ALERT: "How A Hacker Launches A Web Application Attack!"
Step-by-Step - SPI Dynamics White Paper
Learn how to defend against Web Application Attacks with real-world
examples of recent hacking methods such as: SQL Injection, Cross Site
Scripting and Parameter Manipulation
https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------
