Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi Sylvain, hi all, On Thu, 7 Nov, 2019, 3:19 PM Sylvain Beucler, wrote: > Hi, > > On 06/11/2019 21:14, Utkarsh Gupta wrote: > > On 06/11/19 11:47 am, Brian May wrote: > >> Utkarsh Gupta writes: > >> > >>> I am not quite sure about what should we do here because the update > (DLA > >>> 1956-1) doesn't quite fix the CVE completely and also brings some login > >>> problems as reported in #125. > >>> Because for now, #121 + #126 = actual CVE fix. But the login problem > >>> remains. > >> I guess we have three options: > >> > >> 1. Do nothing. > >> 2. Revert the #121 patch, because it could break. I haven't seen any > >> complaints however... > > Whilst that is true, I'd rather not want someone to face an "unexpected > > response" error. > > Though I hope no one is using that feature yet :) > > > >> 3. Apply the #126 patch too. Not 100% convinced this is a justified > >> change for LTS, but it "looks right". > >> 4. Wait longer for possible upstream solution to #125. > >> > >> Any opinions? > > I'd be a +1 on the 2nd and/or the 4th option. And a +0.5 on the 3rd. > Do the package maintainers have an opinion on this? > This can help. > I recently fixed (by fixing, I mean importing the CVE fix, not the problem it causes) this in unstable and I'm one of the package maintainers now :) Raphael, given that this package is low popcon and the vulnerability is > fuzzy, do you know if the sponsor for this package would be willing to > test fixes? > Given Raphael's last mail, I'm not sure if it could *really* be tested. What makes sense now is to wait for the upstream fix *until* someone who uses this library grumbles :) Best, Utkarsh >
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi, (Sylvain, please cc me if you want me to read something in any timely fashion) On Thu, 07 Nov 2019, Sylvain Beucler wrote: > Raphael, given that this package is low popcon and the vulnerability is > fuzzy, do you know if the sponsor for this package would be willing to > test fixes? The sponsor is a web hoster who is listing packages used by all their customers. I doubt that they can easily test. I'm bccing them in case they want to chip in and express their interest in testing fixes. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi, On 06/11/2019 21:14, Utkarsh Gupta wrote: > On 06/11/19 11:47 am, Brian May wrote: >> Utkarsh Gupta writes: >> >>> I am not quite sure about what should we do here because the update (DLA >>> 1956-1) doesn't quite fix the CVE completely and also brings some login >>> problems as reported in #125. >>> Because for now, #121 + #126 = actual CVE fix. But the login problem >>> remains. >> I guess we have three options: >> >> 1. Do nothing. >> 2. Revert the #121 patch, because it could break. I haven't seen any >> complaints however... > Whilst that is true, I'd rather not want someone to face an "unexpected > response" error. > Though I hope no one is using that feature yet :) > >> 3. Apply the #126 patch too. Not 100% convinced this is a justified >> change for LTS, but it "looks right". >> 4. Wait longer for possible upstream solution to #125. >> >> Any opinions? > I'd be a +1 on the 2nd and/or the 4th option. And a +0.5 on the 3rd. Do the package maintainers have an opinion on this? This can help. Raphael, given that this package is low popcon and the vulnerability is fuzzy, do you know if the sponsor for this package would be willing to test fixes? Cheers! Sylvain
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hiya, On 06/11/19 11:47 am, Brian May wrote: > Utkarsh Gupta writes: > >> I am not quite sure about what should we do here because the update (DLA >> 1956-1) doesn't quite fix the CVE completely and also brings some login >> problems as reported in #125. >> Because for now, #121 + #126 = actual CVE fix. But the login problem >> remains. > I guess we have three options: > > 1. Do nothing. > 2. Revert the #121 patch, because it could break. I haven't seen any > complaints however... Whilst that is true, I'd rather not want someone to face an "unexpected response" error. Though I hope no one is using that feature yet :) > 3. Apply the #126 patch too. Not 100% convinced this is a justified > change for LTS, but it "looks right". > 4. Wait longer for possible upstream solution to #125. > > Any opinions? I'd be a +1 on the 2nd and/or the 4th option. And a +0.5 on the 3rd. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Utkarsh Gupta writes: > I am not quite sure about what should we do here because the update (DLA > 1956-1) doesn't quite fix the CVE completely and also brings some login > problems as reported in #125. > Because for now, #121 + #126 = actual CVE fix. But the login problem > remains. I guess we have three options: 1. Do nothing. 2. Revert the #121 patch, because it could break. I haven't seen any complaints however... 3. Apply the #126 patch too. Not 100% convinced this is a justified change for LTS, but it "looks right". 4. Wait longer for possible upstream solution to #125. Any opinions? -- Brian May
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi Brian, On 11/10/19 5:02 pm, Utkarsh Gupta wrote: > On 10/10/19 11:23 am, Brian May wrote: >> Utkarsh Gupta writes: >> >>> Just a quick question about this patch since I haven't really tested >>> this at all (however aware of the CVE), >>> Is checking signature before sending a request to openid.claimed_id URL >>> strict enough? >> Yes, that is my understanding. If the signature is checked, that makes >> it impossible for a third party to change the claimed_id URL, rendering >> the attack impossible. >> >> I don't claim to be an expert on this however. > I had a few pointers, but since this is already uploaded, I'll raise > this in upstream first and then get back if needed. > Thank you for taking care of this. The patch that was taken from one of the PRs[1] to fix CVE-2019-11027 didn't seem to fix the CVE completely. That said, I raised this upstream and sent a one-liner patch[2] that was merged (which should actually fix the CVE!). This is also released as v2.9.2 (kinda happy about it) :) However, the previous PR (#121) leads to an issue[3] that hasn't been quite fixed; making the library kinda unusable (at least the login part of it). I am not quite sure about what should we do here because the update (DLA 1956-1) doesn't quite fix the CVE completely and also brings some login problems as reported in #125. Because for now, #121 + #126 = actual CVE fix. But the login problem remains. Any pointers? Best, Utkarsh --- [1]: https://github.com/openid/ruby-openid/pull/121 [2]: https://github.com/openid/ruby-openid/pull/126 [3]: https://github.com/openid/ruby-openid/issues/125 signature.asc Description: OpenPGP digital signature
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
On 10/10/19 11:23 am, Brian May wrote: > Utkarsh Gupta writes: > >> Just a quick question about this patch since I haven't really tested >> this at all (however aware of the CVE), >> Is checking signature before sending a request to openid.claimed_id URL >> strict enough? > Yes, that is my understanding. If the signature is checked, that makes > it impossible for a third party to change the claimed_id URL, rendering > the attack impossible. > > I don't claim to be an expert on this however. I had a few pointers, but since this is already uploaded, I'll raise this in upstream first and then get back if needed. Thank you for taking care of this. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Utkarsh Gupta writes: > Just a quick question about this patch since I haven't really tested > this at all (however aware of the CVE), > Is checking signature before sending a request to openid.claimed_id URL > strict enough? Yes, that is my understanding. If the signature is checked, that makes it impossible for a third party to change the claimed_id URL, rendering the attack impossible. I don't claim to be an expert on this however. -- Brian May
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi Brian, On 09/10/19 11:52 am, Brian May wrote: > My current understanding based on discussions in > https://github.com/openid/ruby-openid/issues/122 is that the following > patch should entirely fix this problem in ruby-openid. > > The discussion seems to be highly confused, and at times the reporter > seems to reject this as being insufficient, but without providing a any > real details. > > As this patch from upstream applied cleanly to Jessie, I imagine it will > apply equally as easily to the other distributions. > https://github.com/openid/ruby-openid/pull/121 > > > diff -Nru ruby-openid-2.5.0debian/debian/changelog > ruby-openid-2.5.0debian/debian/changelog > --- ruby-openid-2.5.0debian/debian/changelog 2014-03-15 02:04:12.0 > +1100 > +++ ruby-openid-2.5.0debian/debian/changelog 2019-10-09 17:00:00.0 > +1100 > @@ -1,3 +1,11 @@ > +ruby-openid (2.5.0debian-1+deb8u1) jessie-security; urgency=high > + > + * Non-maintainer upload by the LTS Team. > + * CVE-2019-11027 Avoid SSRF for claimed_id request. > +Patch source: https://github.com/openid/ruby-openid/pull/121 > + > + -- Brian May Wed, 09 Oct 2019 17:00:00 +1100 > + > ruby-openid (2.5.0debian-1) unstable; urgency=medium > >* Imported Upstream version 2.5.0debian > diff -Nru ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch > ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch > --- ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch > 1970-01-01 10:00:00.0 +1000 > +++ ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch > 2019-10-09 17:00:00.0 +1100 > @@ -0,0 +1,30 @@ > +From 8a4c31a6740a949cdc29d956c276ba3c4021dfa8 Mon Sep 17 00:00:00 2001 > +From: Vadim Shaulski > +Date: Tue, 16 Apr 2019 19:34:35 +0300 > +Subject: [PATCH] Avoid SSRF for claimed_id request > + > +`verify_discovery_results` sends a request to openid.claimed_id URL. > +Anybody can change claimed_id URL but request still will be sent. > +For example, sending a request to the internal network or localhost: > +https://myserver/callback?_method=post_id=http://localhost:3000/do_method. > + > +I think, we must check signature before use any data from the URL > +--- > + lib/openid/consumer/idres.rb | 2 +- > + 1 file changed, 1 insertion(+), 1 deletion(-) > + > +diff --git a/lib/openid/consumer/idres.rb b/lib/openid/consumer/idres.rb > +index 16c1d80..6c4e0a3 100644 > +--- a/lib/openid/consumer/idres.rb > b/lib/openid/consumer/idres.rb > +@@ -72,9 +72,9 @@ def signed_fields > + def id_res > + check_for_fields > + verify_return_to > +-verify_discovery_results > + check_signature > + check_nonce > ++verify_discovery_results > + end > + > + def server_url > diff -Nru ruby-openid-2.5.0debian/debian/patches/series > ruby-openid-2.5.0debian/debian/patches/series > --- ruby-openid-2.5.0debian/debian/patches/series 1970-01-01 > 10:00:00.0 +1000 > +++ ruby-openid-2.5.0debian/debian/patches/series 2019-10-09 > 17:00:00.0 +1100 > @@ -0,0 +1 @@ > +CVE-2019-11027.patch Just a quick question about this patch since I haven't really tested this at all (however aware of the CVE), Is checking signature before sending a request to openid.claimed_id URL strict enough? Whilst another option that seems doable is to disable Yardis discovery but it might reduce functionalities that others need and also, I don't really like disabling things if we can fix them the right way :) So if it is strict enough to check the signature before *actually* sending a request to URL (to avoid SSRFs), then it should probably be good to go! :D Best, Utkarsh signature.asc Description: OpenPGP digital signature
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
My current understanding based on discussions in https://github.com/openid/ruby-openid/issues/122 is that the following patch should entirely fix this problem in ruby-openid. The discussion seems to be highly confused, and at times the reporter seems to reject this as being insufficient, but without providing a any real details. As this patch from upstream applied cleanly to Jessie, I imagine it will apply equally as easily to the other distributions. https://github.com/openid/ruby-openid/pull/121 diff -Nru ruby-openid-2.5.0debian/debian/changelog ruby-openid-2.5.0debian/debian/changelog --- ruby-openid-2.5.0debian/debian/changelog2014-03-15 02:04:12.0 +1100 +++ ruby-openid-2.5.0debian/debian/changelog2019-10-09 17:00:00.0 +1100 @@ -1,3 +1,11 @@ +ruby-openid (2.5.0debian-1+deb8u1) jessie-security; urgency=high + + * Non-maintainer upload by the LTS Team. + * CVE-2019-11027 Avoid SSRF for claimed_id request. +Patch source: https://github.com/openid/ruby-openid/pull/121 + + -- Brian May Wed, 09 Oct 2019 17:00:00 +1100 + ruby-openid (2.5.0debian-1) unstable; urgency=medium * Imported Upstream version 2.5.0debian diff -Nru ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch --- ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch 1970-01-01 10:00:00.0 +1000 +++ ruby-openid-2.5.0debian/debian/patches/CVE-2019-11027.patch 2019-10-09 17:00:00.0 +1100 @@ -0,0 +1,30 @@ +From 8a4c31a6740a949cdc29d956c276ba3c4021dfa8 Mon Sep 17 00:00:00 2001 +From: Vadim Shaulski +Date: Tue, 16 Apr 2019 19:34:35 +0300 +Subject: [PATCH] Avoid SSRF for claimed_id request + +`verify_discovery_results` sends a request to openid.claimed_id URL. +Anybody can change claimed_id URL but request still will be sent. +For example, sending a request to the internal network or localhost: +https://myserver/callback?_method=post_id=http://localhost:3000/do_method. + +I think, we must check signature before use any data from the URL +--- + lib/openid/consumer/idres.rb | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/lib/openid/consumer/idres.rb b/lib/openid/consumer/idres.rb +index 16c1d80..6c4e0a3 100644 +--- a/lib/openid/consumer/idres.rb b/lib/openid/consumer/idres.rb +@@ -72,9 +72,9 @@ def signed_fields + def id_res + check_for_fields + verify_return_to +-verify_discovery_results + check_signature + check_nonce ++verify_discovery_results + end + + def server_url diff -Nru ruby-openid-2.5.0debian/debian/patches/series ruby-openid-2.5.0debian/debian/patches/series --- ruby-openid-2.5.0debian/debian/patches/series 1970-01-01 10:00:00.0 +1000 +++ ruby-openid-2.5.0debian/debian/patches/series 2019-10-09 17:00:00.0 +1100 @@ -0,0 +1 @@ +CVE-2019-11027.patch -- Brian May
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi I think we should consider to mark this package unsupported. // Ola On Tue, 13 Aug 2019 at 00:20, Brian May wrote: > Hello, > > Looking at some security issues, e.g. ruby-openid, CVE-2019-11027, the > security issues orignate from problems with the standard. Which likely > means that all implementations are vulnerable. > > As LTS developers, I don't think there is anything we can do with these > issues, because we cannot break the known standard in a LTS release just > to fix a security issue, as this would break applications that use this > library. > > I don't yet fully understand this security vulnerability, however the > researcher has recommended that detailed error messages be replaced by > generic errors. While this doesn't solve the security issue, it makes it > a little bit harder to exploit. So I guess this is something we could > do. Although I am unclear how we should mark this change up in the > security tracker... > > There are also some recommendations for application developers. However > I don't see any applications in Debian/Jessie that depend on > ruby-openid. So I don't think we can do anything with these > recommendations. > > Presumably that means anybody who who needs this library, has installed > it for locally installed applications. I see "find-work" has given > ruby-openid a score of 2.35% > > It is also worth noting that there are other potential security issues > with this library, e.g. see > https://github.com/openid/ruby-openid/issues/98 > > Regards > -- > Brian May > > -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Security issues in standards (ruby-openid / CVE-2019-11027)
Hello, Looking at some security issues, e.g. ruby-openid, CVE-2019-11027, the security issues orignate from problems with the standard. Which likely means that all implementations are vulnerable. As LTS developers, I don't think there is anything we can do with these issues, because we cannot break the known standard in a LTS release just to fix a security issue, as this would break applications that use this library. I don't yet fully understand this security vulnerability, however the researcher has recommended that detailed error messages be replaced by generic errors. While this doesn't solve the security issue, it makes it a little bit harder to exploit. So I guess this is something we could do. Although I am unclear how we should mark this change up in the security tracker... There are also some recommendations for application developers. However I don't see any applications in Debian/Jessie that depend on ruby-openid. So I don't think we can do anything with these recommendations. Presumably that means anybody who who needs this library, has installed it for locally installed applications. I see "find-work" has given ruby-openid a score of 2.35% It is also worth noting that there are other potential security issues with this library, e.g. see https://github.com/openid/ruby-openid/issues/98 Regards -- Brian May
