jmestwa-coder opened a new pull request, #4235:
URL: https://github.com/apache/logging-log4j2/pull/4235
`Rfc5424Layout` sanitizes SD-PARAM-NAME and escapes SD-PARAM-VALUE, but two
neighboring fields of the same record go out unmodified:
- `appendMessageId` appends `StructuredDataMessage.getType()` raw, so a
newline in the type ends the record and what follows is read as a separate
syslog message
- `formatStructuredElement` appends the SD-ID raw, so a `]` closes the
element early and the remainder reads as a second, caller-controlled element
- neither `setType` nor the `StructuredDataId` constructors check
characters, only length, and both fields carry application data
`new StructuredDataMessage("a] [forged@1 user=\"root", "login ok",
"Audit\n<13>1 - - - - -")` through a `Syslog` appender, before:
```
<128>1 1970-01-01T05:30:00.001+05:30 host - 95177 Audit
<13>1 - - - - - [a] [forged@1 user="root] login ok
```
after:
```
<128>1 1970-01-01T05:30:00.001+05:30 host - 95119 Audit?<13>1?-?-?-?-?-
[a??[forged@1?user??root] login ok
```
Same `?` replacement #4073 introduced for parameter names. SD-ID reuses the
SD-NAME rule since RFC 5424 gives both fields the same production, MSGID keeps
the wider printable US-ASCII range its own rule allows. Lengths are left alone
so callers that raise `StructuredDataId`'s 32 character limit keep working.
## Checklist
* [x] Based on `2.x`
* [x] `./mvnw verify` succeeds (ran the build and `Rfc5424LayoutTest` for
`log4j-api`, `log4j-core` and `log4j-core-test` locally)
* [x] Entry added under `src/changelog/.2.x.x`
* [x] Tests are provided
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
