You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2004/12/23 19:24:41 UTC
Re: cvs commit:
logging-log4j/tests/src/java/org/apache/log4j/pattern
CachedDateFormatTest.java
Hi Curt,
At 07:15 PM 12/23/2004, Ceki Gülcü wrote:
>At 06:59 PM 12/23/2004, you wrote:
>>That seems to be substantially upping the complexity of
>>CachedDateFormat. It seemed a lot simpler to protect against that
>>weakness by checking for it DatePatternConverter. Something like:
>>
>> try {
>> if (pattern.indexOf("S") == -1 || pattern.indexOf("SSS") != -1) {
>> df = new CachedDateFormat(SimpleDateFormat(pattern));
>> } else {
>> df = new SimpleDateFormat(pattern);
>> }
>>
>> } catch (IllegalArgumentException e) {
In unlikely case where the pattern contains quoted 'S' characters the
(pattern.indexOf("S") == -1 || pattern.indexOf("SSS") != -1) will be unsafe.
>>Also, the slot stuff also seemed to up the complexity. I was trying to
>>make it simpler at some trival cost (an extra dateformat per second or
>>so) and still avoid the migrating millisecond field problem, I thought
>>that I had adequately addressed that weakness.
Indeed, maybe you have adequately addressed the migrating millisecond field
problem. I have to look at the code again. (I was not fully aware of the
migrating millisecond field problem encountered with 1 or 2 'S' when I
started making changes.) Let me look at your latest version again and come
back to you.
--
Ceki Gülcü
The complete log4j manual: http://qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: cvs commit: logging-log4j/tests/src/java/org/apache/log4j/pattern CachedDateFormatTest.java
Posted by Curt Arnold <ca...@apache.org>.
On Dec 23, 2004, at 12:24 PM, Ceki Gülcü wrote:
>
> Hi Curt,
>
> At 07:15 PM 12/23/2004, Ceki Gülcü wrote:
>> At 06:59 PM 12/23/2004, you wrote:
>>> That seems to be substantially upping the complexity of
>>> CachedDateFormat. It seemed a lot simpler to protect against that
>>> weakness by checking for it DatePatternConverter. Something like:
>>>
>>> try {
>>> if (pattern.indexOf("S") == -1 || pattern.indexOf("SSS") != -1)
>>> {
>>> df = new CachedDateFormat(SimpleDateFormat(pattern));
>>> } else {
>>> df = new SimpleDateFormat(pattern);
>>> }
>>>
>>> } catch (IllegalArgumentException e) {
>
> In unlikely case where the pattern contains quoted 'S' characters the
> (pattern.indexOf("S") == -1 || pattern.indexOf("SSS") != -1) will be
> unsafe.
>
It you want to catch that, then AND a pattern.indexOf("'") == -1 to the
conditional but I wouldn't. I'm thinking that if someone writes a
pattern that contains SSS in a literal and only S or S Sin the active
format and follows that with other content, then they deserve to have
some of the following content overwritten. If we have a malicious
person with access to the configuration, they could do a whole lot more
damage by switching the position of the month and the date fields or
than using the milliseconds field to overwrite the following content.
Since we can't prevent the more serious attack, I would not obsess much
more about it.
>>> Also, the slot stuff also seemed to up the complexity. I was trying
>>> to make it simpler at some trival cost (an extra dateformat per
>>> second or so) and still avoid the migrating millisecond field
>>> problem, I thought that I had adequately addressed that weakness.
>
> Indeed, maybe you have adequately addressed the migrating millisecond
> field problem. I have to look at the code again. (I was not fully
> aware of the migrating millisecond field problem encountered with 1 or
> 2 'S' when I started making changes.) Let me look at your latest
> version again and come back to you.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org