The Mediawiki auth plugin has to contact admin.fedoraproject.org in order to lookup the users and verify their passwords. It's using curl to do so. One of the options being given to curl is the following:
# This is only required because of the wildcard cert on pt10 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
That turns off verifying the host via SSL. From the comment it appears to only be needed with the test FAS server. I'd like to comment this line out.
This is a flaw that potentially opens us to a DNS spoofing attack to compromise authentication. Luckily for us, there is a problem with routing to admin.fedoraproject.org within PHX so we have an /etc/hosts entry for admin.fp.o that directs the wiki to use an internal IP address. That means for this flaw to affect us, someone would have to compromise the /etc/hosts files rather than a DNS server. So we should fix this but compromising it is not as easy.
If this fails, we will see authentication failures when we try to login to the wiki and can revert.
Can I get a couple +1's?
-Toshio
Ricky Zhou wrote:
On 2009-01-30 01:46:22 PM, Toshio Kuratomi wrote:
If this fails, we will see authentication failures when we try to login to the wiki and can revert.
Can I get a couple +1's?
+1, thanks for catching this.
Thanks go to the newly added docs guys :-)
itbegins, sparks, and ke4qqq are the three that caught it while porting the mediawiki auth plugin to work with zikula.
-Toshio
2009/1/30 Toshio Kuratomi a.badger@gmail.com:
The Mediawiki auth plugin has to contact admin.fedoraproject.org in order to lookup the users and verify their passwords. It's using curl to do so. One of the options being given to curl is the following:
# This is only required because of the wildcard cert on pt10 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
That turns off verifying the host via SSL. From the comment it appears to only be needed with the test FAS server. I'd like to comment this line out.
Can I get a couple +1's?
+1
Toshio Kuratomi wrote:
The Mediawiki auth plugin has to contact admin.fedoraproject.org in order to lookup the users and verify their passwords. It's using curl to do so. One of the options being given to curl is the following:
# This is only required because of the wildcard cert on pt10 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
That turns off verifying the host via SSL. From the comment it appears to only be needed with the test FAS server. I'd like to comment this line out.
This is a flaw that potentially opens us to a DNS spoofing attack to compromise authentication. Luckily for us, there is a problem with routing to admin.fedoraproject.org within PHX so we have an /etc/hosts entry for admin.fp.o that directs the wiki to use an internal IP address. That means for this flaw to affect us, someone would have to compromise the /etc/hosts files rather than a DNS server. So we should fix this but compromising it is not as easy.
If this fails, we will see authentication failures when we try to login to the wiki and can revert.
After looking at this a little more with G, there's two settings to toggle:
CURLOPT_SSL_VERIFYPEER CURLOPT_SSL_VERIFYHOST
They're both set to off right now and I'd like to turn them both back on. Tested with a small php script that turning them on doesn't interfere with retrieving data.
Can I get a couple +1's?
-Toshio
On Fri, 30 Jan 2009, Toshio Kuratomi wrote:
Toshio Kuratomi wrote:
The Mediawiki auth plugin has to contact admin.fedoraproject.org in order to lookup the users and verify their passwords. It's using curl to do so. One of the options being given to curl is the following:
# This is only required because of the wildcard cert on pt10 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
That turns off verifying the host via SSL. From the comment it appears to only be needed with the test FAS server. I'd like to comment this line out.
This is a flaw that potentially opens us to a DNS spoofing attack to compromise authentication. Luckily for us, there is a problem with routing to admin.fedoraproject.org within PHX so we have an /etc/hosts entry for admin.fp.o that directs the wiki to use an internal IP address. That means for this flaw to affect us, someone would have to compromise the /etc/hosts files rather than a DNS server. So we should fix this but compromising it is not as easy.
If this fails, we will see authentication failures when we try to login to the wiki and can revert.
After looking at this a little more with G, there's two settings to toggle:
CURLOPT_SSL_VERIFYPEER CURLOPT_SSL_VERIFYHOST
They're both set to off right now and I'd like to turn them both back on. Tested with a small php script that turning them on doesn't interfere with retrieving data.
Can I get a couple +1's?
+1 from me.
-Mike
+1
IIRC we needed this at the time of deployment (was it before the wildcard?), but it certainly seems to not be an issue now.
- Nigel ----- "Toshio Kuratomi" a.badger@gmail.com wrote:
Toshio Kuratomi wrote:
The Mediawiki auth plugin has to contact admin.fedoraproject.org in order to lookup the users and verify their passwords. It's using
curl
to do so. One of the options being given to curl is the following:
# This is only required because of the wildcard cert on pt10 curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
That turns off verifying the host via SSL. From the comment it
appears
to only be needed with the test FAS server. I'd like to comment
this
line out.
This is a flaw that potentially opens us to a DNS spoofing attack
to
compromise authentication. Luckily for us, there is a problem with routing to admin.fedoraproject.org within PHX so we have an
/etc/hosts
entry for admin.fp.o that directs the wiki to use an internal IP address. That means for this flaw to affect us, someone would have
to
compromise the /etc/hosts files rather than a DNS server. So we
should
fix this but compromising it is not as easy.
If this fails, we will see authentication failures when we try to
login
to the wiki and can revert.
After looking at this a little more with G, there's two settings to toggle:
CURLOPT_SSL_VERIFYPEER CURLOPT_SSL_VERIFYHOST
They're both set to off right now and I'd like to turn them both back on. Tested with a small php script that turning them on doesn't interfere with retrieving data.
Can I get a couple +1's?
-Toshio
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
infrastructure@lists.fedoraproject.org
-
Jeffrey Ollie -
Mike McGrath -
Nigel Jones -
Ricky Zhou -
Toshio Kuratomi