* Stas Bekman <[EMAIL PROTECTED]> wrote: > Andr� Malo wrote: >> * 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).
> I lost you here. what post processing? If you wanna log multiple lines, you just have to postprocess them. (Convert \n back into newlines etc.) >>>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> > That makes sense. I'm not talking about access_log, but error_log. I don't > think that concern applies to error_log which may contain absolutely anything > and i fail to see how it would be unsafe. Why not differentiate between > different logs? The problems are the same. Terminal corruption, evil code injection, faked log entries. Stas, we have closed a well known and remotely exploitable security leak. This goes straight over comfort. If you don't like it, provide an alternative solution. Just nagging or trying to talk the problem away doesn't help. >>>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. > Sorry, Andre, but I think this is an invalid statement. Tomorrow someone will > decide that logs shouldn't longer than 74 characters, and suggest that the API > never said/acked to be not 74 lines long? May be it's silly example, but I > hope you get the idea. Sure. But I don't see your point. Where do the docs say something about multilining? Where are the thousands of people that wondered about "broken" access logs in 1.3.25 or 2.0.4x? >> 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. > :( > Actually it's not only about \n and \t, it's about other chars as well. Now I > get error messages like this: <snip /> You can easily post process this entry, because it's *safely escaped* now. I don't understand how this (unescaping) could be such a big problem for you. nd P.S.: I'm some days more or less off, so don't worry if I don't reply immediately. I hope anyway, someone else will jump in and provide another opinion...
