The new CSRF protection of the Balancer Manager breaks editing functionality for browsers that lowercase hostnames in the Referer: header; e.g. Chrome The error is based on the usage of strcmp() in the safe_referer() function https://github.com/apache/httpd/blob/2.4.x/modules/proxy/mod_proxy_balancer.c#L1107
(In reply to Armin Abfalterer from comment #0) > The new CSRF protection of the Balancer Manager breaks editing functionality > for browsers that lowercase hostnames in the Referer: header; e.g. Chrome > > The error is based on the usage of strcmp() in the safe_referer() function > > https://github.com/apache/httpd/blob/2.4.x/modules/proxy/mod_proxy_balancer. > c#L1107 thanks for the report and sorry for the inconvenience. Trunk r1865749 and proposing for backport to 2.4.x.
hi all, mybe i found a kind of same problem. in my configuration i used the balancer manager behind a proxy ------------- |Bastian Host | |Apache Proxy | -----------> LB Apache Balancer Manger ------------- and i struggle in the problem with an update from Ubuntu 18.04 which i described in the following bug report https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1842701 on localhost with lynx i figure out error log entrys with every submit and no update from the load data etc. :~# tail -f /var/log/apache2/management_error.log [Wed Sep 04 12:28:58.249737 2019] [proxy_balancer:error] [pid 14669:tid 140254497400576] [client 127.0.0.1:42844] AH10187: ignoring params in balancer-manager cross-site access [Wed Sep 04 12:29:09.585221 2019] [proxy_balancer:error] [pid 14669:tid 140254623291136] [client 127.0.0.1:42848] AH10187: ignoring params in balancer-manager cross-site access i can reproduce this within debian 10 :~# apt-get install apache2 :~# dpkg -l | grep apache2 ii apache2 2.4.38-3+deb10u1 ii apache2-bin 2.4.38-3+deb10u1 ii apache2-data 2.4.38-3+deb10u1 ii apache2-utils 2.4.38-3+deb10u1 i download the prior version from the module and compile that version http://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.40/modules/proxy/mod_proxy_balancer.c :~# apxs2 -c -i mod_proxy_balancer.c :~# systemctl restart apache2 :~# lynx 127.0.0.1:81/balancer-manager :~# elinks 127.0.0.1:81/balancer-manager Browser: http://192.168.56.211:81/balancer-manager i can use the balancer manager as expected without any error log entry i compiled also that version from https://svn.apache.org/viewvc?view=revision&revision=1865749 but with no luck. regards horst
can you try something like this since you had a sandbox env: Index: modules/proxy/mod_proxy_balancer.c =================================================================== --- modules/proxy/mod_proxy_balancer.c (revision 1866509) +++ modules/proxy/mod_proxy_balancer.c (working copy) @@ -1185,7 +1185,7 @@ /* Ignore parameters if this looks like XSRF */ ref = apr_table_get(r->headers_in, "Referer"); if (apr_table_elts(params) - && (!ref || !safe_referer(r, ref))) { + && (ref && !safe_referer(r, ref))) { ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(10187) "ignoring params in balancer-manager cross-site access"); apr_table_clear(params); No referer should pass through IIUC.
Well, Eric you suggested it, so maybe I got it wrong ;) In all valid requests to the balancer-manager the previous URI should be the balancer-manager page, and hence Referer should be set. So ignoring params if Referer is not present was definitely deliberate. So OP are you're saying this fails with lynx and works with elinks?
BTW I can't comment on that Ubuntu page without creating an account, so please point them to this comment The referenced change to mod_proxy/mod_proxy_balancer has NOTHING to do with CVE-2019-10092. CVE-2019-10092 is fixed by https://svn.apache.org/viewvc?view=revision&revision=1864191
if i came from ousite with firefox and on the console with elinks the first connect :~# http://192.168.56.225:81/balancer-manager :~# tail -f /var/log/apache2/management_error.log [Sat Sep 07 12:37:39.907268 2019] [proxy_balancer:error] [pid 6582:tid 140508132738816] [client 192.168.56.1:52006] AH10187: ignoring params in balancer-manager cross-site access :~# elinks 127.0.0.1:81/balancer-manager :~# tail -f /var/log/apache2/management_error.log [Sat Sep 07 12:40:42.786775 2019] [proxy_balancer:error] [pid 6582:tid 140507992790784] [client 127.0.0.1:48454] AH10187: ignoring params in balancer-manager cross-site access creates on error log entry but it workes with lynx first connect and every submit creates the log entry :~# lynx 127.0.0.1:81/balancer-manager :~# tail -f /var/log/apache2/management_error.log [Sat Sep 07 12:41:43.620865 2019] [proxy_balancer:error] [pid 6582:tid 140507900471040] [client 127.0.0.1:48460] AH10187: ignoring params in balancer-manager cross-site access [Sat Sep 07 12:42:20.582399 2019] [proxy_balancer:error] [pid 6582:tid 140508132738816] [client 127.0.0.1:48466] AH10187: ignoring params in balancer-manager cross-site access [Sat Sep 07 12:42:33.611602 2019] [proxy_balancer:error] [pid 6582:tid 140508043147008] [client 127.0.0.1:48468] AH10187: ignoring params in balancer-manager cross-site access [Sat Sep 07 12:42:37.749409 2019] [proxy_balancer:error] [pid 6582:tid 140508026361600] [client 127.0.0.1:48470] AH10187: ignoring params in balancer-manager cross-site access so yes lynx ist not working - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - with your patch on http://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.41/modules/proxy/mod_proxy_balancer.c i got no errog log entrys and lynx is also working for my sandbox env. thx horst i create the hint on the ubuntu page
Sorry I'm struggling to parse your comemnts, Horst. From a quick search it looks some versions of Lynx don't produce Referer headers. They won't work with mod_proxy_balancer since 2.4.41, because we made tightened up the XSRF protection. This is unfortunate but we don't have a better way to protect against XSRF.
i'am sorry for that... on the ubuntu page is a further more discussion and i explain and test the initilal problem LB manager behind a proxy ist not working after the update. mybe this helped out to get my problem more clear. lynx is only comming to the playground for debug the initial problem. lynx with your patch ist start working again. but good to know that in the future lynx is mybe not a good choice for debugging purpose on that point.
This has been backported in 2.4.x branch in r1865966 This is part of 2.4.42. Not sure that comments in comment #2 and below are related. If needed, please open a new bug report for it.