Hello,
> I'm not sure how long ago that was, but I don't live in the Windows
> world. I would have thought that someone at Apache Lounge would have
> balked if a release was broken. Were you building a release version,
> or trunk?
I downloaded a release. This was a few years ago now. I suspect mod_jk
on Windows is no longer well used. Windows as a hosting platform in
larger organisations (the type that use Tomcat) is not common, and
vendors ship some random old version of the module dating back years
("it works [*], why change it?").
[*] we don't do security.
> > And having got involved and contributed a few years ago, I recall
> > the code being somewhat in need of refurbishment, as does pretty
> > much all 15+ year old C/Java/....
>
> Last time I checked, C code pretty much compiled the same way it did
> 25 years ago. I don't see a particular need to go in there and change
> a whole lot of stuff.
Just because it compiles doesn't mean it's a work of art. I look at much
of what I wrote ten years ago, back in the Tomcat 3 days, and cry.
> Nobody is making anyone use AJP.
They are encouraging it if it's doing something the HTTP connector does
not.
> be invented. Probably some meta-information passed-through in HTTP
> headers. It would work, but it would be a pain, and it would be more
> difficult to hide those implementation details from the application.
Disagree. It's entirely easy to publish the username of common SSO
systems (Oracle Access Manager, OpenSSO/AM, Tivoli, SiteMinder, RSA
Access Manager [ClearTrust] to name but a few) as an HTTP header. The
typical integration approach is "publish username as an HTTP header
using Apache module, reverse proxy onto Tomcat and pick up via your Java
app".
I'm suggesting that this support should be more integrated to the
getRemoteUser() call, as has been implemented with AJP.
> >> So, your proposed implementation is incorrect and represents a
> >> security vulnerability.
> >
> > It does not represent a security vulnerability.
>
> Sure it does: a client can supply a forged REMOTE_USER header quite
> easily.
Yes, and that's precisely the problem with mod_jk. Anyone with local
access to the host can do the same as a
Apache/mod_proxy_http/REMOTE_USER solution. I'm amazed the wider
security world hasn't picked up on the widely abused mod_jk security
hole.
> So, how is Tomcat supposed to know that the request has been
> properly-sanitized? At least with AJP, one expects that a nearby web
> server is making the request and that the user knows what they are
> doing. Nobody sets up a one-box-wonder in production with the AJP port
> publicly available. But people do that all the time with port 80
> available publicly.
Well, for a start, I'm not sure the AJP connector comes bound to
localhost (tomcat 8.x download):
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
Next, no-one makes any effort to secure AJP to Apache. And whilst I'm
sympathetic to the sanitisation of HTTP headers (by Apache) belief, I'm
not sure Tomcat's now decade old HTTP connector - that has had lots of
attention/work - needs the protection once offered by Apache HTTPd. It
would certainly be interesting to get the two pen-tested.
The sad fact is that the majority of Tomcat AJP enabled deployments with
tomcatAuthentication="false" are vulnerable to injection, perhaps even
not from localhost!
> Care to file a Bugzilla enhancement for that?
How do? :)
> I don't like your proposed implementation, but that doesn't mean that
> it could work similar to the way you've described it. For one thing,
> it should be a configuration option that is off *by default*.
Actually, I don't like it very much, but I'd like to see some
consistency. This includes extensive logging/warning/nagging when AJP is
not bound to localhost and tomcatAuthentication="false", and hence
greater transparency on this security issue.
I'd also like a better way and after discussing with some
security-geeks, we were wondering if there's some way we can implement a
Valve that takes a username and a signature using a shared secret. The
problem is signing in Apache: I've not looked too hard for a module to
do this but maybe one exists? If one does exist, then the mod_jk module
could use the same strategy to ensure Tomcat only trusts a username +
valid signature.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
