-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 John,
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'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? >> 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. > 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. >> 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. Correct. I'm not sure if there's anything built-into httpd that can do this, but I'm sure it's possible using a custom module. For httpd 2.4, mod_lua can evidently do anything, as long as a library is available somewhere for the primitives (e.g. an HMAC signature). If you are going to do a signature with a pre-shared key, you could encrypt the data directly instead of sending the data + sig. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVt9IQAAoJEBzwKT+lPKRYRmYP/iddYiNNbQvpB1FUtRrh7+cl qy9j0qUyO9hafQReennzzWNkpxqwBqnBXKKQYGqzVKeKxzg9uQ2v9uKjGLefIiex mu6ylovw7+DvhxXeJmWtgxSF8XNttWK/DseE9i1mUsrfxmB3gJfa3+WOPvgZayad 0iGEVsxQCstQOqTgyh918xEcAEEo3VOci+2JcpqGJU1Hav6Ckjd+W9JFYTCbTt18 e/9+QQTjUrC9yl6BC5FsbQVYzRWHLkx3ZUAfoCTZTBahXHBmVouKFpiXH+QYzpCu hPR5xBiadHScI56z4kvMHowr2hKX794XEdCVKPPtYJNYU8sij3lmB2/wkGiOkEcV IIIkYF5pvb7rgQPeARS1KZGVnOKszUidFW0wshRqxQ372lKTmq8JIa8lTJskZGVv hwE3XsZQf1vJBAr43ncOfP6PqV+sy2MVMiP7f8CvpOl7Og9gmczsNcc/xE37/uwl 3l1QsZ/+PRaLR0YdVmiEnXtSpE+/2GJlJT7zXJj2/Ujs6FHfKclxgXTODuSvfeKg cHmKs4hU2QRVweNEqUy6f5K109WA0lc+S+hIdWubtWg3JX3CabPRPUaQpBjU2QhX pgp26al7dq0EsmHZSr073IJlvCsJdZH8ZC60/CTlnKnFILNU2PoQO55+LuIDTJOu mb94+dUvNknqwi+RUSjG =jb+f -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
