* 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 I don't understand is when can I postprocess them? I send data via the log functions, it goes to the log file. Where can I plug in postprocessing? Once it's in the log file?
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 don't know. I'm just stumbled. I know that the security fix is important. I just don't know what solution to provide to all users who rely on that feature that is now gone.
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?
I guess it doesn't matter where my point is, since it won't make any difference. I just don't know what the solution is.
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.
I wish I knew what you are talking about, Andre. Where can I postprocess things here?
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, "the program has failed: %s", error_mesg);
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...
me too
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
