auth-user-pass-verify Option
So how commonly used is the "auth-user-pass-verify" option used though? That would give us an idea as to whether this is a big deal or not.
OpenVPN open to pre-auth Bash Shellshock bug – researcher
The Shellshock Bash bug, the gift that just keeps on taking, could also sting OpenVPN users, according to researcher Fredrick Stromberg. Pre-authentication vectors affect communication through the popular and formerly secure VPN platform, he says. Shellshock affected the crucial and ubiquitous *nix component Bash up to and …
-
-
Wednesday 1st October 2014 06:47 GMT Anonymous Coward
Re: auth-user-pass-verify Option
I can see why a lot do, to bring a vpn tunnel up automatically unattended as openvpn by default doesnt support auth-user-pass in its config files.
I had to recompile openvpn on the box to support auth-user-pass though as someone had taken the auth-user-pass option out of the compiled in options for security to stop people discovering the shared secret if they read the config file.
Just patch bash. Its no longer a big deal then.
-
Wednesday 1st October 2014 10:51 GMT Voland's right hand
Re: auth-user-pass-verify Option
Not very.
The most common setup for OpenVPN is to use client certificates. I have been using it for ~ 10 years now. Out of those ~ 3-4 years were also to run VPN access for an SMB. I have never ever set it for passwords.
Even if I would have set it for passwords I would have given it a perl or python script to execute so it connects to something useful in terms of passwords f.e. LDAP/AD. In order to connect for that you need appropriate modules, etc and bash does not have them.
This is an interesting authenticated attack vector (if you have stolen certs or passwords). While bash for password verification is rare, you are quite likely to find it in places where openvpn invokes various scripts once connection has been established.
-
Wednesday 1st October 2014 18:25 GMT phil 27
Re: auth-user-pass-verify Option
Thousands of people who have bought a "privacy vpn" use passwords, because thats the only manageable way of tracking the userbase for some offshore vpn provider. And as you don't control the vpn server, you can't enforce authentication by certs. Which is why I had to patch my openvpn to put the option back in because I didn't want to have a shell script to handle credentials (well actually I put my shared secrets in a included file and made it 400 and owned by root but thats not directly related)
As above, meanwhile in the real world, yes quite likely.
-
-
-
-
Wednesday 1st October 2014 07:59 GMT Steven Raith
Re: My /bin/sh points to dash .....
The simple answer is Just Patch It Anyway -
sudo apt-get update
sudo apt-get install --only-upgrade bash
That way you're patched and it won't affect anything else.
As I mentioned elsewhere PATCH FUCKING EVERYTHING because if you don't know what on your system calls bash explicitly, and you don't know whether the package you have is exploitable, then you don't know if you're safe, period.
Remove it, or patch it, but don't just leave a package with a known remotely exploitable vulnerability sitting on the system - that's asking for trouble.
Steven R
-
Wednesday 1st October 2014 12:19 GMT Rob Carriere
Re: My /bin/sh points to dash .....
As Steven said, "patch anyway".
As an exercise in intellectual curiosity: You (and pretty much all other Linux users out there) are not vulnerable in any situation where a shell script is invoked without specifying the shell to execute it. In that case, you get the default shell, which is not bash.
However, it is also possible for the caller to explicitly specify bash as the shell to be used or for the script itself to use a shebang specifying bash. In many environments, doing either of those will get the dev in question hung, drawn and quartered, but still, such things do happen.
The only way to be certain it doesn't happen on your machine would be a complete audit of all code on there. That's probably not your plan, therefore the answer of "patch anyway".
-
-
Wednesday 1st October 2014 08:44 GMT m4r35n357
Yes, you are. No sensible distribution has used bash for anything but interactive shells for as long as I can remember. That's what bash is, sh/ash/dash + interactive features. Only an idiot would use it for batch (non-interactive) processing. This whole thing is just natural selection at work.
-
Wednesday 1st October 2014 14:58 GMT Jamie Jones
" Yes, you are. No sensible distribution has used bash for anything but interactive shells for as long as I can remember. That's what bash is, sh/ash/dash + interactive features. Only an idiot would use it for batch (non-interactive) processing. This whole thing is just natural selection at work."
Very much this.
From what I gather from the story, bash isn't a requirement of openvpn, it's just that some stupid scripts/system configurations use it.
You can hardly put the blame onto them.
That's like saying Openvpn is vulnerable on systems which use the password 'password'.
Even forgetting security, bash shouldn't be used in scripting because of portability and efficiency/bloat reasons.
Despite your somewhat provocative tone, it's shocking to see you get all these downvotes on a technical forum. No wonder software today is bloated, unportable security-less shit, and these days the Linux fanatics are just as bad and insular as they accused Microsoft of being.
-
Wednesday 1st October 2014 18:41 GMT phil 27
Maybe he's been downvoted because some people understand all the child process called by the "good" script have to be not running bash as the variables persist onto the child processes even if its ignored and not interpreted by the parent shell so you need to audit not only the parent but all its children, then its children's children ad nauseum, and people haven't had time to audit their entire distribution before nipping the shops for a sarnie at lunchtime instead of applying a yum/apt-get/emerge bash like is being recommended in multiple places.
Just patch it, its a one liner on linux, solaris its a bit of a shit because of the patch cluster issue if the box is behind on clusters due to "commercial pressures" and "development cycles" and whatever other guff has been trotted out as a cost saving excuse, but we'll get through it while all the hardcore solaris guys shout about what linuxifcation has done and this would never have happened back in 2.6 days and for embedded devices pester the snot out your vendors.
-
-
-
Wednesday 1st October 2014 13:22 GMT William Towle
Re: No Logo?
> needs to get itself a trendy logo like Heartbleed
Not that I approve, but I've seen at least two:
https://openclipart.org/image/800px/svg_to_png/202367/shellshock-bug.png (at http://51sec.blogspot.co.uk/2014/09/shellshock-bash-computer-bug-exploited.html)
http://www.symantec.com/connect/sites/default/files/users/user-2967561/shellshock-vulnerability-logo.png (at http://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability)
// thinks the first one could do with the ">" in the appropriate direction
-
-
Wednesday 1st October 2014 10:40 GMT Matt Hamilton
Not enabled by default
The auth-user-pass-verify option is not used by default. It is something you would need to configure. Not only that, but it has two different 'modes'. You can either pass the credentials via an environment variable, or via a temporary file. The docs have always indicated the security issues with these approaches. I'm not sure if the 'by temp file' way also sets environment variables to the shell anyway.
e.g. we use it to pass the username/password to a small python script to check the details against a RADIUS database. We use OpenBSD though, so it's a moot point anyway.
-Matt
-
Wednesday 1st October 2014 12:25 GMT Blacklight
I use OpenVPN and auth-user-pass-verify....
So read this and went "eep".
However I checked my script, and it's #!/bin/sh, so that's ok then (and bash has also been patched on my box).
But I'm also using client certs, tls-auth files, non-default ciper algorithms and of course the auth-user-pass-verify. But if you've managed to get my certs, tls file and password, I suspect that's the least of my worries :)
-
Wednesday 1st October 2014 21:33 GMT Anonymous Coward
I told them so...
A couple of years ago, and a bit before that as well. Specifically, I told OpenVPN that the use of environment variables to run executables on Windows was regarded as a security flaw, and how to avoid that. There wasn't any interest -- it kind of seemed like the idea of environment variables as a security flaw was alien.
Biting the hand that feeds IT
