0000311: OpenVPN allows password authentication for users not associated with provided cert.

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000311

ClearOS

openvpn

public

2011-06-15 23:09

2012-03-03 13:31

Reporter

dloper

Assigned To

user2

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

duplicate

Platform

OS Version

Product Version

5.2-SP1

Target Version

Fixed in Version

Summary

0000311: OpenVPN allows password authentication for users not associated with provided cert.

Description

When logging into OpenVPN it is possible to use a certificate of a user but provide credentials of a different user. Example, bob can log into the server and has a laptop. John takes his laptop, even though john does not have permissions to use the openvpn he can authenticate using bob's certificate and his own username/password.

Even though the current system provides two factor authentication, those factors of authentication are not correlated. There does not seem to be a switch within OpenVPN that addresses this issue of correlation of credentials.

Additional Information

Workaround to follow and suggestions for implementation to system.

Tags

No tags attached.

Attached Files

Relationships

duplicate of

0000262

closed

Enforce common name information to match username on authentication

Notes
(0000360) dloper (administrator) 2011-06-15 23:19	The following changes adds a check to the system to validate the certificate and the user ID. Since ClearOS correlates the naming of both, we can use simple logic to overcome the issue. This is a workaround at the moment and there may be a better way to handle the issue that scales better. Change /etc/openvpn/clients.conf: #user nobody #group nobody script-security 2 management localhost 7505 client-connect /etc/openvpn/cert-validate.script This enables the localhost only management portal via telnet. We will use this to disconnect clients that are in violation of the rules. Please note that removing nobody causes an additional security concern in that a compromise of the OpenVPN daemon can result in privilege escalation. It is vital that moving forward OpenVPN and these associated scripts be assigned to a non-privileged but named user and group. /etc/openvpn/cert-validate.script: #!/bin/bash address=$trusted_ip':'$trusted_port if [ $username == $common_name ]; then exit 0 else /etc/openvpn/killopenvpnuser $address fi /etc/openvpn/killopenvpnuser: #!/usr/bin/expect set arg1 [lindex $argv 0] set timeout 10 spawn telnet localhost 7505 expect " for more info" send "kill $argv\n" expect "client(s) killed" send "quit\n" Please note that only one user may be connected to the localhost management port at a time. If connected manually to the port then it will cause the user to be passed. This is likely the case as well if the client floods the server and is rejected with the first request but granted the second while the system purges the initial connection.

(0000361) dloper (administrator) 2011-06-15 23:19	http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,21/func,view/id,26266/ [^]

(0000362) user2 2011-06-16 05:13	See tracker 0000262

(0000363) dloper (administrator) 2011-06-16 08:01	The major logic bug here is that only one session of expect can be passed to the telnet session at a time so what happens if more that one instance comes. The answer is two fold...queue the disconnect requests, and two, stall the openvpn request indefinitely until disconnect. One thing I noticed is that the script (cert-validate.script) will keep the authentication request in limbo until it exits normally. This sort of solves the problem in itself in that it can pass expect script and wait for a positive outcome. If none is forthcoming it will continue to keep the client at bay with: "SENT CONTROL [server.clearos.lan]: 'PUSH_REQUEST' (status=1)". In fact, the client side will continue to produce these messages long after OpenVPN has denied the host. Additionally, a more scalable architecture may be to call a central script that spins off the cert-validate.script so that it can perform even more additional services. For example, it may want to set up specific firewall rules for this client.

Issue History
Date Modified	Username	Field	Change
2011-06-15 23:09	dloper	New Issue
2011-06-15 23:19	dloper	Note Added: 0000360
2011-06-15 23:19	dloper	Note Added: 0000361
2011-06-16 05:12	user2	Relationship added	duplicate of 0000262
2011-06-16 05:13	user2	Note Added: 0000362
2011-06-16 05:13	user2	Status	new => resolved
2011-06-16 05:13	user2	Resolution	open => duplicate
2011-06-16 05:13	user2	Assigned To	=> user2
2011-06-16 08:01	dloper	Note Added: 0000363
2012-03-03 13:30	user2	Status	resolved => closed

ClearOS Bug Tracker