* Stas Bekman <[EMAIL PROTECTED]> wrote: > Yes, but we use it to log error messages which aren't under our control. > e.g. from user's programs, like cgi scripts. what are we supposed to do? > parse and split a multiline message and invoke the logger n times?
post processing, (which was actually hard to do before and safe now). > What security fault in printing a new line and tab characters? Sorry if > I've missed this discussion. Any pointers? The same as in access log. For example, an attacker can fake a log entry by injecting a newline into the URL (%0a) and data that looks like a timestamp + message. You wouldn't have gotten it. \ts are actually questionable. I like the escaping at this point to get a clear distinction between spaces and tabs. I'm not sure, however, if there are terminals that don't like them. References can be found in the CVE-Entry: <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020> > I also fail to see server/http_log.h telling anything about this newly > introduced restriction. It was never documented as line oriented, which > means that you just changed the public API in the middle of the road, no? It was never said/acked to be not line oriented. Where are we now? A line in the {access,error}log consists of a timestamp and a message. That is expected behaviour, which was broken way too long. We may, however, decide to add an #ifdef SECURITY_HOLE_LOG_INJECTION or the like to re-add the broken behaviour of not escaping \n. nd
