[musl] Potential Injection Vulnerability in _vsyslog Function

[musl] Potential Injection Vulnerability in _vsyslog Function

[whistle]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

In the current _vsyslog function, if the log contains characters like \r or \n, according to CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection'), this could potentially lead to an injection vulnerability. 




When using musl, would it be safer to explicitly handle \r and \n here as an extra security measure?

[-- Attachment #2: Type: text/html, Size: 1489 bytes --]

Re: [musl] Potential Injection Vulnerability in _vsyslog Function

[Rich Felker]

On Thu, May 08, 2025 at 11:14:55PM +0800, whistle@mail.ustc.edu.cn wrote:
> In the current _vsyslog function, if the log contains characters
> like \r or \n, according to CWE-93: Improper Neutralization of CRLF
> Sequences ('CRLF Injection'), this could potentially lead to an
> injection vulnerability.
> 
> 
> When using musl, would it be safer to explicitly handle \r and \n
> here as an extra security measure?

I don't think there's any reason we should be munging the contents of
the log message here. The syslogd receiving the datagram is free to
reject embedded newlines (meaning \n; \r is completely irrelevant here
AFAICT) or store them in some storage-backend-specific way. If it
stores them in a manner where they can be misinterpreted as the start
of a new log record with different process credentials, that seems
like a weakness in the syslogd not in the libc. Especially since
someone wanting to do that could just write their own client sending
the datagrams with embedded newlines to /dev/log, no?

Rich