Justin Massey

Justin Massey

Penetration Tester

Contact Me

Debugging Jenkins + Checkmarx Maximum Upload Limit

Problem: After installing the Checkmark plugin through the “Manage Plugins” page in Jenkins, everything seems to scan and build successfully when run on projects with small source code and small artifacts. However, when the workspace, the collection of all assets from a specific build inside of Jenkins, exceeds 200MB, the build fails.

Started zipping the workspace
ERROR: Checkmarx Scan Failed: Reached maximum upload size limit of 200 MB
Finished: FAILURE
This can usually be fixed by analyzing the files inside of the workspace and excluding binary files or other files which are unnecessary for Checkmarx to scan. This can be configured inside of the “Include/Exclude wildcard patterns” setting under the Checkmarx configuration inside of the Jenkins build section. There are preset wildcards under this configuration. For example: .exe, .pdb, .gz files (and many more) are excluded from being compressed. However, after the tuning of these wildcard patterns, I was unable to decrease the zip file to a size below the upper boundary of 200MB.

Desirable Outcome: Allow the compression of all files within the workspace regardless of combined file size.

Issues: Checkmarx support made me aware the 200MB value was set because IIS would not permit the uploading of files larger than 200MB. Although IIS by default may not allow this, it is a configurable feature (see: http://ajaxuploader.com/large-file-upload-iis-asp-net.htm). IIS’s upward limit is 4294967295 bytes (2^32-1).

The next issue is locating the place in the Checkmarx plugin source code where the limit was configured. After cloning down the source code, I discovered a configuration setting inside of src/main/resources/com/checkmarx/jenkins/cxconfig.xml and a hard coded entry to assign the value if the configuration file was not accessible in src/main/java/com/checkmarx/jenkins/CxConfig.java. The hard coded value was set to 209715200. I modified this to be 2^32-1 and the plugin would compile successfully. After installing the modified plugin, Jenkins was unable to authenticate to the Checkmarx server and the logs were displaying a WebServiceException. I found a ticket which explained the error and Igor, the maintainer of the Checkmarx plugin, said that they develop in the Master branch. I was to revert to a previous tag (https://issues.jenkins-ci.org/browse/JENKINS-33607?focusedCommentId=268738&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-268738). The functionality to authenticate to the Checkmarx server was regained after switching to the Release_8.1.0-2 branch, modifying the values in the source code and compiling the plugin.

However, when zipping files, Jenkins would immediately throw the error: “error: java.lang.NumberFormatException: For input string: "4294967295".” This is likely due to the fact that Jenkins is doing some sort of type casting from string to int. The int limit in Java is 2147483647 (2^31-1).

Solution: After modifying the value to be 2^31-1, the application successfully compressed a file larger than 200MB.

Zipping complete with 34 files, total compressed size: 243 MB
Temporary file with zipped and base64 encoded sources was created at: /tmp/base64ZippedSource3303569387968177320.bin
Uploading sources to Checkmark Server
Temporary file deleted

Scan job submitted successfully

Source contains: 988 lines of code.
Scan job queued at position: 1
Scanning: Engine starts scan (Current stage progress: 0%, Total progress: 0%)
Scan Finished Successfully - RunID: 313377 ScanID:1020636
Requesting XML Scan Report Generation
XML Report generation is in progress
Scan report generated on Checkmark server
Scan report written to: /var/lib/jenkins/jobs/test2/builds/17/checkmarx/ScanReport.xml
Finished: SUCCESS
I forked the repo and committed the change and it can be viewed here: https://github.com/Th3R3p0/checkmarx-plugin/commit/9d4eaebe617694e9fac08cacba4ce4a3c66ffbab. I submitted a pull request here: https://github.com/jenkinsci/checkmarx-plugin/pull/3

Final Thoughts: The hardcoded value inside of the Checkmarx plugin should be a modifiable value inside of Jenkins. A short informational text window would be helpful to explain the dependencies on the web server limits on which Checkmarx runs on. In this case, the IIS server had to be modified. If an NGINX reverse proxy sat in front of the IIS server, that configuration would also likely need to be modified.

Comments and suggestions are welcomed here.