Command line length limit

[fsacer]

Not sure if there is any length limit for the command line log in place (I think I might have had it a couple of times where some software executed a long base64 encoded script via bash) or if it is configurable somewhere?

[bostjan]

(I am not sure why I am either not getting email notifications about newly opened issues, or missing these notifications in my inbox. Sorry for the late response.)

@fsacer, you can find various limits here. The main ones are:

• SNOOPY_DATASOURCE_MESSAGE_MAX_SIZE (max length of a response from each individual datasource)
• SNOOPY_LOG_MESSAGE_BUF_SIZE (max overall length of a formatted message)

So, in your case, 2K characters was probably the limit you've hit.

Technically, you can raise them by rebuilding yourself with the correct -D... flags. So far, the use case for even longer log messages has not been presented/suggested, but now that you mention it, I can't really recall a reason for it being statically defined instead of being configurable in the config file, except maybe needing to take care of fewer dynamic memory allocations.

What's the actual use case here, what is generating these large base64-encoded command line arguments?

[fsacer]

Hey sorry for the late response, the use case here was that a CTF challenge was running a script base64 encoded script so I was only able to read part of it because of the length limits. It would definitely be useful to be able to configure this via snoopy's config file.

[bostjan]

Let me think about this.

[fsacer]

cool, would really be nice to have the config option for this

[bostjan]

@fsacer, I am thinking about having:

• Two configurable values in the config file, one for per-datasource max result length, and the other for the max overall message length.
• Two maximum limits for the above, that can't be increased from the config file. The intention here is to protect the system from unintended excessive resource consumption, and changing these will require a rebuild from sources.

What would be your idea of the maximum limits mentioned above? Or, maybe a bit simpler way of putting it - what is the absolute max message length that you're expecting to see in your use case?

[fsacer]

Based on this issue microsoft/azure-pipelines-tasks#6509 I am thinking 100k could be a good fail-safe maximum, the default limit could stay at 2k or changed to 8k like in cmd.exe.

[bostjan]

Alright, this just landed in master. @fsacer, would you be kind enough to try it out before I release it in a stable version?

Note to self - I should probably add a few more functional tests, to make sure the new configurable limits are really applied as intended.

PS: I thought this was going to be a relatively small change, but I didn't realise at the time just how ingrained in the codebase the static message limit definitions have became over time.

[fsacer]

hey thanks, I will try to test it out when I play the next challenge, will update here