chartmuseum v0.13.1 vulnerable against Log Injection

[janstarke]

Dear all,

I found that chartmuseum (v0.13.1) accepts %0a in URLs and forwards this character (newline) to logfiles, which allows attackers to inject custom logfile messages.

PoC

wget http://<hostname>/ind%0aex.yaml

inserts a newline between ind and ex.yaml in the logfile. An attacker can insert information such as "user 'XYZ' has been logged out" prior to perform malicious activity, to cover his traces.

Additional Information

https://capec.mitre.org/data/definitions/93.html

[scbizu]

Got it , will work out ASAP . Thank you .

[jdolitsky]

Hello @janstarke, and thanks for opening this issue.

In the future, please responsibly disclose security issues following the guidelines here.

Unfortunately I was not able reproduce this on both Mac and Linux. Instead the newline char \n ends up in the logs:

2022-01-21T13:08:40.890-0600	WARN	[1] Request served	{"path": "/ind\nex.yaml", "comment": "", "clientIP": "::1", "method": "GET", "statusCode": 404, "latency": "134.292µs", "reqID": "da2bbfc5-6c8f-4e20-b9d0-cd2e81dcb202"}

Could you share some more information on how to recreate this / how you are running v0.13.1?

[jdolitsky]

I see the issue. This seems to be affected only when using both DEBUG=true and LOG_JSON=false.

For users seeing this issue - these settings are not the default in the Helm chart deployment. You are likely unaffected unless you have specified both --set env.open.DEBUG=true and --set env.open.LOG_JSON=false.

The default for the binary itself is DEBUG=false and LOG_JSON=false, so you'd be unaffected unless you add the --debug flag.