activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Steiner (JIRA)" <>
Subject [jira] Commented: (AMQ-3211) JMSXUserId Can be spoofed by client
Date Thu, 10 Mar 2011 23:05:00 GMT


Michael Steiner commented on AMQ-3211:

> Can you validate the next 5.5-SNAPSHOT to ensure the fix captures your use case.

Thanks for the quick turn-around!!

I did not find a new built SNAPSHOT version but i saw changes in the
source and so built the version from svn.  While a few tests failed, 
(e.g., and
org.apache.activemq.bugs.AMQ2021Test), i could successfully run my
tests and confirm that with the change JMSXUserID could not be spoofed
anymore (at least not the way i did in the past ;-). 

> A client supplied JMSXUserID value is only used as a last resort. I
> think it is better from an interop and backward compatibility
> perspective to not explicitly disallow setting this property. 

I'm not sure whether there is really a good use case for having clients
providing it, at least my security mindset would make opt for erring
on the safe side.  However, some of the the scenarios mentioned in might need that
(although the original request still required validation at the broker
side which would be fail-safe).  However, I see at least two potentially
problematic cases:

- whether application code would see correct or potentially spoofed
  fields would depend on a config.

- what happens if the config must allow unauthenticated clients? 

The former is maybe more a stylic/robustness issue, i.e., multiple
lines of defense.   The latter though is a clear security issue. And
after a quick test with non-x509 based JAAS config  and

    org.apache.activemq.jaas.GuestLoginModule sufficient

it seems anonymous guest result in no JMXSUserID (ie.d., above
guest.user/group seem to be ignored as far as JMSXUserID is
concerned) and i can still spoof ids.

So ideally, not allowing clients from setting it at all would be
best. Alternatives, i see (in decreasing orders of desirability )

(a) provide an option which allows passing through only validated
    JMSXUserID  (or to be on the fail-safe side, an option which 
    would have to be explicitly provided to allow a pass-through)

(b) Garantuee that an anonymous user has always a well-identified
    broker-provided JMSXUserID value

(c)  provide a way for the code to check where the value come from.

(Arguably, all together might even be better :-)

Regarding (c), there is actually a way by which it can be safely
determined that the field is not spoofed: if
message.getPropertyNames() does not include JMSXUserID but
.getStringProperty("JMSXUserID") is returned, it will not have been
set by JMS client code. Not sure, though, whether one couldn't modify
the JMS client library to change that behaviour and it might also
provide false alerts if the client has set the value but the broker
has overridden/corrected it.

> JMSXUserId Can be spoofed by client
> -----------------------------------
>                 Key: AMQ-3211
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.4.2
>            Reporter: Michael Steiner
>            Assignee: Gary Tully
>             Fix For: 5.5.0
>         Attachments: JMSXUserID-bug.conf-src.tar.bz2, JMSXUserID-bug.diff
> It seems the JMSXUserId can be spoofed by client contrary to what
> My test setup is populateJMSXUserID="true set in a single broker, a JAAS config org.apache.activemq.jaas.TextFileCertificateLoginModule
and using mutual auth SSL (i.e., ?needClientAuth=true for transportConnector setup), and a
single consumer and producer based on small modifications of the ConsumerTool and ProducerTool
examples in the 5.4.2 distro.  See attached the changes to the distro package to demonstrate
the bug. Just do
> 1. run apache-activemq-5.4.2/bin/activemq-admin start
> 2. in apache-activemq-5.4.2/example run ant consumer -Durl=ssl://localhost:61617 -Dmax=3
> 3. in another shell in apache-activemq-5.4.2/example run ant producer -Durl=ssl://localhost:61617
-Dmax=3 -Dverbose=true
> 4. look at the output of the consumer for the properties printed after each received
message (the producer spoofs only on even numbered messages)
> When the client does not set the property, then i get the properly authenticated DN as
JMSXUserID using message.getStringProperty("JMSXUserID"). However, when the client sets it,
i get the value set by the client.  The only difference i notice is that in the former case,
message.getPropertyNames() does not return JMSXUserID whereas in the spoofed case it does.

> i wonder whether in the context of or (which interestingly doesn't list JMSXUserID
as supported in a comment even though it is?) something got messed up?

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message