ICEfaces
  1. ICEfaces
  2. ICE-8771

SECURITY: Potential security improvements related to findings from Veracode security scan

    Details

    • Assignee Priority:
      P2
    • Salesforce Case Reference:

      Description

      The results of a security scan were sent in by a customer and they asked us to review and respond. The raw report is attached to the customer ticket. My summary of that report is as follows:


      The basic breakdown of the 19 issues is:
      11 x "Improper Output Neutralization for Logs"
      1 x "Leftover Debug Code"
      1 x "Improper Validation of Host-specific Certificate Data"
      3 x "Insufficient Entropy"
      1 x "External Control of File Name or Path"
      2 x "Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')"
      All of the issues were found in either:
      com.icesoft.icepush
      com.icesoft.faces
      So they are confined to ICEpush EE (perhaps the customer is using an EE version?) and compat packages. Either ACE is not used and so the security scan was not run against it or there were no detected issues.


      JIRAs

      Comparing the reported issues against any security related work we've done since release 3.0.1 doesn't really show any specific fixes related to the areas described in the report. The only directly security related JIRA I could find was:

      http://jira.icesoft.org/browse/ICE-7394

      But the work for that case doesn't look like it applies to any of the issues being captured by the Veracode scan.


      Issue Details

      This section is just a condensed version of the report showing the problem, description and where it occurs.

      "Improper Output Neutralization for Logs"
      This call to java.util.logging.Logger.info() could result in a log forging attack. Writing unsanitized user-supplied data into a log file allows an attacker to forge log entries or inject malicious content into log files.

      1 instance in com.icesoft.icepush.APNSNotificationProvider
          void send(java.lang.String, org.icepush.PushNotification)
      1 instance in com.icesoft.faces.component.effect.ApplyEffectRenderer
          void encodeBegin(javax.faces.context.FacesContext, javax.faces.component.UIComponent)
      3 instances in com.icesoft.icepush.C2dmNotificationProvider$GoogleServiceLogin
          void run()
      2 instances in com.icesoft.faces.webapp.CompatResourceServlet
         void service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
      1 instance in com.icesoft.faces.context.effects.CurrentStyle
          java.util.Map decode(javax.faces.context.FacesContext)
      1 instance in com.icesoft.faces.renderkit.dom_html_basic.FormRenderer
          void encodeBegin(javax.faces.context.FacesContext, javax.faces.component.UIComponent)
      2 instances in com.icesoft.faces.component.selectinputdate.SelectInputDateRenderer
          void decode(javax.faces.context.FacesContext, javax.faces.component.UIComponent)



      "Leftover Debug Code"
      The main() method may be leftover debug code that creates an unintended entry point in a web application. Although this is an acceptable practice during product development, classes that are part of a production J2EE application should not define a main() method. Whether this method can be remotely invoked depends on the configuration of the J2EE container and the application itself.

      com.icesoft.icepush.ProductInfo
          void main(java.lang.String [])


      "Improper Validation of Host-specific Certificate Data"
      In this call to !operator_newarray_initimp(), host-specific certificate data is not validated or is incorrectly validated. Failing to validate the certificate makes the SSL session susceptible to a man-in-the-middle attack. Verify that the certificate is valid, matches the requested site, and is signed by a trusted root authority. Generate an error and destroy the connection if any of these conditions are not met.

      com.icesoft.icepush.C2dmNotificationProvider
          void <clinit>(void)"


      "Insufficient Entropy"
      Standard random number generators do not provide a sufficient amount of entropy when used for security purposes. Attackers can brute force the output of pseudorandom number generators such as rand(). If this random number is used where security is a concern, such as generating a session key or session identifier, use a trusted cryptographic random number generator instead. These can be found on the Windows platform in the CryptoAPI or in an open source library such as OpenSSL. In Java, use the SecureRandom object to ensure sufficient entropy.

      com.icesoft.faces.context.effects.JavascriptContext
          java.lang.String randomComment(void)
      com.icesoft.faces.component.panelpositioned.PanelPositionedRenderer
          void encodeBegin(javax.faces.context.FacesContext, javax.faces.component.UIComponent)
      com.icesoft.faces.facelets.component.table.richdatagrid.RichDataGridBean
          void updateRandom()


      "External Control of File Name or Path"
      This call to java.lang.ClassLoader.getResourceAsStream() contains a path manipulation flaw. The argument to the function is a filename constructed using user-supplied input. If an attacker is allowed to specify all or part of the filename, it may be possible to gain unauthorized access to files on the server, including those outside the webroot, that would be normally be inaccessible to end users. The level of exposure depends on the effectiveness of input validation routines, if any. The first argument to getResourceAsStream() contains tainted data from the variable path. The tainted data originated from an earlier call to javax.servlet.http.HttpServletRequest.getPathInfo. Validate all user-supplied input to ensure that it conforms to the expected format, using centralized data validation routines when possible. When using black lists, be sure that the sanitizing routine performs a sufficient number of iterations to remove all instances of disallowed characters.

      com.icesoft.faces.webapp.CompatResourceServlet
          void service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
           
           
      "Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')"
      This call to java.lang.Class.forName() uses reflection in an unsafe manner. An attacker can specify the class name to be instantiated, which may create unexpected control flow paths through the application. Depending on how reflection is being used, the attack vector may allow the attacker to bypass security checks or otherwise cause the application to behave in an unexpected manner. Even if the object does not implement the specified interface and a ClassCastException is thrown, the constructor of the user-supplied class name will have already executed. The first argument to forName() contains tainted data from the variable type. The tainted data originated from earlier calls to javax.faces.context.ExternalContext.getRequestParameterMap, com.sun.faces.config.InitFacesContext$ServletContextAdapter.getRequestParameterMap, javax.faces.context.ExternalContextWrapper.getRequestParameterMap, and com.sun.faces.context.ExternalContextImpl.getRequestParameterMap. Validate the class name against a combination of white and black lists to ensure that only expected behavior is produced.

      2 instances of com.icesoft.faces.component.util.CustomComponentUtils
          java.lang.Class classForName(java.lang.String)

        Issue Links

          Activity

            People

            • Assignee:
              Deryk Sinotte
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: