CVE-2016-2049 about php-openid HOT 6 CLOSED

copy of what I have sent on the oss list:

So from what I understand, this issue is only related to the sample
code in php-openid, correct?

You also report that this code is in "use verbatim" in "the vast
majority of sites", yet looking at the Debian code base, the only
samples of that code I could find are in php-openid itself and the SAML
library:

https://codesearch.debian.net/search?perpkg=1&q=getTrustRoot

(jglobus seems to be a false positive there)

I have reviewed the usage of the openid.realm field in the Debian source
code and, in general, it doesn't seem to use the Host: header:

https://codesearch.debian.net/search?perpkg=1&q=openid.realm

Furthermore, I am not sure the attack works even on the theoritical
level: how would the user reach the proper website if the Host header is
changed?

i have marked debian as not vulnerable to this, but it is true the sample code here should be updated to use a better openid.realm.

from php-openid.

So from what I understand, this issue is only related to the sample
code in php-openid, correct?

Yes.

You also report that this code is in "use verbatim" in "the vast
majority of sites", yet looking at the Debian code base, the only
samples of that code I could find are in php-openid itself and the SAML
library:

Nathaniel and I made this report after finding this specific exploit in a valuable service. I haven't yet asked for permission to publish what this service is. This server ran Apache and used php-openid in the default configuration.

I did some research via google, finding a couple of servers that followed the same pattern. I talked to some friends who run php-openid services and I could find only a few who both used php-openid and didn't base their configuration off the example. From this sample, I made the assumption that most were using the example as a base for their configurations.

I have reviewed the usage of the openid.realm field in the Debian source code and, in general, it doesn't seem to use the Host: header:

I'm not sure what this has to do with Debian? I posted on oss-security because this is an open source piece of software. Additionally, this bug is not the openid.realm header being directly compared to the Host header, it's that the realm it is compared to is, in the example derived from $SERVER['SERVER_NAME'].

from php-openid.

On 2016-02-05 15:50:19, Zemnmez wrote:

You also report that this code is in "use verbatim" in "the vast
majority of sites", yet looking at the Debian code base, the only
samples of that code I could find are in php-openid itself and the SAML
library:

Nathaniel and I made this report after finding this specific exploit in a valuable service. I haven't yet asked for permission to publish what this service is. This server ran Apache and used php-openid in the default configuration.

It would be good to have more information on that.

I did some research via google, finding a couple of servers that followed the same pattern. I talked to some friends who run php-openid services and I could find only a few who both used php-openid and didn't base their configuration off the example. From this sample, I made the assumption that most were using the example as a base for their configurations.

If you know of other software that do the same mistake, it would be good
to identify them and contact their authors directly.

I have reviewed the usage of the openid.realm field in the Debian source code and, in general, it doesn't seem to use the Host: header:

I'm not sure why this has to do with Debian?

Well, I am doing triage work for the security team there, to try to
figure out which packages actually need to be updated, if any, in
Debian.

I posted on oss-security because this is an open source piece of
software.

That seems perfectly appropriate.

Additionally, this bug is not the openid.realm header being directly
compared to the Host header, it's that the realm it is compared to
is, in the example derived from $SERVER['SERVER_NAME'].

... which is derived from the Host header. Or did I misunderstand?

A.

Every one of us is, in the cosmic perspective, precious. If a human
disagrees with you, let him live. In a hundred billion galaxies, you
will not find another. - Carl Sagan

from php-openid.

also, so you have patches or suggestions for fixes?

from php-openid.

If you know of other software that do the same mistake, it would be good
to identify them and contact their authors directly.

This is my first time reporting an issue in an open source piece of software I haven't contacted the vendor directly to resolve, I'm not sure what the best way to go about finding and helping these people is.

... which is derived from the Host header. Or did I misunderstand?

No, this is correct. Somehow I missed the latter part of your comment. Honestly, I'm not sure. I assume the HTTP service I was testing this against did not enforce a 'correct' host header, and instead was serving the php files to any origin (that's a flawed configuration because of DNS rebinding anyway...).

also, so you have patches or suggestions for fixes?

One of the people I talked to was worried initially then said that since the library they had used has asked them specifically not to use SERVER_NAME, they hadn't. https://code.google.com/archive/p/lightopenid/

I think a good approach might be to strongly instruct users not to use $SERVER['SERVER_NAME'], and die or throw an error if (1) $SERVER['SERVER_NAME'] is being used and (2) the request is not from localhost. I'm not sure how easy that is to do.

from php-openid.

On 2016-02-05 16:11:23, Zemnmez wrote:

If you know of other software that do the same mistake, it would be good
to identify them and contact their authors directly.
This is my first time reporting an issue in an open source piece of software I haven't contacted the vendor directly to resolve, I'm not sure what the best way to go about finding and helping these people is.

You're doing a great job at it. :) Providing ways to reproduce the issue
is also good.

In general, it is considered good practice to contact the maintainers
privately at first and give them some time to respond, which varies,
according to the responsiveness of the upstream and the seriousness of
the vulnerability. A general rule of thumb is to wait 24h to a
week. Contacting security teams of related projects (e.g., in this case,
Drupal, Wordpress...) is also a good idea.

... which is derived from the Host header. Or did I misunderstand?
No, this is correct. Somehow I missed the latter part of your comment. Honestly, I'm not sure. I assume the HTTP service I was testing this against did not enforce a 'correct' host header, and instead was serving the php files to any origin (that's a flawed configuration because of DNS rebinding anyway...).

It's possible! If there's only one virtual host on the machine, this
works fine...

also, so you have patches or suggestions for fixes?
One of the people I talked to was worried initially then said that since the library they had used has asked them specifically not to use SERVER_NAME, they hadn't. https://code.google.com/archive/p/lightopenid/

I think a good approach might be to strongly instruct users not to use $SERVER['SERVER_NAME'], and die or throw an error if (1) $SERVER['SERVER_NAME'] is being used and (2) the request is not from localhost. I'm not sure how easy that is to do.

thanks for the suggestions.

a.

Conformity-the natural instinct to passively yield to that vague something
recognized as authority.
- Mark Twain

from php-openid.