Sent from ProtonMail Mobile
On Thu, Jun 15, 2017 at 8:00 PM, <openvpn-devel-requ...@lists.sourceforge.net>
wrote: Send Openvpn-devel mailing list submissions to
openvpn-devel@lists.sourceforge.net To subscribe or unsubscribe via the World
Wide Web, visit https://lists.sourceforge.net/lists/listinfo/openvpn-devel or,
via email, send a message with subject or body 'help' to
openvpn-devel-requ...@lists.sourceforge.net You can reach the person managing
the list at openvpn-devel-ow...@lists.sourceforge.net When replying, please
edit your Subject line so it is more specific than "Re: Contents of
Openvpn-devel digest..." Today's Topics: 1. Re: Bug or Feature? Username in
environment in auth-user-pass-verify (Steven Haigh) 2. Re: Bug or Feature?
Username in environment in auth-user-pass-verify (David Sommerseth) 3. Re: Bug
or Feature? Username in environment in auth-user-pass-verify (Antonio
Quartulli) 4. Re: W10 Client assigns old AND new IPv6 address to TAP with
GUI+Service but not with cmd prompt (debbie10t)
---------------------------------------------------------------------- Message:
1 Date: Fri, 16 Jun 2017 02:11:48 +1000 From: Steven Haigh To:
openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] Bug or
Feature? Username in environment in auth-user-pass-verify Message-ID:
<1649446.b7buzjz...@dhcp-10-1-1-119.lan.crc.id.au> Content-Type: text/plain;
charset="utf-8" On Thursday, 15 June 2017 5:47:39 PM AEST Gert Doering wrote: >
Hi, > > On Thu, Jun 15, 2017 at 12:50:40PM +1000, Steven Haigh wrote: > > I'm
just trying to figure out if its expected behaviour to have the > > 'username'
set in the environment when using the auth-user-pass-verify > > script. > > The
code in question (ssl_verify.c) is older than the involvement of > any of the
currently-active developers... but JJK or Ecrist might know. > > Anyway, what
the code *says* is: > > ssl_verify.c, about line 1095: > >
verify_user_pass_script(...) > { > ... > /* Set environmental variables prior
to calling script */ > if (session->opt->auth_user_pass_verify_script_via_file)
> { > ... (no setenv here) > } > else > { > setenv_str(session->opt->es,
"username", up->username); > setenv_str(session->opt->es, "password",
up->password); > } > > > so, yes, that is what it *does* - "username" is only
ever set together > with "password", and that's only setenv'ed if you do not
use "via-file". > > Now, that is about calling the --verify-auth-user-pass, but
I think the > "es" (environment set) being affected here is the global
per-connection > es (not something local to this function), so that would
affect > --client-connect as well. > > [..] > > > The auth-user-pass-verify
documentation states: > > If method is set to "via-env", OpenVPN will call
script with the > > environmental variables username and password set to the >
> username/password strings provided by the client. Be aware that this > >
method is insecure on some platforms which make the environment of a > >
process publicly visible to other unprivileged processes. > > This "some
platforms" actually something we should eventually verify > and clearly
spell-out - because Linux and all recent BSDs do *not* show > the environment
to other unprivileged users. > > [..] > > > No mention of the username env
variable when using via-file - but this > > gives me the impression that the
username should *not* be set in the > > environment - but it should be in the
file. > > > > So - bug or feature? > > Username and Password are always handled
in tandem when talking about > --auth-user-pass-verify, so "both in
environment" or "none of them". > > Now, if you use a *plugin* (or the
management interface), the code will > always set both in the es, and delete
the password(!) afterwards, leaving > the username intact... > > > Looking from
a given distance, I'd say that this is a bug, and "username" > should propably
be always visible in the es (if present), while password > should not. > > > If
you want to experiment: go to ssl_verify.c, and move the line 1123 > (master)
outside the else {} block: > > old: > > else > { > setenv_str(session->opt->es,
"username", up->username); > setenv_str(session->opt->es, "password",
up->password); > } > > new: > > else > { > setenv_str(session->opt->es,
"password", up->password); > } > setenv_str(session->opt->es, "username",
up->username); > > ... then it should show up in client-connect as well. I
managed to track this down today. It seems the pam plugin sets the environment
variable. As such, as soon as I add the following line to the server config,
the username variable appears back in the environment for
auth-user-pass-verify: plugin
/usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn After commenting
this line out and restarting the daemon, the username env variable is gone.
That still poses the question, is a plugin supposed to be able to alter the
environment presented to the auth-user-pass-verify script? If so, should these
changes also be in the client-connect script? If not, the environment might
need a reset before the auth-user-pass-verify script is called? -- Steven Haigh
? net...@crc.id.au ? http://www.crc.id.au ? +61 (3) 9001 6090 ? 0412 935 897
-------------- next part -------------- A non-text attachment was scrubbed...
Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This
is a digitally signed message part. ------------------------------ Message: 2
Date: Fri, 16 Jun 2017 00:01:03 +0200 From: David Sommerseth To: Steven Haigh
, openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] Bug or
Feature? Username in environment in auth-user-pass-verify Message-ID:
<9e766589-ac6e-e418-1b07-41a2889e0...@sf.lists.topphemmelig.net> Content-Type:
text/plain; charset="utf-8" On 15/06/17 18:11, Steven Haigh wrote: > On
Thursday, 15 June 2017 5:47:39 PM AEST Gert Doering wrote: >> Hi, >> >> On Thu,
Jun 15, 2017 at 12:50:40PM +1000, Steven Haigh wrote: [...snip...] >> >> old:
>> >> else >> { >> setenv_str(session->opt->es, "username", up->username); >>
setenv_str(session->opt->es, "password", up->password); >> } >> >> new: >> >>
else >> { >> setenv_str(session->opt->es, "password", up->password); >> } >>
setenv_str(session->opt->es, "username", up->username); >> >> ... then it
should show up in client-connect as well. > > I managed to track this down
today. > > It seems the pam plugin sets the environment variable. As such, as
soon as I > add the following line to the server config, the username variable
appears > back in the environment for auth-user-pass-verify: > plugin
/usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn Ouch. > After
commenting this line out and restarting the daemon, the username env > variable
is gone. > > That still poses the question, is a plugin supposed to be able to
alter the > environment presented to the auth-user-pass-verify script? You have
discovered something I've not been thinking of. But yes, plug-ins can actually
manage to do that if they manipulate the environment pointer provided to it.
All plug-ins runs within the same memory scope as the main OpenVPN process - in
fact, plug-ins is a way to extend the features of the core OpenVPN process.
That said ... this needs to be changed, I think it makes sense to take some
action to reduce this possibility. By manipulating pointers provided to you via
the the plug-in interface, you can make the OpenVPN process crash and burn ...
and it is fairly easily. If you manage to modify memory regions too much so
other OpenVPN data structures gets corrupted, it will explode in interesting
ways. > If so, should these changes also be in the client-connect script? That
should not be possible. There exist no direct API to modify the environment
variables from plug-ins, that is purely a side-effect if how the memory buffers
and pointers sent to plug-ins are handled. > If not, the environment might need
a reset before the auth-user-pass-verify > script is called? Either reset
(which I think is harder) or to copy the information into new fresh buffers
which are discarded once the plug-ins returns. -- kind regards, David
Sommerseth OpenVPN Technologies, Inc -------------- next part -------------- A
non-text attachment was scrubbed... Name: signature.asc Type:
application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature
------------------------------ Message: 3 Date: Fri, 16 Jun 2017 07:19:44 +0800
From: Antonio Quartulli To: openvpn-devel@lists.sourceforge.net Cc: Steven
Haigh Subject: Re: [Openvpn-devel] Bug or Feature? Username in environment in
auth-user-pass-verify Message-ID:
<82761970-4d2b-4102-a33c-684829fa0...@unstable.cc> Content-Type: text/plain;
charset="us-ascii" > On 16 Jun 2017, at 06:01, David Sommerseth wrote: > That
said ... this needs to be changed, I think it makes sense to take > some action
to reduce this possibility. By manipulating pointers > provided to you via the
the plug-in interface, you can make the OpenVPN > process crash and burn ...
and it is fairly easily. If you manage to > modify memory regions too much so
other OpenVPN data structures gets > corrupted, it will explode in interesting
ways. What happens if a plugin crashes on its own because of a segfault (for
example)? I think the entire openvpn process will crash, right? If I am right,
this means that protecting openvpn private objects is not really going to save
the process from a possible horrible death. > >> If so, should these changes
also be in the client-connect script? > > That should not be possible. There
exist no direct API to modify the > environment variables from plug-ins, that
is purely a side-effect if how > the memory buffers and pointers sent to
plug-ins are handled. > >> If not, the environment might need a reset before
the auth-user-pass-verify >> script is called? > Either reset (which I think is
harder) or to copy the information into > new fresh buffers which are discarded
once the plug-ins returns. > I second this idea - sounds easy and protects the
openvpn env from changes. (assuming this is not done on a fast path, because a
full blown copy of the env might have perf issues). Cheers, -- Antonio
Quartulli -------------- next part -------------- A non-text attachment was
scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes
Desc: Message signed with OpenPGP ------------------------------ Message: 4
Date: Fri, 16 Jun 2017 00:59:55 +0100 From: debbie10t To:
openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] W10 Client
assigns old AND new IPv6 address to TAP with GUI+Service but not with cmd
prompt Message-ID: <1c726aa0-84eb-5956-1621-e0afef500...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed On 13/06/17 21:15, Selva
Nair wrote: > On Tue, Jun 13, 2017 at 3:37 PM, Gert Doering wrote: > >> On Tue,
Jun 13, 2017 at 03:33:35PM -0400, Selva Nair wrote: >>> Right :) But we could
probably do better using Set instead of Add while >>> the address is set using
the service. I'm not that familiar with ipapi, >> but >>> looks like
SetUnicastIpAddressEnrty instead of AddUnicastIpAddressEntry >>> may be the
right thing. >>> >>> The netsh command used when service is not in use does
correctly do a set >>> not add. >> >> Good point. Wouldn't solve the first
problem, but at least a subsequent >> run would "magically fix it", provided
the same tap interface is used >> (which, I think, is the case in the great
majority of windows >> installations) > > > Okay, I can say that the issue is
indeed the service effectively doing an > "add address" instead > of "set
address". Reproduced this without using an admin run: > > 1. Connect to server
1 using GUI/iservice > 2. Kill iservice using taskmanager or taskkill (do not
do sc stop > service-name.. as that will do a graceful stop) > 3. Start the
service again > 4. Disconnect from server 1 > At this point "netsh int ipv6
show addr" will show that v6 addres is > retained although the connection is
down > 4. connect to server 2 using GUI/iservice > > Now the adapter will have
two ipv6 addresses. > > On Tue, Jun 13, 2017 at 3:50 PM, Samuli Sepp?nen wrote:
> >> I encountered the issue with the Powershell test suite >>
(openvpn-windows-test) which ran through a bunch of t_client test >> configs
and forcibly killed the OpenVPN process at the end of each test. >> All ping6
tests except the first one would then fail, because adding a >> default IPv6
route failed as one existed already. > > > Probably the same issue. The real
culprit here is force-killing without > impunity. I'll be posting a PR to the
GUI that allows sending connect, > disconnect and exit commands to the running
GUI, so we could use that in > the script. That said using "set address" in the
service will mitigate this > to some extent -- looks easy to do a patch.. >
PEBKAC's aside .. +1 to 'set not add' ------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech
sites, Slashdot.org! http://sdm.link/slashdot ------------------------------
Subject: Digest Footer _______________________________________________
Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
------------------------------ End of Openvpn-devel Digest, Vol 133, Issue 27
********************************************** @openvpn.net> @greenie.muc.de>
@gmail.com> @sf.lists.topphemmelig.net> @crc.id.au>@unstable.cc> @crc.id.au>
@sf.lists.topphemmelig.net> @crc.id.au>------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
