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]
Message-ID: <20061221193548.32507.qmail@securityfocus.com>
Date: 21 Dec 2006 19:35:48 -0000
From: jim@...ico.net
To: bugtraq@...urityfocus.com
Subject: Re: Enforcing Java Security Manager in Restricted Windows
 Environments?

You should not deploy java.exe in a shared environments where multiple trusted users use the same JVM. There are simply to many JVM level vulnerabilities where one user will be able to use the very recent series of JVM level bugs that can inspect the running code of another user, not to mention the problems you mentioned where a user can run Java shells, network sniffers, and other nasties.

You only want to do this in the J2EE world where you are protected behind many layers of protections between the user and the JVM.

But what you are suggesting is an environment where many users can directly share the same JVM, and even with your security policy restrictions, like you said, I can do some simple OS parameter tampering to get around that.

Answer: do not do it. Shared JVM's only belong in the Servlet/J2EE work - and even then, JVM level exploits still get exposed from container endpoints, like we see in JBOSS  often.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ