Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Fri, 29 Jul 2016 21:46:20 +0000 (UTC)
From: "Hadoop QA (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.12993593.1469812393000.172837.1469828780525@Atlassian.JIRA>
In-Reply-To: <JIRA.12993593.1469812393000@Atlassian.JIRA>
References: <JIRA.12993593.1469812393000@Atlassian.JIRA> <JIRA.12993593.1469812393646@arcas>
Subject: [jira] [Commented] (AMBARI-17962) Coverity Scan Security
 Vulnerability - SQL injection
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 29 Jul 2016 21:46:22 -0000


    [ https://issues.apache.org/jira/browse/AMBARI-17962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400051#comment-15400051 ] 

Hadoop QA commented on AMBARI-17962:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12821084/AMBARI-17962_trunk_01.patch
  against trunk revision .

    {color:red}-1 patch{color}.  Top-level trunk compilation may be broken.

Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/8233//console

This message is automatically generated.

> Coverity Scan Security Vulnerability - SQL injection
> ----------------------------------------------------
>
>                 Key: AMBARI-17962
>                 URL: https://issues.apache.org/jira/browse/AMBARI-17962
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 1.2.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>            Priority: Critical
>              Labels: coverity, security
>             Fix For: 2.4.0
>
>         Attachments: AMBARI-17962_branch-2.4_01.patch, AMBARI-17962_trunk_01.patch
>
>
> The Ambari coverity scan found two "High impact security" issues, both SQL Injections.  They are both the same coding issue, but one is in OracleConnector.java, and one is in the analogous method in PostgresConnector.java.
> This is the key description:
> {quote}
>  CID 167755 (#1 of 1): SQL injection (SQLI)9. sql_taint: Insecure concatenation of a SQL statement. The value searchClause is tainted.
> Perform one of the following to guard against SQL injection attacks.
> * Parameterize the SQL statement using ? positional characters. Bind the tainted values to the ? positional parameters using one of the PreparedStatement.set* methods.
> * Validate user-supplied values against predefined constant values. Concatenate these constant values into the SQL statement.
> * Cast tainted values to safe types such as integers. Concatenate these type safe values into the statement.
> [More Information|https://scan3.coverity.com/doc/en/cov_checker_ref.html#id_sql_generic]
> {quote}
> This is the one in OracleConnector.java, lines 32 -55:
> {code}
> 32  @Override
>   8. taint_path_param: Parameter searchClause receives the tainted data.
> 33  protected PreparedStatement getQualifiedPS(Statements statement, String searchClause, Workflows.WorkflowDBEntry.WorkflowFields field, boolean sortAscending, int offset, int limit) throws IOException {
> 34    if (db == null)
> 35      throw new IOException("db not initialized");
> 36
> 37    String order = " ORDER BY " + field.toString() + " " + (sortAscending ? SORT_ASC : SORT_DESC);
> 38
> 39    String query = "select * \n" +
> 40        "  from ( select " +
> 41//        "/*+ FIRST_ROWS(n) */ \n" +
> 42        "  a.*, ROWNUM rnum \n" +
> 43        "      from ("
>   CID 167755 (#1 of 1): SQL injection (SQLI)9. sql_taint: Insecure concatenation of a SQL statement. The value searchClause is tainted.
>   Perform one of the following to guard against SQL injection attacks.
>     Parameterize the SQL statement using ? positional characters. Bind the tainted values to the ? positional parameters using one of the PreparedStatement.set* methods.
>     Validate user-supplied values against predefined constant values. Concatenate these constant values into the SQL statement.
>     Cast tainted values to safe types such as integers. Concatenate these type safe values into the statement.
> More Information
> 44        + statement.getStatementString() + searchClause + order +
> 45        ") a \n" +
> 46        "      where ROWNUM <= " + (offset + limit) + ") \n" +
> 47        "where rnum  >= " + offset;
> 48
> 49    try {
>   10. sql_sink: Passing the tainted value query to the SQL API java.sql.Connection.prepareStatement(java.lang.String) may allow an attacker to inject SQL.
> 50      return db.prepareStatement(query);
> 51    } catch (SQLException e) {
> 52      throw new IOException(e);
> 53    }
> 54
> 55  }
> {code}
> This is the one in PostgresConnector.java, lines 495-504:
> {code}
>  
>    8. taint_path_param: Parameter searchClause receives the tainted data.
> 495  protected PreparedStatement getQualifiedPS(Statements statement, String searchClause) throws IOException {
> 496    if (db == null)
> 497      throw new IOException("postgres db not initialized");
> 498    try {
> 499      // LOG.debug("preparing " + statement.getStatementString() + searchClause);
>    CID 167743 (#1 of 1): SQL injection (SQLI)9. sql_taint: Insecure concatenation of a SQL statement. The value searchClause is tainted. Passing the tainted command to the SQL API java.sql.Connection.prepareStatement(java.lang.String) may allow an attacker to inject SQL.
>    Perform one of the following to guard against SQL injection attacks.
>     Parameterize the SQL statement using ? positional characters. Bind the tainted values to the ? positional parameters using one of the PreparedStatement.set* methods.
>     Validate user-supplied values against predefined constant values. Concatenate these constant values into the SQL statement.
>     Cast tainted values to safe types such as integers. Concatenate these type safe values into the statement.
> More Information
> 500      return db.prepareStatement(statement.getStatementString() + searchClause);
> 501    } catch (SQLException e) {
> 502      throw new IOException(e);
> 503    }
> 504  }
> {code}
> *Solution*
> Remove code supporting an unsupported REST API call to obtain jobtracker information.  his entry point is handled by {{org.apache.ambari.eventdb.webservice.WorkflowJsonService}}.  By removing this class and cleaning up orphaned code, the SQL injection issue list above will be solved. 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)