Skip to content
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

Receiving perl execution failed - Your password has expired (at /usr/share/webmin/password_change.cgi line 12) #947

Closed
luizfschrickte opened this issue Jul 25, 2018 · 14 comments

Comments

@luizfschrickte
Copy link

commented Jul 25, 2018

Hi,

After a webmin update to 1.890 I can't use the chage 0 command on linux to force a user to change its password anymore because when logging on webmin it receives the message:

Perl execution failed - Your password has expired [...] at /usr/share/webmin/password_change.cgi

Looking at the file, apparently webmin is denying the expired password... because the password is expired!

The most weird part is that the password_change.cgi file in the 1.890 tgz file is different from the file in the git 1.890 tag! And exactly line 12 has changed... From the GIT repository info, this file was theoretically changed last time only in 2014!

The problematic line 12 is:
$in{'expired'} eq '' || die $text{'password_expired'},qx/$in{'expired'}/;

Which was, in 1.860 version AND currently is on the github master and 1.890 tag sources:
$miniserv{'passwd_mode'} == 2 || die "Password changing is not enabled!";

So, may I correct this manually or am I doing something wrong? Why is this code in the deb file and not in the GIT sources.. am I looking in the wrong place?

Thank you very much!
Luiz Fernando

@jcameron

This comment has been minimized.

Copy link
Collaborator

commented Jul 26, 2018

You're right, there was a local edit to that file on my packaging system which was incorrect. Putting back the contents from the repo should fix the problem.

@jcameron jcameron closed this Jul 26, 2018

@SaulGoodman1337

This comment has been minimized.

Copy link

commented Aug 20, 2019

You're right, there was a local edit to that file on my packaging system which was incorrect. Putting back the contents from the repo should fix the problem.

Good job @jcameron ... really good job... I am excited

@rostovtsev

This comment has been minimized.

Copy link
Collaborator

commented Aug 20, 2019

@SaulGoodman1337 It wasn't intentional in any way! We over looked it. This file was maliciously modified. We don't create back-doors in our software on purpose! Besides, it's unclear why this kind of exploit, so obvious, open, and affecting so little installs, as only very few systems have password reset on, because by default, we have this feature set to off.

@SaulGoodman1337

This comment has been minimized.

Copy link

commented Aug 20, 2019

I am well aware that you are not deliberately spreading malicious code. However, I am absolutely surprised with how much operational blindness you overlooked this bug report.

Please do your homework better in the future. In this case, this is simply not acceptable for a software that intervenes as deeply in the system as Webmin does.

@wiserweb

This comment has been minimized.

Copy link

commented Aug 20, 2019

Hi @SaulGoodman1337 you need to relax. It's your assumption that it was operational blindness. It's also not necessary to make the whole world aware of your victimhood mentality but you seem to have no issue with it.

If you ever get close to creating something the magnitude of Virtualmin or Webmin then, only, maybe, then, your opinion might be taken seriously.

As a long time customer and contributor to both Webmin and Virtualmin I KNOW 100% that the team is top notch.

Good luck with life.

@SaulGoodman1337

This comment has been minimized.

Copy link

commented Aug 20, 2019

Ahhh beautiful.
The people who have to become directly personal out of nothing. They are my favorite :)

@Neustradamus

This comment has been minimized.

Copy link

commented Aug 22, 2019

@jcameron, @rostovtsev, @swelljoe, @webmin, @usermin, @virtualmin: Time to take little minutes for have a perfect github for Virtualmin products?

@jcameron

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2019

Looking back, I made a big mistake in ignoring this ticket - at the time I assumed it was just a stupid copy/paste error I made in password_change.cgi and never checked it. Only much later was it pointed out that the qx operator in Perl actually executes code :-(

@c4td0g8

This comment has been minimized.

Copy link

commented Aug 22, 2019

But now why u offical website still direct download page to sourceforge.net?

http://www.webmin.com/download.html >> https://sourceforge.net/projects/webadmin/files/ (which contain executes code backdoor )

@art-lucas

This comment has been minimized.

Copy link

commented Aug 22, 2019

Where should the latest version be downloaded from, from GitHub?

@jcameron

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2019

Version 1.930 on sourceforge and linked from http://www.webmin.com/download.html is safe.

I am intentionally keeping older versions around in case anyone wants to analyze them.

@swelljoe

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2019

It's worth noting that no release on github has ever been exploitable via this mechanism, including the versions that were exploitable from SourceForge, since the code on github never had these bugs. But, for running it i production, you'd want to use yum or apt, so it's easy to update.

@luizfschrickte

This comment has been minimized.

Copy link
Author

commented Aug 22, 2019

Sad that I didn't realize the potential problem of this issue before :'(

Is the build infrastructure safe or is it safer to keep using GitHub versions from now on?

Thank you

@swelljoe

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2019

I always recommend running the version from apt or yum repositories.

This issue aside, running a current version is the most important thing to do with regard to security (for any software, not just Webmin). We'll work on reproducible and verifiable builds for the future, and the 1930 release was built from a fresh git checkout on new infrastructure (and hand-checked for this issue). That was a rushed affair, since we didn't have any early disclosure of the issue before it was in the wild, but we'll spend more time on the problem for the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.