ZAP Exit Codes on Docker

[Justin Giannone]

Hey Guys,

I'm getting a weird exit code when running a long scan in Docker and telling ZAP to Compact Database on exit.  I am getting exit code -9 which, according to Python's POpen documentation, indicates that the process was terminated by a SIGKILL signal.

Here is my ZAP Shutdown function :

def shutdownZap(zapClient, zapProc, shutdownTimeoutSec=600):

    writeConsole('Shutting ZAP down...')

    zapClient.core.shutdown()

    

    if not zapProc:

        writeConsole('ZAP Process not provided... Unable to confirm ZAP Shutdown success...')

        return

    

    writeConsole('Waiting for ZAP to shutdown...')

    shutdownSuccessful = False

    try:

        exitCode = zapProc.wait(shutdownTimeoutSec)

        writeConsole(f'ZAP Process exited with code : {exitCode} !')

        shutdownSuccessful = true

    except TimeoutExpired:

        shutdownSuccessful = False

        pass

    

    if not shutdownSuccessful:

        raise IOError(errno.EIO, f'Failed to shutdown ZAP after {shutdownTimeoutSec} seconds')

Any insight into what causes that exit code, or how to respond to it?  When I get this exit code the archived ZAP Session Database doesn't seem to be fully compacted.

[Simon Bennetts]

Are there any errors in the zap.log file?

https://www.zaproxy.org/faq/somethings-not-working-what-should-i-do/

You could try running the same scan via the desktop and then seeing what happens when you shut down ZAP and compact the db.

[Justin Giannone]

Hey Simon,

There are no errors in the zap.log file that gets uploaded to permanent storage... but it also doesn't appear to have the expected ZAP Shutdown log lines either.  I'm re-running the scan again now and going to try to SSH into the container once the scan is complete to verify the zap.log file on the container itself.  I've attached the zap.log file that was uploaded to permanent storage from the last completed scan (from this past Fri).

When I try running these scans locally via my desktop or even a local container these issues don't seem to come up... only when I run them in ECS...

Justin Giannone, CISSP | Senior Security Architect | Medidata Solutions

350 Hudson Street, 9th Floor, New York, NY 10014

jgia...@mdsol.com | direct: +1 646 939 8138

 

Follow Us: Twitter | LinkedIn | Geeks Talk Clinical Blog

 

The information in this transmittal and any attachments are confidential and intended only for the recipient(s) listed above.

You are hereby notified that any unauthorized distribution or copying of this transmittal or its attachments is prohibited.

If you have received this transmittal in error, please notify the sender.

--
You received this message because you are subscribed to a topic in the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zaproxy-users/JS6qa8S-5sE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zaproxy-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/716060b9-b8f5-4dae-bf64-f6674c22e92fn%40googlegroups.com.

[Justin Giannone]

Just to update everyone.  I finally figured out the issue I was running into... the ZAP Java Process was exceeding the memory limitations for the ECS Container.  As a result, the kernel was killing the Java Process using a SIGKILL signal (signal 9) and when the kernel does that it automatically sets the process's exit code to -9.

I maxed out the memory limit and re-ran the scan entirely successfully... although the instance used ~15.5GB of memory at the max.  I assume that is from the HSQLDB being held in-memory and having spidered ~1200 urls and had a whole lot of scan rules enabled at Medium strength.  The memory usage seemed to climb pretty consistently with message throughput.

Glad we figured out the issue and we've started to do some work around reducing the number of pages to scan (leveraging ZAP's Structure functionality... and maybe Site Map Modifiers from the weekly builds) and tuning the scan rules for applicability.

[Simon Bennetts]

Thanks for letting us know!

Is there any extra information we could have logged which would have helped you work this out more easily?

Cheers,

Simon

[Justin Giannone]

To be honest, I don't think so.  SIGKILL signals aren't (from my experience) interceptable signals like SIGTERM or SIGINT... so from what I understand there is no real opportunity to log anything... the target process's only option is to terminate immediately.  The exit code was set correctly to the negative value of the Signal which caused it to terminate (in this case SIGKILL is signal 9, so the exit code was -9) and is the appropriate indicator for what happened.

Justin Giannone, CISSP | Senior Security Architect | Medidata Solutions

350 Hudson Street, 9th Floor, New York, NY 10014

jgia...@mdsol.com | direct: +1 646 939 8138

 

Follow Us: Twitter | LinkedIn | Geeks Talk Clinical Blog

 

The information in this transmittal and any attachments are confidential and intended only for the recipient(s) listed above.

You are hereby notified that any unauthorized distribution or copying of this transmittal or its attachments is prohibited.

If you have received this transmittal in error, please notify the sender.

To view this discussion on the web visit https://groups.google.com/d/msgid/zaproxy-users/fe38b9ee-0a7c-4d9c-890a-e38fb4090b60n%40googlegroups.com.