Fortify分析翻译8

上一篇 / 下一篇  2008-09-02 20:01:18 / 个人分类:Fortify

          Fortify分析翻译8

                      http://user.qzone.qq.com/281696143/blog/1219905860 Ronger

22.Process Control(Data Flow):
22.1.源文件:AgentServlet.java.
代码:obj = this.getClass().getClassLoader().loadClass(servletName).newInstance();
22.2.原文:Loading libraries from an untrusted source or in an untrusted environment
can cause an application to execute malicious commands on behalf of an attacker.
翻译:从一个不值得信任的库或者环境加载库将使得应用程序去执行一个恶意的攻击命令。
理解:在次不值得信任的库指的就是参数servletName。
22.3.EXPLANATION 解释
Process control vulnerabilities take two forms:
过程控制弱点可以归纳为两种模式:
- An attacker can change the name of the library that the program loads:
the attacker explicitly controls what the name of the library is.
一个攻击者可以改变程序加载的库的名字:
攻击者可以显式的控制库的名字是什么。
- An attacker can change the environment in which the library loads:
the attacker implicitly controls what the library name means.
一个攻击者可以改变库加载的环境:
攻击者可以隐式的控制库名字的用意。
In this case we are primarily concerned with the first scenario,
the possibility that an attacker may be able to control the name of the library that is loaded. Process control vulnerabilities of this type occur when:
在这种情况下,我们首先关注最早的设定,
可能是这样,攻击者能够控制加载的库的名字。
22.3.1. Data enters the application from an untrusted source.
In this case the data enters at getInitParameter()
in web/common/monitor/AgentServlet.java at line 143.
数据从一个不可信任的源进入应用程序。
在这种情况下,在AgentServlet.java的143行数据通过getInitParameter()进入。
22.3.2. The data is used as or as part of a string representing a library
that is loaded by the application.
In this case the library is loaded by loadClass()
in web/common/monitor/AgentServlet.java at line 147.
数据作为一个字符串或者字符串的一部分,这个字符串是用来描述通过应用程序导入的库的。
在这种请款下,库是通过loadClass()来加载,在AgentServlet.java的147行。
22.3.3. By executing code from the library,
the application gives the attacker a privilege or capability
that the attacker would not otherwise have.
通过执行从库中的代码,
应用程序给攻击者一个另外具有的特权或者能力。
Example 1: The following code from a privileged system utility
uses the system property APPHOME to determine the directory in
which it is installed and then loads a native library based on a relative path
from the specified directory.
例子1:下面的代码,使用了系统特性,使用系统属性APPHOME决定
安装的路径,并且基于这个路径的一个相对路径而加载一个临时的库。
...
String home = System.getProperty("APPHOME");
String lib = home + LIBNAME;
java.lang.Runtime.getRuntime().load(lib);
...
This code allows an attacker to load a library
and potentially execute arbitrary code with the elevated privilege of the application
by modifying the system property APPHOME to point
to a different path containing a malicious version of LIBNAME.
Because the program does not validate the value read from the environment,
if an attacker can control the value of the system property APPHOME,
then they can fool the application into running malicious code and take control of the system.
这段代码允许攻击者加载一个库,并且通过修改系统属性APPHOME指向一个不同的
包含恶意版本的LIBNAME,潜在的执行任意的代码。
因为程序没有验证从环境中读入的值,
如果攻击者可以控制系统属性APPHOME的值,
那么他们可以使应用程序执行恶意的代码并且控制系统。
Example 2: The following code uses System.loadLibrary() to load code
from a native library named library.dll,
which is normally found in a standard system directory.
例子2:下面的代码使用System.loadLibrary(),从一个命名为library.dll的临时库
中加载代码,library.dll通常可以在标准系统目录中可以找到。
...
System.loadLibrary("library.dll");
...
The problem here is that System.loadLibrary() accepts a library name,
not a path, for the library to be loaded.
From the Java 1.4.2 API documentation this function behaves as follows [1]:
这儿的程序是这样的,System.loadLibrary()接受一个库的名字,
不是一个路径,通过名字这个库被加载。
从Java1.4.2的API文档中,这个函数行为和下面的[1]一样。
A file containing native code is loaded from the local file system from a place
where library files are conventionally obtained.
The details of this process are implementation-dependent.
The mapping from a library name to a specific filename is done in a system-specific manner.
一个包含本地代码的文件是从本地文件系统加载的,这个本地文件系统是从库文件被包含的地方加载的。
这个过程的细节是由实现决定的。
从一个库名字到一个特定文件名的映射是由系统的样式决定的。
If an attacker is able to place a malicious copy of library.dll higher
in the search order than file the application intends to load,
then the application will load the malicious copy instead of the intended file.
Because of the nature of the application, it runs with elevated privileges,
which means the contents of the attacker's library.dll will now be run with elevated privileges,
possibly giving them complete control of the system.
如果攻击者能够可以对library.dll进行一个恶意的拷贝,
这个拷贝比应用程序加载的文件有更高的搜索顺序,
那么应用程序将加载这个恶意的拷贝代替已经确定的文件。
因为应用程序的本性,它将执行优先级更高的,
这个意味着攻击者的library.dll的内容将拥有更高优先级而被运行,
有可能让他们完全的控制系统。
22.4.RECOMMENDATIONS 建议
Do not allow users to control libraries loaded by the program.
In cases where user input must affect the choice of the library to load,
the application typically expects a particular input to take on only a very small set of values.
Rather than relying on the input to be safe and non-malicious,
the application should use the input only
to make a selection from a predetermined set of safe libraries.
If the input appears to be malicious,
the library to be loaded should either default to some safe selection from this set
or the program should gracefully decline to continue operation.
不要允许用户去控制程序加载的库。
在某种情况下,用户输入可以影响要加载的库的选择,
应用程序期望特别的输入可以进来,这些合法的值仅仅有一个很小的范围。
比依赖于输入更加安全和不会有恶意数据的是,
应用程序可以使用选择输入,从预先定义的安全库中选择。
如果输入显示为恶意的,
加载的库可以使用安全选择的库中的默认库,
或者程序可以拒绝继续执行。
An attacker can indirectly control the libraries
loaded by a program by modifying the environment.
The environment should not be trusted
and precautions should be taken to prevent an attacker
from using some manipulation of the environment to perform an attack.
Whenever possible,library names should be controlled by the application
and loaded using an absolute path passed to System.load().
System.loadLibrary() should be avoided because its behavīor is implementation dependent.
In cases where the path is not known at compile time,
an absolute path should be constructed from trusted values during execution.
Library names and paths read from the environment
should be sanity-checked against a set of invariants that define valid values.
攻击者可以通过修改环境,间接的控制程序加载的库。
环境是不可以信任的,并且要预防攻击者,使用对环境的处理来实施攻击。
当可能的时候,库名字应该被应用程序控制,并且使用一个绝对路径加载给System.load().
System.loadLibrary()最好避免使用,因为它的行为是依赖实现的。
在一些情况下,路径在编译时是不直到的,
在运行时一个绝对的路径可以从一个安全值构造。
库名字和路径从环境中读入,应该理智检查一系列定义好有效值的变量。
Other checks can sometimes be performed to detect
if the environment may have been tampered with. For example,
if a configuration file is world-writable, the program might refuse to run.
In cases where information about the library to be loaded is known in advance,
the program may perform checks to verify the identity of the file.
If a library should always be owned by a particular user
or have a particular set of access permissions assigned to it,
these properties can be verified programmatically before it is loaded.
其它的检查有时候也可以实施探测到,环境信息被篡改的时候。例如,
如果一个配置文件是可以被随便改写的,程序将拒绝执行。
在这种情况中,加载的库的信息是被预先知道的,
程序将实施检查去合适文件的合法性。
如果一个库总是被一个特殊的用户所拥有,或者有一个分配给它的特殊的存取许可,
这些属性在它被加载之前,可以被程序检测到。
In the end it may be impossible for a program to fully protect itself
from an imaginative attacker bent on controlling the libraries it loads.
You should strive to identify
and protect against every conceivable manipulation of input values and the environment.
The goal should be to shutdown as many attack vectors as possible.
最后,对于一个程序来说,不可能完全的保护它,被一个想象的攻击者基于控制加载的库方面的攻击。
你可以努力去核实,并且检查输入数据和环境的每一个可能的处理。
22.5.REFERENCES 引用
[1] Java 1.4.2 API Documentation, Sun Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/index.html
23.Password management(Data Flow):
23.1.源文件:WLIContextHolder.java
代码:env.put(Context.SECURITY_CREDENTIALS, passwd);
23.2.原文:Storing a password in plaintext may result in a system compromise.
翻译:基于折衷考虑用一个清晰的文本保存密码。
理解:也是从项目的安全性(密码管理)方面来考虑,在次Fortify将次风险归纳为warning级别。
23.3.EXPLANATION 解释
Password management issues occur
when a password is stored in plaintext in an application's properties or configuration file.
密码管理情况出现在,当一个密码以明码保存在一个程序的属性或者配置文件中。
In this case, the password is read into the program at executeQuery()
in wf/common/WLIContextHolder.java at line 102 and used to access a resource at put()
in wf/common/WLIContextHolder.java at line 206.
在这种情况下,密码在WLIContextHolder.java的102行的executeQuery()被读入程序,
并且在WLIContextHolder.java的206行使用put()方法进行存取。
Example: The following code reads a password from a properties file
and uses the password to connect to a database.
例如:下面的代码使用一个属性文件读取密码,并且使用密码连接数据库
...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, password);
...
This code will run successfully,
but anyone who has access to config.properties can read the value of password.
If a devious employee has access to this information,
they can use it to break into the system.
这个代码将运行的很成功,
但是已经存取数据到config.properties的一些人可以读到密码的值。
如果一个雇员获得这些信息,他们可以使用它中断系统。
23.4.RECOMMENDATIONS 建议
A password should never be stored in plaintext. Instead,
the password should be entered by an administrator when the system starts.
If that approach is impractical,
a less secure but often adequate solution is to obfuscate the password
and scatter the de-obfuscation material around the system so that an attacker
has to obtain and correctly combine multiple system resources to decipher the password.
密码不能使用明码来存储。可以这样来操作,
当系统启动的时候,密码可以通过管理员输入。
如果这个方法不可行,
一个安全级别低点但是经常采用的解决方案是使密码模糊,
并且分散令人迷惑的信息围绕系统,于是攻击者要去包含和正确的结合系统的多个资源,
去译解密码。
Some third party products claim the ability to manage passwords in a more secure way.
For example, WebSphere Application Server 4.x uses a simple XOR encryption algorithm for obfuscating values,
but be skeptical about such facilities.
WebSphere and other application servers offer outdated and relatively weak encryption mechanisms
that are insufficient for security-sensitive environments.
For a secure solution,
the only viable option today appears to be a proprietary mechanism that you create.
一些第三方的产品以一些更加安全的方法,强化了管理密码的能力。
例如,WebSphere应用服务器4.x使用一个简单的XOR编码法则,进行模糊数据,
但是让人怀疑它的简易性。
WebSphere和其它的应用服务器提供了过时的和相对的虚弱的编码机制,
对一个安全敏感的环境来说,是不足的。
对一个安全的解决方案来说,
今天仅仅可行的选择是,显示你创建的私人拥有的密码的机制。
23.5.TIPS 提示
23.5.1. Fortify identifies password management issues by looking for functions
that are known to take passwords as arguments.
If a password is read in from outside the program
and does not pass through an identified de-obfuscation routine
before being used, then Fortify flags a password management issue.
Fortify通过扫描函数来确定密码管理事件,这个函数将密码当成参数。
如果一个密码从程序的外部读入,并且在被使用前,没有经过一个确定的模糊处理,
那么Fortify将标示为一个密码管理器事件。
23.5.2.To audit a password management issue,
trace through the program from the point at
which the password enters the system to the point at which it is used.
Look for code that performs de-obfuscation. If no such code is present,
then this issue has not been mitigated.
If the password passes through a de-obfuscation function,
verify that the algorithm used to protect the password is sufficiently robust.
审计一个密码管理器事件,从密码进入系统的这一点,开始追踪程序。
寻找实现了模糊处理的代码。如果没有这样的代码存在,
那么这些事件就没有被减轻。
如果密码通过一个模糊函数处理,
验证表明,这个用来保护密码的规则不够强壮。
23.5.3.Once you are convinced that the password is adequately protected,
write a custom pass-through rule for the de-obfuscation routine
that indicates that the password is protected with obfuscation.
If you include this rule in future analyses of the application,
passwords that pass through the identified de-obfuscation routine
will no longer trigger password management vulnerabilities.
一旦你确信,密码被充分的保护好了,
为密码模糊写一个用户通过规则,表明密码被模糊规则保护。
在未来对应用程序的分析中,如果你包含这个规则,
通过模糊规则确定的密码将不会触发密码管理器漏洞。


TAG: Fortify

 

评分:0

我来说两句

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 25666
  • 日志数: 25
  • 建立时间: 2008-08-27
  • 更新时间: 2008-09-02

RSS订阅

Open Toolbar