Possible Security Bug: Client Override

[jimp]

That is a little odd, but the real problem is that you are mixing security levels on the same VPN.

If you need to securely isolate someone, they should not be on the same VPN with anyone else with higher access. Setup a second VPN with a completely different CA structure, TLS key, tunnel network, etc, and then firewall it off that way.

Using ccd-excluside can help, as kpa said, but then you must define an override for every user.

Alternately, use the reverse tactic. Give users with access to more things special override settings to do that, and let the default be the insecure settings. I wouldn't do that, though, I'd still go for the second VPN for restricted access.

[mario_b]

Well, no i have over 40 Users and every user have different access levels … i couldn't be the solution creating for every User a own VPN.

Passing the space at the end of the Username is still a bug, and only that bug is causing that Problem.

@kpa: Nice idea - will try that Workaround tomorrow. Thanks.

[Pippin]

A file called "DEFAULT" with "disable" on one line in OpenVPN`s ccd directory as a workaround ?

See "–client-config-dir dir" and "--disable" in manul 2.4:
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Also, first report this on OpenVPN forum ?
https://forums.openvpn.net
and/or the mailing list:
https://sourceforge.net/projects/openvpn/lists/openvpn-users

[mario_b]

Morning,

so i restarted this morning the OpenVPN with "ccd-exclusive" under custom Options. And yes that solves the Security Issue.

@jimp: As i have many different users access, i have an Override per every user. That's why i said i am not mixing levels - the Security Issue without ccd-exclusive is, that you can gain access of other users with that "space" trick.

I have yesterday also send a complete Security Exploit Description to pfSense Security Team.

Thanks all for the help.

Regards Mario

[jimp]

I just tried this myself and putting a space after the username fails authentication with local users and RADIUS users, but can be accepted by an LDAP server.

Are you using an external authentication server? Your problem may be there, not with pfSense.

Apr 6 08:43:33 	openvpn 		user 'jimp ' could not authenticate.
Apr 6 08:43:33 	openvpn 	28014 	172.21.32.35 WARNING: Failed running command (--auth-user-pass-verify): external program exited with error status: 1
Apr 6 08:43:33 	openvpn 	28014 	172.21.32.35 TLS Auth Error: Auth Username/Password verification failed for peer 

I also verified the space was passed all the way through the authentication process. Nothing in our code strips it away that I can see.

I see other similar complaints about LDAP servers and trailing spaces in filters around the Internet, but at least the references I can find lead back to it being a fact of life with how LDAP handles filters.

I have tried numerous ways of escaping the space in the LDAP filter but each time the LDAP server ignores the trailing space when matching the user. The encoding was working properly because I was also testing a user with a space in the middle of the username and that worked when the space was encoded, but the trailing space was also allowed.

I opened https://redmine.pfsense.org/issues/8439 to track it, but as far as I can tell so far it's the fault of LDAP server filter processing.

You might want to lobby to OpenVPN and see if maybe they can add an option to strip extraneous whitespace from usernames, since it has to happen in OpenVPN for it to be caught early enough to matter.

[jimp]

One more thing I thought of. If you use user certificates as well as user authentication, you could enable the option to enforce a match between the username and certificate common name.

[maverick_slo]

Ummm I use Ms ad server 2012r2 ldap and adding space to end of username fails auth…

[jimp]

Make sure you are trying that twice in a row, if you auth, then reconnect with another username, the server will always reject you as changing names.

I didn't have an AD structure handy to test against but I did have OpenLDAP, and it ignores the trailing space as OP describes.

[maverick_slo]

It fails every time.
I can`t login with my username if it has trailing space.

[jimp]

It's entirely possible that AD does the right thing and OpenLDAP-based systems fail that test.

Strengthens the case that it's not a pfSense issue, but a problem on the authentication server.