New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

recaptcha fails #13500

Closed
Ressy66 opened this Issue Jul 18, 2017 · 14 comments

Comments

Projects
None yet
3 participants
@Ressy66

Ressy66 commented Jul 18, 2017

Steps to reproduce

1.update to current stable release
2. try login
3. presents click images, says OK your not a robot, but fails login for wrong captcha

Expected behaviour

correct captcha should allow login

Last working phpmyadmin version was 4.7.0
reverted to 4.7.0, logins now succeed again, so problem is in change between 4.7.0 and 4.7.1

Actual behaviour

says wrong captcha - see redacted screenshot

Server configuration

Operating system:
linux

Web server:
apache 2.4.7
Database:
mariadb 5

PHP version:
5.5.38
phpMyAdmin version:
current stable 4.7.2
snapshot676

@nijel

This comment has been minimized.

Show comment
Hide comment
@nijel

nijel Jul 18, 2017

Member

I've just tested it and it works fine for me with 4.7.2, are you sure there was not a mistake in Captcha solution?

Also there are no changes in the authentication code between 4.7.0 and 4.7.2...

Member

nijel commented Jul 18, 2017

I've just tested it and it works fine for me with 4.7.2, are you sure there was not a mistake in Captcha solution?

Also there are no changes in the authentication code between 4.7.0 and 4.7.2...

@nijel nijel self-assigned this Jul 18, 2017

@nijel nijel added the question label Jul 18, 2017

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Jul 19, 2017

No error, it happens on all accounts, including my own. (also if was actually wrong, surely the green tick would not appear)

what version of php?
The exact same config.inc.php works on 4.7.0, fails on 4.7.1 & .2
logs don't show anything.

Ressy66 commented Jul 19, 2017

No error, it happens on all accounts, including my own. (also if was actually wrong, surely the green tick would not appear)

what version of php?
The exact same config.inc.php works on 4.7.0, fails on 4.7.1 & .2
logs don't show anything.

@nijel

This comment has been minimized.

Show comment
Hide comment
@nijel

nijel Jul 21, 2017

Member

I've tested on PHP 5.6.26-1 and 7.0.20-2.

You can look yourself at changes between the releases, there is really nothing related to ReCaptcha integration, see RELEASE_4_7_0...RELEASE_4_7_1

Member

nijel commented Jul 21, 2017

I've tested on PHP 5.6.26-1 and 7.0.20-2.

You can look yourself at changes between the releases, there is really nothing related to ReCaptcha integration, see RELEASE_4_7_0...RELEASE_4_7_1

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Jul 22, 2017

" PHP 5.6.26-1 " -dash versions are not original source versions, they are hacked distro versions

Either way, those servers run 5.5.38, which runs fine on 4.7.0. So another change somewhere has inadvertently broken it as of 4.7.1

.... and before you say " upgrade php, there is a reason we have not, some clients code has proved to fail on 5.6.

Ressy66 commented Jul 22, 2017

" PHP 5.6.26-1 " -dash versions are not original source versions, they are hacked distro versions

Either way, those servers run 5.5.38, which runs fine on 4.7.0. So another change somewhere has inadvertently broken it as of 4.7.1

.... and before you say " upgrade php, there is a reason we have not, some clients code has proved to fail on 5.6.

@ibennetch

This comment has been minimized.

Show comment
Hide comment
@ibennetch

ibennetch Jul 23, 2017

Member

For what it's worth, I also tried with PHP 5.5.55-0+deb8u1 and it worked as expected.

Still, this is quite a strange combination of feedback to be shown.

Member

ibennetch commented Jul 23, 2017

For what it's worth, I also tried with PHP 5.5.55-0+deb8u1 and it worked as expected.

Still, this is quite a strange combination of feedback to be shown.

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Jul 24, 2017

Hrmm, only thing I see changed was a version prior, 4.6.6, about fopen for url, no changes since, doesnt explain why, if that was problem it didnt fall over then, I've ruled out suhosin in early days, so its not to blame, as suhosin controls the function restrictions.

only thing I didnt check was if that change somehow wants to access something outside openbase, I'v monitored the outgoing packets and its definately tlaking to google so pretty sure that wont be it, I'll try disabling that and see, just if nothing else but to entertain me ...

Ressy66 commented Jul 24, 2017

Hrmm, only thing I see changed was a version prior, 4.6.6, about fopen for url, no changes since, doesnt explain why, if that was problem it didnt fall over then, I've ruled out suhosin in early days, so its not to blame, as suhosin controls the function restrictions.

only thing I didnt check was if that change somehow wants to access something outside openbase, I'v monitored the outgoing packets and its definately tlaking to google so pretty sure that wont be it, I'll try disabling that and see, just if nothing else but to entertain me ...

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Jul 24, 2017

nope, you can eliminate all of those, disabled open_base and suhosin, still no go.
any openssl changes that might be related around that version?

Ressy66 commented Jul 24, 2017

nope, you can eliminate all of those, disabled open_base and suhosin, still no go.
any openssl changes that might be related around that version?

@nijel

This comment has been minimized.

Show comment
Hide comment
@nijel

nijel Aug 28, 2017

Member

No, there weren't any related changes between those releases.

Does it work for you with some of the recent releases or is it still broken?

Member

nijel commented Aug 28, 2017

No, there weren't any related changes between those releases.

Does it work for you with some of the recent releases or is it still broken?

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Aug 29, 2017

Nope, I have even tried just released 4.7.4 but still failed,
I have also noticed this on one other box, but for a weird reason, it fails after 4.6.6 as the last working version.

All other servers are stuck running 4.7.0 until I sort this out, or give up and revert back to apache having to protect phpmyadmin, which will only happen at this stage if there's a critical exploit found on the ones we're using. The object at present is to fix whats broken, somehow :)

Ressy66 commented Aug 29, 2017

Nope, I have even tried just released 4.7.4 but still failed,
I have also noticed this on one other box, but for a weird reason, it fails after 4.6.6 as the last working version.

All other servers are stuck running 4.7.0 until I sort this out, or give up and revert back to apache having to protect phpmyadmin, which will only happen at this stage if there's a critical exploit found on the ones we're using. The object at present is to fix whats broken, somehow :)

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Aug 29, 2017

OK.... something HAS changed in the way phpmyadmin sends to google
on the older working phpmyadmins it succeeds,
on the newer where it fails wireshark in reporting:

2404:6800:4006:807::2004 TLSv1 113 Alert (Level: Fatal, Description: Unknown CA)

Same box, same location, same everything, just different phpmyadmin versions
I have rerun this alternating between the good and fail versions several times now, checking the data, and always, the later ones fail and always with unknown CA, where earlier versions always pass, do not report this failure in the wireshark data dumps

Ressy66 commented Aug 29, 2017

OK.... something HAS changed in the way phpmyadmin sends to google
on the older working phpmyadmins it succeeds,
on the newer where it fails wireshark in reporting:

2404:6800:4006:807::2004 TLSv1 113 Alert (Level: Fatal, Description: Unknown CA)

Same box, same location, same everything, just different phpmyadmin versions
I have rerun this alternating between the good and fail versions several times now, checking the data, and always, the later ones fail and always with unknown CA, where earlier versions always pass, do not report this failure in the wireshark data dumps

@nijel

This comment has been minimized.

Show comment
Hide comment
@nijel

nijel Aug 29, 2017

Member

If it would be broken since 4.6.6 it might be caused by 05a2587 - we default to curl now, but it used to rely on allow_url_fopen in past. But this code was part of both 4.6.6 and 4.7.0...

Anyway it seems that some part of your PHP doesn't use system SSL certificates and verification thus fails.

There seems to be some reports similar on the recaptcha (eg. google/recaptcha#85), but I'm not really sure if the cause is same. In the end google/recaptcha#165 should be a solution to this kind of problems.

Member

nijel commented Aug 29, 2017

If it would be broken since 4.6.6 it might be caused by 05a2587 - we default to curl now, but it used to rely on allow_url_fopen in past. But this code was part of both 4.6.6 and 4.7.0...

Anyway it seems that some part of your PHP doesn't use system SSL certificates and verification thus fails.

There seems to be some reports similar on the recaptcha (eg. google/recaptcha#85), but I'm not really sure if the cause is same. In the end google/recaptcha#165 should be a solution to this kind of problems.

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Aug 29, 2017

I make partial revert, back to
if (! empty($_POST["g-recaptcha-response"])) {
//if (function_exists('curl_init')) {
//$reCaptcha = new ReCaptcha\ReCaptcha(
// $GLOBALS['cfg']['CaptchaLoginPrivateKey'],
// new ReCaptcha\RequestMethod\CurlPost()
// );
//} else if (ini_get('allow_url_fopen')) {
if (ini_get('allow_url_fopen')) {

and it now logs in! at least we know have pin pointed the exact culprit.
Thanks for your help, should get us through to next release at least where I'll need to be make same changes I guess, this is a Slackware system, this release seeks out CERTS not in /etc/ssl/certs so I gather thats the issue path, no idea, try symlink to it but still failed :)

Ressy66 commented Aug 29, 2017

I make partial revert, back to
if (! empty($_POST["g-recaptcha-response"])) {
//if (function_exists('curl_init')) {
//$reCaptcha = new ReCaptcha\ReCaptcha(
// $GLOBALS['cfg']['CaptchaLoginPrivateKey'],
// new ReCaptcha\RequestMethod\CurlPost()
// );
//} else if (ini_get('allow_url_fopen')) {
if (ini_get('allow_url_fopen')) {

and it now logs in! at least we know have pin pointed the exact culprit.
Thanks for your help, should get us through to next release at least where I'll need to be make same changes I guess, this is a Slackware system, this release seeks out CERTS not in /etc/ssl/certs so I gather thats the issue path, no idea, try symlink to it but still failed :)

@nijel

This comment has been minimized.

Show comment
Hide comment
@nijel

nijel Aug 29, 2017

Member

Okay, so the PHP curl extension on your system does not have access to system certs. Still I wonder why 4.7.0 worked for you as it has exactly same code :-).

Member

nijel commented Aug 29, 2017

Okay, so the PHP curl extension on your system does not have access to system certs. Still I wonder why 4.7.0 worked for you as it has exactly same code :-).

@Ressy66

This comment has been minimized.

Show comment
Hide comment
@Ressy66

Ressy66 Aug 29, 2017

very good question (as mentioned I've tried to other boxes, on 4.6.6's and all of them fail after that version, no-one is owning up to fudging something on the 4.7.0 box, I have migrated all 4 "test" cases to 4.7.4 with that mod, and will leave it go a couple of weeks before doing any others.

All servers are scheduled for a OS upgrade to slackware 14.2 this Christmas, so I might just leave it that til then :) Hopefully anyone else upgrading like in my case (I recall old Centos's never used that path) will find this in google and see the quick fix - make above change, or upgrade their OS ;)

Thanks again for help, I think we can close this issue now

Ressy66 commented Aug 29, 2017

very good question (as mentioned I've tried to other boxes, on 4.6.6's and all of them fail after that version, no-one is owning up to fudging something on the 4.7.0 box, I have migrated all 4 "test" cases to 4.7.4 with that mod, and will leave it go a couple of weeks before doing any others.

All servers are scheduled for a OS upgrade to slackware 14.2 this Christmas, so I might just leave it that til then :) Hopefully anyone else upgrading like in my case (I recall old Centos's never used that path) will find this in google and see the quick fix - make above change, or upgrade their OS ;)

Thanks again for help, I think we can close this issue now

@Ressy66 Ressy66 closed this Aug 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment