2009년 01월 23일
[URL]TPTP 프로파일링 Part 1, TPTP 설치 및 메모리 누수 찾기
# by | 2009/01/23 12:47 | Tools | 트랙백 | 덧글(0)
# by | 2009/01/23 12:47 | Tools | 트랙백 | 덧글(0)
All applets and any applications invoked with a security manager must be granted explicit permission to access local system resources apart from read access to the directory and its subdirectories where the program is invoked. The JavaTM platform provides permissions to allow various levels of access to different types of local information. Because permissions let an applet or application override the default security policy, you should be very careful when you assign permissions to not create an opening for malicious code to attack your system. This appendix describes the available permissions and explains how each permission can create an opening for malicious attacks. One way to use this information is to help you limit what permissions a given applet or application might need to successfully execute. Another way to use this information is to educate yourself on the ways in which a particular permission can be exploited by malicious code. As a safeguard, never trust an unknown applet or application. Always check the code carefully against the information in this appendix to be sure you are not giving malicious code permission to cause serious problems on the local system. For example, the following policy file entry specifies a To run an application with the security manager and a policy file named Another way to determine which permission your program needs is to browse Appendix B: Methods and Permissions. This appendix tells you which Java 2 platform software methods are prevented from executing without the listed permission. The information in Appendix B is also useful for developers who want to write their own security manager to customize the verifications and approvals needed in a program. Here is a short example to show you how to translate the first couple of lines in a stack trace to a policy file entry. The first line tells you access is denied. This means this stack trace was generated because the program tried to access a system resource without the proper permission. The second line means you need a accessEventQueue: This target grants permission to access the AWT event queue. Granting this permission could allow malicious code to peek at and remove existing events from the system, or post bogus events that could cause the application or applet to perform malicious actions. listenToAllAWTEvents: This target grants permission to listen to all AWT events throughout the system. Granting this permission could allow malicious code to read and exploit confidential user input such as passwords. Each AWT event listener is called from within the context of that event queue's readDisplayPixels: This target grants permission to read pixels back from the display screen. Granting this permission could allow interfaces such as showWindowWithoutWarningBanner: This target grants permission to display a window without also displaying a banner warning that the window was created by an applet. Without this warning, an applet might pop up windows without the user knowing they belong to an applet. This could be a problem in environments where users make security-sensitive decisions based on whether the window belongs to an applet or an application. For example, disabling the banner warning might trick the end user into entering sensitive user name and password information. This policy file grants read, write, delete, and execute permission to all files. When granting file permissions, always think about the implications of granting read and especially write access to various files and directories. The requestPasswordAuthentication: This target grants permission to ask the authenticator registered with the system for a password. Granting this permission could mean malicious code might steal the password. specifyStreamHandler: This target grants permission to specify a stream handler when constructing a Uniform Resource Locator (URL). Granting this permission could mean malicious code might create a URL with resources to which it would not normally have access, or specify a stream handler that gets the actual bytes from somewhere to which it does have access. This means the malicious code could trick the system into creating a ProtectionDomain/CodeSource for a class even though the class really did not come from that location. The actions are specified in a list of comma-separated keywords, and have the following meanings: The naming convention for target information where a library, package, or class name is added follows the hierarchical property naming convention, and includes wild cards. An asterisk at the end of the target name, after a dot ( createClassLoader: This target grants permission to create a class loader. Granting this permission might allow a malicious application to instantiate its own class loader and load harmful classes into the system. Once loaded, the class loader could place these classes into any protection domain and give them full permissions for that domain. getClassLoader: This target grants permission to retrieve the class loader for the calling class. Granting this permission could enable malicious code to get the class loader for a particular class and load additional classes. setContextClassLoader: This target grants permission to set the context class loader used by a thread. System code and extensions use the context class loader to look up resources that might not exist in the system class loader. Granting this permission allows code to change which context class loader is used for a particular thread, including system threads. This can cause problems if the context class loader has malicious code. setSecurityManager: This target grants permission to set or replace the security manager. The security manager is a class that allows applications to implement a security policy. Granting this permission could enable malicious code to install a less restrictive manager, and thereby, bypass checks that would have been enforced by the original security manager. createSecurityManager: This target grants permission to create a new security manager. Granting this permission could give malicious code access to protected and sensitive methods that might disclose information about other classes or the execution stack. It could also allow the introduction of a weakened security manager. exitVM: This target grants permission to halt the Java VM. Granting this permission could allow malicious code to mount a denial-of-service attack by automatically forcing the VM to stop. setFactory: This target grants permission to set the socket factory used by the setIO: This target grants permission to change the value of the modifyThread: This target grants permission to modify threads by calls to the stopThread: This target grants permission to stop threads. Granting this permission allows code to stop any thread in the system provided the code already has permission to access that thread. Malicious code could corrupt the system by killing existing threads. modifyThreadGroup: This target grants permission to modify threads by calls to the getProtectionDomain This target grants permission to retrieve the readFileDescriptor: This target grants permission to read file descriptors. Granting this permission allows code to read the particular file associated with the file descriptor, which is dangerous if the file contains confidential data. writeFileDescriptor: This target grants permission to write file descriptors. Granting this permission allows code to write to the file associated with the descriptor, which is dangerous if the file descriptor points to a local file. loadLibrary.{library name}: This target grants permission to dynamically link the specified library. Granting this permission could be dangerous because the security architecture is not designed to and does not extend to native code loaded by way of the accessClassInPackage.{package name} This target grants permission to access the specified package by way of a class loader's defineClassInPackage.{package name}: This target grants permission to define classes in the specified package by way of a class loader's accessDeclaredMembers: This target grants permission to access the declared members of a class. Granting this permission allows code to query a class for its public, protected, default (package), and private fields and methods. Although the code would have access to the private and protected field and method names, it would not have access to the private and protected field data and would not be able to invoke any private methods. Nevertheless, malicious code may use this information to better aim an attack. Additionally, malicious code might invoke any public methods or access public fields in the class, which could be dangerous if the code would normally not be able to invoke those methods or access the fields because it cannot cast the object to the class or interface with those methods and fields. queuePrintJob: This target grants permission to initiate a print job request. Granting this permission could allow code to print sensitive information to a printer or maliciously waste paper.Overview
Permissions are granted to a program with a policy file. A policy file contains permissions for specific access. A permission consists of the permission name, a target, and in some cases, a comma-separated list of actions.java.io.FilePermissionpermission that grantsreadaccess (the action) to the${user.home}/text2.txttarget.grant { permission java.io.FilePermission "${user.home}/text2.txt", "read";};There is one policy file for Java platform installation (system) and an optional policy file for each user. The system policy file is in{java.home}/lib/security/java.policy, and the user policy file is in each user's home directory. The system and user policy files are combined. So for example,there could be a system policy file with very few permissions granted to all users on the system, and individual policy files granting additional permissions to certain users.polfilein the user's home directory, type: java -Djava.security.main -DJava.security.policy=polfile FileIO
To run an applet in appletviewer with a policy file namedpolfilein the user's home directory, type: appletviewer -J-Djava.security.policy=polfile fileIO.html
When running an applet in a browser, the browser looks for the user and system policy files to find the permissions the applet needs to access local system resources on behalf of the user who downloaded the applet.Knowing Which Permissions
When you run an applet or invoke an application with a security manager that needs permissions, you will get a stack trace if you did not provide a policy file with all the needed permissions. The stack trace contains the information you need to add the permission to the policy file that caused the stack trace. If the program needs additional permissions, you will keep getting stack traces until all the required permissions are added to the policy file. The only drawback to this approach is you have to try every possible code path in your application.java.net.SocketPermissionthat gives the program permission toconnectto andresolvethe host name for Internet Protocol (IP) address 129.144.176.176, port 1521.java.security.AccessControlException: access denied
(java.net.SocketPermission 129.144.176.176:1521 connect,resolve)
To turn this into a policy file entry, list the permission name, a target, and an action list as follows wherejava.net.SocketPermissionis the permission name,129.144.176.176:1521is the target, andconnect,resolveis the action list.grant { permission java.net.SocketPermission
"129.144.176.176:1521", "connect,resolve";};AllPermission
java.security.AllPermissionspecifies all permissions in the system for all possible targets and actions. This permission should be used only during testing because it grants permission to run with all security restrictions disabled as if there were no security manager.grant { permission java.security.AllPermission;};AWTPermission
java.awt.AWTPermissiongrants access to the following Abstract Window Toolkit (AWT) targets. The possible targets are listed by name with no action list.grant { permission java.awt.AWTPermissionaccessClipboard: This target grants permission to post information to and retrieve information from the AWT clipboard. Granting this permission could allow malicious code to share potentially sensitive or confidential information.
"accessClipboard";
permission java.awt.AWTPermission
"accessEventQueue";
permission java.awt.AWTPermission
"showWindowWithoutWarningBanner";};EventDispatchThread, so if theaccessEventQueuepermission is also enabled, malicious code could modify the contents of AWT event queues throughout the system, which can cause the application or applet to perform unintended and malicious actions.java.awt.Compositethat allow arbitrary code to examine pixels on the display to include malicious code that snoops on user activities.FilePermission
java.io.FilePermissiongrants access to a file or directory. The targets consist of the target pathname and a comma-separated list of actions.grant { permission java.io.FilePermissionThis policy file grants read and write permission to
"<<ALL FILES>>", "read, write, delete, execute";};text.txtin the user's home directory.grant { permission java.io.FilePermissionYou can use the following wild cards to specify the target pathname.
"${user.home}/text.txt", "read, write";};
The actions are specified in a list of comma-separated keywords and have the following meanings:/*, where/*is the file separator character indicates a directory and all the files contained in that directory./-indicates a directory, and recursively, all files and subdirectories contained in that directory.*) indicates all files in the current directory.-) indicates all files in the current directory, and recursively, all files and subdirectories contained in the current directory.<<ALL FILES>>permission with write action is especially dangerous because it grants permission to write to the entire file system. This means the system binary can be replaced, which includes the Java1 Virtual Machine (VM) runtime environment.NetPermission
java.net.NetPermissiongrants access to various network targets. The possible targets are listed by name with no action list.grant { permission java.net.NetPermissionsetDefaultAuthenticator: This target grants permission to set the way authentication information is retrieved when a proxy or HTTP server asks for authentication. Granting this permission could mean malicious code can set an authenticator that monitors and steals user authentication input as it retrieves the input from the user.
"setDefaultAuthenticator";
permission java.net.NetPermission "requestPasswordAuthentication";};PropertyPermission
java.util.PropertyPermissiongrants access to system properties. Thejava.util.Propertiesclass represents persistent settings such as the location of the installation directory, the user name, or the user's home directory.grant { The target list contains the name of the property; for example,
permission java.util.PropertyPermission
"java.home", "read";
permission java.util.PropertyPermission
"os.name", "write";
permission java.util.PropertyPermission
"user.name", "read, write";};java.homeoros.name. The naming convention for the properties follows the hierarchical property naming convention, and includes wild cards. An asterisk at the end of the property name, after a dot (.), or alone signifies a wild card match. For example,java.*or*are valid, but*javaora*bare invalid.
Granting property permissions can leave your system open to intrusion. For example, granting permission to access thejava.homeproperty makes the installation directory vulnerable to attack, and granting permission to access theuser.nameanduser.homeproperties might reveal the user's account name and home directory to code that might misuse the informaiton.ReflectPermission
java.lang.reflect.ReflectPermissiongrants permission for various reflective operations. The possible targets are listed by name with no action list.grant { permission java.lang.reflect.ReflectPermissionsuppressAccessChecks: This target grants permission to access fields and invoke methods in a class. This includes public, protected, and private fields and methods. Granting this permission could reveal confidential information and make normally unavailable methods accessible to malicious code.
"suppressAccessChecks";};RuntimePermission
java.lang.RuntimePermissiongrants access to various runtime targets such as the class loader, Java VM, and thread. The possible targets are listed by name with no action list.grant { permission java.lang.RuntimePermission
"createClassLoader"; permission java.lang.RuntimePermission
"getClassLoader"; permission java.lang.RuntimePermission
"exitVM"; permission java.lang.RuntimePermission
"setFactory"; permission java.lang.RuntimePermission "setIO";
permission java.lang.RuntimePermission
"modifyThread"; permission java.lang.RuntimePermission
"modifyThreadGroup"; permission java.lang.RuntimePermission
"getProtectionDomain"; permission java.lang.RuntimePermission
"setProtectionDomain"; permission java.lang.RuntimePermission
"readFileDescriptor"; permission java.lang.RuntimePermission
"writeFileDescriptor"; permission java.lang.RuntimePermission
"loadLibrary.<library name>"; permission java.lang.RuntimePermission
"accessClassInPackage.<package name>"; permission java.lang.RuntimePermission
"defineClassInPackage.<package name>"; permission java.lang.RuntimePermission
"accessDeclaredMembers.<class name>"; permission java.lang.RuntimePermission
"queuePrintJob";};.), or alone signifies a wild card match. For example,loadLibrary.*or*are valid, but*loadLibraryora*bare not.ServerSocketorSocketclass, or the stream handler factory used by theURLclass. Granting this permission allows code to set the actual implementation for the socket, server socket, stream handler, or Remote Method Invocation (RMI) socket factory. An attacker might set a faulty implementation that mangles the data stream.System.out,System.in, andSystem.errstandard system streams. Granting this permission could allow an attacker to changeSystem.into steal user input, or setSystem.errto anulloutput stream, which would hide any error messages sent toSystem.err.stop,suspend,resume,setPriority, andsetNamemethods in theThreadclass. Granting this permission could allow an attacker to start or suspend any thread in the system.destroy,resume,setDaemon,setmaxPriority,stop, andsuspendmethods of theThreadGroupclass. Granting this permission could allow an attacker to create thread groups and set their run priority.ProtectionDomaininstance for a class. Granting this permission allows code to obtain policy information for that code source. While obtaining policy information does not compromise the security of the system, it does give attackers additional information, such as local file names for example, to better aim an attack.java.lang.System.loadLibrarymethod.loadClassmethod when that class loader calls theSecurityManager.checkPackageAcesssmethod. Granting this permission gives code access to classes in packages to which it normally does not have access. Malicious code may use these classes to help in its attempt to compromise security in the system.defineClassmethod when that class loader calls theSecurityManager.checkPackageDefinitionmethod. Granting this permission allows code to define a class in a particular package, which can be dangerous because malicious code with this permission might define rogue classes in trusted packages likejava.securityorjava.lang, for example.
# by | 2009/01/22 11:06 | Java[J2SE 5, J2SE 6] | 트랙백 | 덧글(0)
◀ 이전 페이지 다음 페이지 ▶