Closed mihaigalos closed 6 months ago
I don't see how we would solve this problem in the log crate. If I understand the problem correctly it stems from parsers that don't deal with ANSI escape sequences correctly or the transport between the log producer and the log parser. That's of course out of scope for the log crate.
For the not-creating-escape-sequence part, that would be up to the logging implementation as this crate is just a facade. We could add some documentation to this effect.
Hi @Thomasdezeeuw, in the talk this point is adressed at 35:24. The speaker's informed opinion is that the input be sanitized and the output escaped (36:09).
Hi @Thomasdezeeuw, in the talk this point is adressed at 35:24. The speaker's informed opinion is that the input be sanitized and the output escaped (36:09).
What does escaped mean here? How do you escape something if you don't know the output format (as again, log is a facade, it doesn't do the actual logging)?
I don't believe this is a concern for the log
crate to handle; its job is to wire callers of the log!
macros to some Log
implementation. It's the responsibility of that Log
implementation to deal with encoding issues.
I'll go ahead and close this one, but please feel free to open new issues with any other questions you might have!
Is there any mechanism to protect against code injection via logging?
This talks about server-side code injection from a client connecting via a socket and sending ANSI escape sequences.
The escape sequences get parsed on the server once the logs are evaluated (i.e.: in a shell via
less
ortail
for example).The atack vector is very subtle but doable without explicit countermeasures.
Ideally, the logging should have a opt-out option to automatically strip these control sequences so as to guard against code injection.