On 07/28/2015 02:03 PM, Christopher Schultz wrote:
On 7/28/15 2:29 PM, John Baker wrote:
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.
I'm guessing it's less popular than on *NIX. George Stanchev (a Tomcat
community member) is certainly using it. He filed a bug and patch
against the ISAPI module that coincidentally has to do with
REMOTE_USER handling.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57836
Windows is not being ignored.
I've been building and shipping and supporting an apache based web
server for windows, linux, aix, and solaris for well over a decade now.
I can't recall the last time i had a problem with mod_jk on windows
that didn't also exist on other platforms. I've also been building and
maintaining 32 and 64-bit isapi_redirect.dlls. I can't give numbers,
but I'm confident to say i have a very good sample set.
The only Windows-specific problem I can think of is the ISAPI
remote_user = "" that was being described on a bugzilla report that I
ran into years ago and we assumed it was a flaw in IIS/ISAPI so never
reported it to tomcat folk :) [ reading the thread, i'm not convinced it
isn't a flaw with ISAPI ]
I'm mostly a lurker on these mailing lists (and have been on them for
over a decade as well) primarly because I don't have alot of problems,
and usually when I do run across one, someone already has reported it
and it's already been fixed. This is true on all of the platforms I
have to support including Windows.
I'm suggesting that [REMOTE_USER via HTTP header] support should be
more integrated to the getRemoteUser() call, as has been
implemented with AJP.
Agreed. I just don't like your proposed patch. Note that the AJP
connector *does not* do it like your proposal did. AJP uses a
side-channel that does not involve HTTP headers.
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.
It's rare to have port 8009 open to the world, but you're right:
anyone on localhost can own you. But if they have localhost, you are
already owned anyway, right?
I constantly have to explain to people why a header cannot simply be
blindly trusted for secure data :)
In terms of the localhost issue, you have the combination of securing
the host, and also potentially file security combined with an AJP
secret. That's one additional mechanism
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.
I'm just suggesting that if Apache httpd is going to be trading
authentication headers with Tomcat, it should do it properly. It's
easy to overlook the "Header unset REMOTE_USER" configuration that
would be required to first sanitize the incoming HTTP request.
This has nothing to do with whether or not httpd makes sense out in
front of Tomcat (and there are still some good reasons for that): your
use-case pre-supposes that setup.
I'm not sure there is a better way to do this. REMOTE_USER is the
standards based mechanism of communicating this from a trusted web
server to a consumer of that data.
AJP is intended to be for this purpose. There's no RFC/official IETF
spec for AJP, but the documentation for AJP:
https://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html
"According to email from Gal Shachor to the jakarta-dev mailing list,
the original goals of JK (and thus ajp13) were to extend mod_jserv and
ajp12 by (I am only including the goals which relate to communication
between the web server and the servlet container):"
So the primary goal of this was web server to servlet engine
communication, via a module. so REMOTE_USER is appropriate for AJP.
But for http (apache, IIS, whatever) to Tomcat HTTPConnector, you're
talking about an http proxy. HTTP proxy authentication passthrough is a
very different thing than a protocol (ajp) specifically designed to
facilitate communication from the webserver to tomcat.
I haven't looked too closely, but I'm not sure what "standard"
mechanisms there are to communicate this through a proxy. variables
don't pass through a proxy, and a HEADER is NOT the proper solution here
unless you also implement something similar to the Tomcat RemoteIpValve
where you have the notion of trustedProxiesForAuth or something like that.
The sad fact is that the majority of Tomcat AJP enabled deployments
with tomcatAuthentication="false" are vulnerable to injection,
perhaps even not from localhost!
True, but that's not the default configuration. Your proposed patch
would accept a REMOTE_USER header from anywhere, by default, and with
no way to disable it.
Like I said, I like the idea, just not your patch.
I completely 100% agree with the sentiment that
tomcatAuthentication="false" probably should document this, at the same
time, this is the type of thing you need to vet with your own security
folk. This is an open source - ymmv - project. I'm fairly certain the
tomcat folk will gladly accept documentation assistance as well as patches.
Care to file a Bugzilla enhancement for that?
How do? :)
https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%209
You'll need to register for an account. The only email I get from
Apache's bug system relates to bugs I've filed or ones I'm watching,
etc. It won't increase your email volume much.
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.
Feel free to bring these issues up on the dev list. I haven't seen
anyone else participating in this thread here; maybe you'll get better
responses over there. Or you could file enhancements in Bugzilla.
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.
Take a look at the RemoteIpValve. One could make something similar, say
a RemoteAuthenticationValve, would be my guess. Given that you're using
a shared secret already, I'm not sure what signing will buy you. If
some malicious entity gets the shared secret, the signature/encryption
is going to do nothing for you. If you're concerned about the message
secured by the shared secret being in plain text across a remote
http<->tomcat configuration, I imagine stunnel would help solve the problem
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
