Bug 458594 - openvpn_execve: external program may not be called due to setting of --script-security level
openvpn_execve: external program may not be called due to setting of --script...
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: openvpn (Show other bugs)
el5
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Steven Pritchard
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 458612
  Show dependency treegraph
 
Reported: 2008-08-10 13:04 EDT by Robert Scheck
Modified: 2009-11-11 12:21 EST (History)
6 users (show)

See Also:
Fixed In Version: 2.1-0.30.rc15.el4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-30 15:50:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2008-08-10 13:04:48 EDT
Description of problem:
I recently upgraded from openvpn-2.1-0.17.rc2.el5.1 (EPEL stable?) to the
latest openvpn-2.1-0.27.rc9.el5 (EPEL testing?) and now the OpenVPN server
seems to behave somehow odd/buggy/strange. From the log:

Aug 10 17:26:20 int-fw openvpn[19115]: TCPv4_SERVER link local (bound): [undef]:1194
Aug 10 17:26:20 int-fw openvpn[19115]: TCPv4_SERVER link remote: [undef]
Aug 10 17:26:20 int-fw openvpn[19115]: MULTI: multi_init called, r=256 v=256
Aug 10 17:26:20 int-fw openvpn[19115]: IFCONFIG POOL: base=10.252.0.4 size=62
Aug 10 17:26:21 int-fw openvpn[19115]: MULTI: TCP INIT maxclients=1024 maxevents=1028
Aug 10 17:26:21 int-fw openvpn[19115]: Initialization Sequence Completed
Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 openvpn_execve: external program may not be called due to setting of --script-security level
Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Verify command failed to execute: openssl verify -CAfile /etc/openvpn/PCAcert.pem 2 /C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=PRIVATE/OU=Certification_Authority/CN=Root_Certification_Authority/emailAddress=pca@localhost
Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Exiting

After this, the OpenVPN server instance is gone away. Restarting brings no
change into this.

Version-Release number of selected component (if applicable):
openvpn-2.1-0.27.rc9

How reproducible:
Everytime, see above.

Actual results:
Unusable OpenVPN daemon since last update.

Expected results:
Working OpenVPN daemon again even with latest update state.

Additional info:
It looks like this problem is described at Gentoo Bugzilla as well, because 
they've the same: http://bugs.gentoo.org/show_bug.cgi?id=233657 - if I see
it correct, setting script-security <n> should solve the problem. So can we
somehow set this as default somewhere? Because otherwise we'll kill and/or
hurt much of the existing default OpenVPN EPEL setups which we shouldn't do.
Comment 1 Robert Scheck 2008-08-10 13:13:59 EDT
See also: http://bugs.gentoo.org/show_bug.cgi?id=234254

When now looking into it, I think we should set "--script-security 2" as the 
default in the OpenVPN initscript for EPEL 4, 5 and whereever you also updated
the OpenVPN package _except_ Rawhide. For Rawhide we can break the stuff, so
that the users can get the new behaviour e.g. for EPEL 6 and Fedora 10. But for
the existing branches, please introduce no incompatible/breaking changes. And
as this popped up the first time on Sunday, I'm really pissed by the change...

As far as I understand, we can set "--script-security 2" in the initscript,
but users/admins can overwrite this by using e.g. "script-security 0" in their
openvpn.conf configuration file, right? So if we set the default, we behave
backward compatible and users/admins can use the new feature/extension?!

Luckily the Gentoo guys had the problem before, because otherwise Google just
tells *nothing* about such a crappy problem. Steven, what do you think about
my suggestion?
Comment 2 Robert Scheck 2008-08-10 13:37:25 EDT
Or maybe even a better idea, see the following diff of my braindump:

--- /etc/init.d/openvpn       2008-08-01 19:10:41.000000000 +0200
+++ /etc/init.d/openvpn.rsc   2008-08-10 19:34:35.000000000 +0200
@@ -153,7 +153,11 @@
                . $bn.sh
            fi
            rm -f $piddir/$bn.pid
-           $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work
+           # Handle backward compatibility, see Red Hat Bugzilla ID #458594
+           if [ `grep -c ^script-security $c` -eq 0 ]; then
+               script_security="--script-security 2"
+           fi
+           $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work $script_security
            if [ $? = 0 ]; then
                successes=1
            else

Let us add --script-security 2, if a grep for "script-security" at the beginning 
of the line of the OpenVPN configuration file was unsucessful. Of course this
only has to be done on the affected branches, so everywhere you updated OpenVPN
except Rawhide, I would say. This is maybe even more elegant rather the previous
suggestion as it doesn't cause an overwrite which could confuse admins and users
easily. What do you think?
Comment 3 Robert Scheck 2008-08-10 15:26:21 EDT
Okay, there are now two problems for me with the latest OpenVPN you pushed
into EPEL:

 1. Automagic "--script-security 3" in initscript passing to openvpn once
    the configuration is not mentioning ^script-security.
 2. tls-verify "openssl verify -CAfile /etc/openvpn/PCAcert.pem" doesn't
    work any longer

The first problem we've to follow here. And IMPORTANT: I think, we need
"--script-security 3" to have perfect backward compatibility; otherwise I
saw some things failing here. For the second problem, I'm going to open
another bug report now.
Comment 4 Jan Lieskovsky 2008-08-11 08:25:53 EDT
Hello Robert,

> Okay, there are now two problems for me with the latest OpenVPN you pushed
> into EPEL:
> 
> 1. Automagic "--script-security 3" in initscript passing to openvpn once
>    the configuration is not mentioning ^script-security.
> 2. tls-verify "openssl verify -CAfile /etc/openvpn/PCAcert.pem" doesn't
>    work any longer
>

Could you please specify in more detail what means "doesn't work any longer"?
It is:

a, the certificate verification as a service is not working any more
   (is broken)?

b, the certificate got invalid between upgrading between versions of the
   openvpn package (due miss to update some part in the certificate DN part)?

If a, is the case appearing here, it could be a potential security issue.

> The first problem we've to follow here. And IMPORTANT: I think, we need
> "--script-security 3" to have perfect backward compatibility; otherwise I
> saw some things failing here. For the second problem, I'm going to open
> another bug report now.

Have you already reported the new bug for the second issue?

Jan
Comment 5 Tomas Hoger 2008-08-13 12:58:19 EDT
Comment #4 was previously mistakenly marked as private...

Robert, can you please give more details about what you mean by:

 2. tls-verify "openssl verify -CAfile /etc/openvpn/PCAcert.pem" doesn't
    work any longer

Is some invalid certificate getting accepted, or then OpenVPN tries to run this external command, it blows up?

Thank you!
Comment 6 Robert Scheck 2008-08-13 14:41:13 EDT
Jan and Tomas: I've opened up bug #458600 for the second issue, once I got
that I've got two issues. Bug #458612 (marked as blocks in this bug report)
is the tracker bug and pointing to both of them. I'll move the bug #458600
parts to there.
Comment 7 Steven Pritchard 2008-08-13 15:08:20 EDT
(In reply to comment #2)
> +           # Handle backward compatibility, see Red Hat Bugzilla ID #458594
> +           if [ `grep -c ^script-security $c` -eq 0 ]; then
> +               script_security="--script-security 2"
> +           fi
> +           $openvpn --daemon --writepid $piddir/$bn.pid --config $c --cd $work
> $script_security

OK, I did that almost verbatim in rawhide.

> Of course this only has to be done on the affected branches, so everywhere
> you updated OpenVPN except Rawhide, I would say.

I'm inclined to leave it that way even in rawhide, at least until all of our documentation and samples are updated.
Comment 8 Steven Pritchard 2008-08-13 15:11:44 EDT
Oh, and for an even more elegant solution, I'm thinking of adding an /etc/sysconfig/openvpn where we can set the default for script-security system-wide.  (Maybe default it to 3 on EPEL and 2 on Fedora for now.)

That will take a little more code though.  In the mean time, this gets us working well enough to push a security update, I think...
Comment 9 Jan Lieskovsky 2008-08-25 04:59:37 EDT
For better understanding, wanted to check if there are really two
issues present(from comment#0):

Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 openvpn_execve: external
program may not be called due to setting of --script-security level
Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Verify command failed to
execute: openssl verify -CAfile /etc/openvpn/PCAcert.pem 2
/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=PRIVATE/OU=Certification_Authority/CN=Root_Certification_Authority/emailAddress=pca@localhost
Aug 10 17:26:22 int-fw openvpn[19082]: x.y.z.a:1194 Exiting

Isn't the second error message (unable to verificate the digital certificate)
caused only by the inability of openvpn to call external system command
/usr/bin/openssl verify CA-file -- only consequence of improper setting
of the security level (security level not allowing executing of external 
system commands) by openvpn at the startup)? So adding "--script-security 3"
to the openvpn initscript would set up the proper security level and would
ensure proper function of the certificate validation process?
Comment 10 Robert Scheck 2008-08-25 05:25:33 EDT
Jan, I already HAVE "--script-security 3" as parameter set. And using the 
"script-security 3" command in the *.conf doesn't change anything as well.
Maybe the script-security parameter itself is broken, that's possible as
well. I am not sure, whether this is maybe case, that's hard to test. But
as far as I can see, the script-security parameter seems to work, because
I've got another message, when script-security 0 or 1 is set.
Comment 11 Eric Work 2008-11-29 22:19:44 EST
This problem doesn't appear to be fixed.  An upgrade to rc10 or higher is needed.  The problem is, when a script has an argument it doesn't execute.

Example:

up "./script.sh up"
down "./script.sh down"

Even with --script-security 3 it will not work.  See the ubuntu bug for info.

https://bugs.launchpad.net/debian/+source/openvpn/+bug/277447
Comment 12 Fedora Update System 2008-11-30 09:44:47 EST
openvpn-2.1-0.29.rc15.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/openvpn-2.1-0.29.rc15.fc10
Comment 13 Fedora Update System 2008-11-30 09:44:51 EST
openvpn-2.1-0.29.rc15.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/openvpn-2.1-0.29.rc15.fc9
Comment 14 Fedora Update System 2008-11-30 09:44:54 EST
openvpn-2.1-0.29.rc15.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/openvpn-2.1-0.29.rc15.fc8
Comment 15 Robert Scheck 2008-11-30 09:51:07 EST
Eric, I've bumped Fedora and EPEL testing to rc15 in order to solve this
issue, as the Fedora package maintainer seems to be some kind of AWOL or
at least not interested to work on this. Please test accordingly and let
me know what's up with rc15. I'm also using OpenVPN at work and will have
a look to this there regarding my other issues, which I mostly now worked
around.
Comment 16 Eric Work 2008-11-30 15:50:02 EST
Robert, I downloaded your build from Koji and it appears my script problems have been fixed.  I'm going to go ahead and close this bug, Thanks!
Comment 17 Fedora Update System 2008-12-21 03:18:24 EST
openvpn-2.1-0.29.rc15.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2008-12-21 03:21:31 EST
openvpn-2.1-0.29.rc15.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Fedora Update System 2008-12-21 03:33:14 EST
openvpn-2.1-0.29.rc15.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Dale Bewley 2009-10-23 22:55:07 EDT
There is a problem with the patch in comment #2. The $script_security variable is not initialized in the loop, so if your server3.conf contains 'script-security 3 system' it will be overridden by '--script-security 2' on the command line.

Fix.

[root@rebar init.d]# rpm -q openvpn
openvpn-2.1-0.32.rc15.fc11.x86_64

[root@rebar init.d]# diff -u openvpn.orig openvpn
--- openvpn.orig	2009-10-23 19:54:06.095386158 -0700
+++ openvpn	2009-10-23 19:54:21.713387134 -0700
@@ -154,6 +154,7 @@
 	    fi
 	    rm -f $piddir/$bn.pid
             # Handle backward compatibility, see Red Hat Bugzilla ID #458594
+            script_security=''
             if [ -z "$( grep '^[[:space:]]*script-security[[:space:]]' $c )" ]; then
                 script_security="--script-security 2"
             fi
Comment 21 Fedora Update System 2009-10-25 07:29:12 EDT
openvpn-2.1-0.30.rc15.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/openvpn-2.1-0.30.rc15.el4
Comment 22 Fedora Update System 2009-10-25 07:29:30 EDT
openvpn-2.1-0.30.rc15.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/openvpn-2.1-0.30.rc15.el5
Comment 23 Fedora Update System 2009-11-11 12:20:41 EST
openvpn-2.1-0.30.rc15.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Fedora Update System 2009-11-11 12:20:56 EST
openvpn-2.1-0.30.rc15.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.