full-disclosure - Fwd: On sandboxes, and why I ... don't care.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu Mar 30 11:34:05 2006
From: michaelslists at gmail.com (michaelslists@...il.com)
Subject: Fwd: On sandboxes, and why I ... don't care.

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@...ebo.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