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]
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:
With the above URL, the normal frmweb process is started with the following parameters:
Where ifip parameter is controllable by user input. The frmweb executable, however, accepts one more parameter:
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:
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
attacker could upload a remote shell and execute arbitrary code on the server.
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.
Proof-of-concept exploit (tested with Oracle Development Suite 10.1.2.0.2, installed on Oracle Linux 5u6):
After the first step, attacker could execute OS command
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]
To get the content of /etc/passwd on the remote server:
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.
URL-decoded version of the first blind JSP shell:
Base64-decoded version of the second JSP shell:
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.
May 15, 2014: vulnerability was reported to Oracle.
June 18, 2014: vulnerability was confirmed by Oracle
October 14, 2014: patch released