You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2008/07/17 15:57:31 UTC
[jira] Created: (MIME4J-57) Add a max limit to header length for
parsing.
Add a max limit to header length for parsing.
---------------------------------------------
Key: MIME4J-57
URL: https://issues.apache.org/jira/browse/MIME4J-57
Project: Mime4j
Issue Type: Bug
Affects Versions: 0.3
Reporter: Stefano Bagnara
Fix For: 0.4, 0.5
MIME4J-55 showed issues with very long multipart mime boundary.
It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
It would be good to define a maximum length for an header.
Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Resolved: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved MIME4J-57.
-------------------------------------
Resolution: Fixed
I am closing this issue as resolved and am proceeding with preparing the release. If find anything wrong with the latest changes, just go ahead and reopen the issue.
Oleg
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633064#action_12633064 ]
Oleg Kalnichevski commented on MIME4J-57:
-----------------------------------------
(1) @Stefano: Makes sense. Changed the base class of MaxLineLimitException from IOException to MimeException
(2) I added some javadocs to the MimeEntityConfig class. Please review. Feel free to add more content / correct my Ruslish if necessary
(3) I also realized the max line length limit was not correctly enforced for folded lines. Corrected. Added a test case.
(4) I also added a check for the maximum number of headers in a MIME entity. This should prevent a DoS condition if a message contains too many headers (more than 1000 per default)
Oleg
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633006#action_12633006 ]
Stefano Bagnara commented on MIME4J-57:
---------------------------------------
The line limit of 998 bytes+CRLF is from the MIME spec (rfc2822 - 2.1.1. Line Length Limits) , so maybe it should be a MimeException because this also is unrecoverable. With this option we simply make the length configurable, but it should never be less than 998 (maybe should be added to the javadoc for MimeEntityConfig, or maybe we should raise an exception if a value less than 998 is used.)
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated MIME4J-57:
------------------------------------
Attachment: maxlinelen.patch
The patch adds a configurable parameter that sets a limit on the maximum line length.
Please review and let me know what you think
Oleg
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated MIME4J-57:
----------------------------------
Priority: Critical (was: Major)
Increase the priority because this result in a DoS.
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Robert Burrell Donkin (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632946#action_12632946 ]
Robert Burrell Donkin commented on MIME4J-57:
---------------------------------------------
In favour but have some small nits (I can easily jump in and patch these afterwards if there's agreement)
@@ -78,6 +88,9 @@
while ((ch = in.read()) != -1) {
dst.append(ch);
total++;
+ if (this.maxLineLen > 0 && dst.length() >= this.maxLineLen) {
+ throw new IOException("Maximum line length limit exceeded");
+ }
if (ch == '\n') {
break;
}
I wonder whether a specific MimeException subclass might be more better. This would allow a user to catch and retry with a longer line limit.
===================================================================
--- src/main/java/org/apache/james/mime4j/parser/MimeStreamParser.java (revision 697358)
+++ src/main/java/org/apache/james/mime4j/parser/MimeStreamParser.java (working copy)
@@ -45,13 +45,30 @@
private ContentHandler handler = null;
private boolean contentDecoding;
- private final MimeTokenStream mimeTokenStream = new MimeTokenStream();
+
+ private final MimeTokenStream mimeTokenStream;
- public MimeStreamParser() {
+ public MimeStreamParser(final MimeEntityConfig config) {
super();
+ MimeEntityConfig localConfig;
+ if (config != null) {
+ try {
+ localConfig = (MimeEntityConfig) config.clone();
+ } catch (CloneNotSupportedException ex) {
+ // should never happen
+ localConfig = new MimeEntityConfig();
+ }
+ } else {
+ localConfig = new MimeEntityConfig();
+ }
+ this.mimeTokenStream = new MimeTokenStream(localConfig);
this.contentDecoding = false;
}
Should probably add a few javadoc documentation lines into MimeEntityConfig explaining why it needs to be cloneable since subclassers need to beware.
Alternatively, might be better just to make MimeEntityConfig immutable and so avoid all this cloning. This would be my preferred solution.
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Updated: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Stefano Bagnara (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated MIME4J-57:
----------------------------------
Fix Version/s: (was: 0.4)
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Fix For: 0.5
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633000#action_12633000 ]
Oleg Kalnichevski commented on MIME4J-57:
-----------------------------------------
> I wonder whether a specific MimeException subclass might be more better. This would allow a user to catch and retry with a longer line limit.
Makes sense.
> Should probably add a few javadoc documentation lines into MimeEntityConfig explaining why it needs to be cloneable since subclassers need to beware.
The class is made final to make sure it cannot be extended. So, this should not be an issue
> Alternatively, might be better just to make MimeEntityConfig immutable and so avoid all this cloning. This would be my preferred solution.
I thought about it. However, this approach gets really cumbersome if you all you want to change just one parameter.
I will commit the patch as is. You are welcome to make changes that you deem necessary.
Oleg
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] Commented: (MIME4J-57) Add a max limit to header length for
parsing.
Posted by "Oleg Kalnichevski (JIRA)" <se...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633003#action_12633003 ]
Oleg Kalnichevski commented on MIME4J-57:
-----------------------------------------
> I wonder whether a specific MimeException subclass might be more better. This would allow a user to catch and retry with a longer line limit.
Robert,
I added a new exception class specifically for signaling an error when a line exceeds the max length limit. However, I derived that class from IOException rather than MimeException as I though this error did not have a lot to do with the MIME spec. Hope it is okay with you.
Feel free to take over now.
Oleg
> Add a max limit to header length for parsing.
> ---------------------------------------------
>
> Key: MIME4J-57
> URL: https://issues.apache.org/jira/browse/MIME4J-57
> Project: JAMES Mime4j
> Issue Type: Bug
> Affects Versions: 0.3
> Reporter: Stefano Bagnara
> Priority: Critical
> Fix For: 0.5
>
> Attachments: maxlinelen.patch
>
>
> MIME4J-55 showed issues with very long multipart mime boundary.
> It has been fixed by having the buffer size depending on the boundary length. This create possible issues (OOM/DoS) with malicious messages.
> It would be good to define a maximum length for an header.
> Somewhere in mime rfc or smtp rfc there is a maximum of 998+CRLF ascii bytes per line, of course we may want to support longer headers, but not very long ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org