[
https://issues.apache.org/jira/browse/JAMES-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-4018:
----------------------------------
Description:
Currently a SMTP transaction parses RCPT parameters twice:
- in RcptCmdHandler::doFilterChecks for parameter validity checks
- in RcptCmdHandler::callHooks for actual calls of possible handlers
1. it is wasteful?
2. it clearly create a parser differencial as RcptCmdHandler::callHooks
includes the email address in the parameter parsing.
Valid email addresses like "anything> [email protected] "@carrier.com
would have no rcpt parameters as per doFilterChecks but have one as per
callHooks and thus could "trick" the unsuspecting email server to "inject" RCPT
parameters mid-transaction.
Can this be exploited in a real life attack? Not sure TBH.
h3. How it was detected
I spotted this weird log:
{code:java}
java.lang.IllegalArgumentException: Multiple entries with same key: ,= and ,=
at
com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
at
com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
at
com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
at
com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
at
com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:572)
at
com.google.common.collect.ImmutableMap$Builder.buildOrThrow(ImmutableMap.java:600)
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:587)
at
org.apache.james.protocols.smtp.core.RcptCmdHandler.parseParameters(RcptCmdHandler.java:230)
at
org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:219)
at
org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:55)
at
org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.processHooks(AbstractHookableCmdHandler.java:117)
at
org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:75)
at
org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:50)
at
org.apache.james.protocols.api.handler.CommandDispatcher.dispatchCommandHandlers(CommandDispatcher.java:165)
at
org.apache.james.protocols.api.handler.CommandDispatcher.onLine(CommandDispatcher.java:142)
{code}
And reproduced it with:
{code:java}
RCPT TO: <"any> ,= ,= "@ccc.fr>
{code}
CF https://github.com/linagora/james-project/issues/5119
h3. The fix
Like the email address use the smtp session parameters to cary over the
parameters from doFilterChecks to callHooks...
was:
Currently a SMTP transaction parses RCPT parameters twice:
- in RcptCmdHandler::doFilterChecks for parameter validity checks
- in RcptCmdHandler::callHooks for actual calls of possible handlers
1. it is wasteful?
2. it clearly create a parser differencial as RcptCmdHandler::callHooks
includes the email address in the parameter parsing.
Valid email addresses like "anything> [email protected] "@carrier.com
would have no rcpt parameters as per doFilterChecks but have one as per
callHooks and thus could "trick" the unsuspecting email server to "inject" RCPT
parameters mid-transaction.
Can this be exploited in a real life attack? Not sure TBH.
h3. How it was detected
I spotted this weird log:
{code:java}
java.lang.IllegalArgumentException: Multiple entries with same key: ,= and ,=
at
com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
at
com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
at
com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
at
com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
at
com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:572)
at
com.google.common.collect.ImmutableMap$Builder.buildOrThrow(ImmutableMap.java:600)
at
com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:587)
at
org.apache.james.protocols.smtp.core.RcptCmdHandler.parseParameters(RcptCmdHandler.java:230)
at
org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:219)
at
org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:55)
at
org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.processHooks(AbstractHookableCmdHandler.java:117)
at
org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:75)
at
org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:50)
at
org.apache.james.protocols.api.handler.CommandDispatcher.dispatchCommandHandlers(CommandDispatcher.java:165)
at
org.apache.james.protocols.api.handler.CommandDispatcher.onLine(CommandDispatcher.java:142)
{code}
And reproduced it with:
{code:java}
{code}
CF https://github.com/linagora/james-project/issues/5119
h3. The fix
Like the email address use the smtp session parameters to cary over the
parameters from doFilterChecks to callHooks...
> RCPT TO parser differencial
> ---------------------------
>
> Key: JAMES-4018
> URL: https://issues.apache.org/jira/browse/JAMES-4018
> Project: James Server
> Issue Type: Bug
> Components: SMTPServer
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.9.0
>
>
> Currently a SMTP transaction parses RCPT parameters twice:
> - in RcptCmdHandler::doFilterChecks for parameter validity checks
> - in RcptCmdHandler::callHooks for actual calls of possible handlers
> 1. it is wasteful?
> 2. it clearly create a parser differencial as RcptCmdHandler::callHooks
> includes the email address in the parameter parsing.
> Valid email addresses like "anything> [email protected] "@carrier.com
> would have no rcpt parameters as per doFilterChecks but have one as per
> callHooks and thus could "trick" the unsuspecting email server to "inject"
> RCPT parameters mid-transaction.
> Can this be exploited in a real life attack? Not sure TBH.
> h3. How it was detected
> I spotted this weird log:
> {code:java}
> java.lang.IllegalArgumentException: Multiple entries with same key: ,= and ,=
> at
> com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
> at
> com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
> at
> com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
> at
> com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
> at
> com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
> at
> com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:572)
> at
> com.google.common.collect.ImmutableMap$Builder.buildOrThrow(ImmutableMap.java:600)
> at
> com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:587)
> at
> org.apache.james.protocols.smtp.core.RcptCmdHandler.parseParameters(RcptCmdHandler.java:230)
> at
> org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:219)
> at
> org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:55)
> at
> org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.processHooks(AbstractHookableCmdHandler.java:117)
> at
> org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:75)
> at
> org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:50)
> at
> org.apache.james.protocols.api.handler.CommandDispatcher.dispatchCommandHandlers(CommandDispatcher.java:165)
> at
> org.apache.james.protocols.api.handler.CommandDispatcher.onLine(CommandDispatcher.java:142)
> {code}
> And reproduced it with:
> {code:java}
> RCPT TO: <"any> ,= ,= "@ccc.fr>
> {code}
> CF https://github.com/linagora/james-project/issues/5119
> h3. The fix
> Like the email address use the smtp session parameters to cary over the
> parameters from doFilterChecks to callHooks...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
