Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A custom class loader can be used to exploit this vulnerability. Instantiating a class loader object requires special permissions that are made available by the security policy that is enforced by the SecurityManager. An unsigned applet cannot carry out this step by default. However, if an unsigned applet can execute a custom class loader's constructor, it can effectively bypass all the security checks (it has the requisite privileges as a direct consequence of the vulnerability). A custom class loader can be designed to extend the system classlLoaderclass loader, undermine security, and carry out prohibited actions such as reading or deleting files on the user's file system. Moreover, legitimate security checks in the constructor are meaningless because the code is granted all privileges. The following noncompliant code example illustrates the vulnerability.

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="5e11c66c58001273-4daad9b1-4c304fab-81f08e4c-697602efe13dd7053234c636"><ac:plain-text-body><![CDATA[

[[API 2006

AA. References#API 06]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="aa72cc4a1c5cc3d1-5e59f4e2-491e4089-aa60a488-5e20e49ea141d4881add9044"><ac:plain-text-body><![CDATA[

[[CVE 2011

AA. References#CVE 08]]

[CVE-2008-5353

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5353]

]]></ac:plain-text-body></ac:structured-macro>

...