[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] OpenVPN software quality

  • Subject: Re: [Openvpn-users] OpenVPN software quality
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Sun, 5 Dec 2004 18:18:55 -0700 (MST)

On Mon, 6 Dec 2004 stefano@xxxxxxxxxxx wrote:

> Hi Mr Yonan,
>    first of all I would like to let you know that I really love your
> VPN product, that I follow since about one year. Great work!!!
> I have a simple question: since the time when I descovered your great
> software I was asking myself how much secure it was. Some search on the
> Net revealed zero security advisories related to OpenVPN. This seemed a
> bit strange to me! First I thought that the program was not widely used,
> so perhaps it would not have been properly exercised. Later I realized
> that actually OpenVPN exists since 2002 and it seems it is becoming more
> and more popular around the world...
> Needless to say that a large and complex (and growing) program has
> growing probability of containing defects, but it seems that this is not
> true for OpenVPN! We know that even large company products have been
> subject to some sort of security bug, which is a natural thing if we
> consider the design complexity involved in products that deal with
> security issues.
> So what I would like to know is: what kind of measueres do you take in
> order to have such a great result? Do you rely on testing? If so, which
> type? Perhaps do you apply some sort of formal methods in order to
> verify program correctness?
> Thank you again for your quality work!
> Stefano


I don't think anyone has a 100% reliable method of finding defects in C
code.  I try to be very careful, but no one can be perfect.  I think it's 
important to assume that eventually someone will find an exploit, and work
towards trying to contain it.  OpenVPN has the user/group/chroot options
which allows OpenVPN to run as user/group nobody, chrooted to an empty
directory owned by root.  So the idea is that even if someone figures out
an exploit, their execution environment is going to be very limited, and
it's going to be harder for them to install a standard root kit.

Having said that, of course I try to use programming practices that reduce
the chances of exploitable defects making it into the code.  Here are some
of my basic principles:

(1) Operations involving buffers should go through some kind of buffer 
class that will automatically check for buffer overflows.  In OpenVPN this 
is done by struct buffer and all of the member function found in 
(2) I try to limit the number of lines of code which an incoming network
packet will touch before it is authenticated.  Of course, these are the
lines of code which an attacker will probe for weakness.  If I can limit
these lines of code to 400 instead of 4000, then I can focus my efforts on
making sure that those 400 lines are clean -- much easier than trying to 
do that for 4000 lines.  This is the main idea behind the --tls-auth

(3) Litter the code with ASSERT statements and always keep them turned on 
for the actual release.

(4) Use a memory checker such as the amazing Valgrind tool to test for 
memory errors and references to uninitialized data.

(5) For one of your testing boxes, choose a system that is very different 
from the systems that most people are going to use to run your software, 
preferably one that's running old versions of development tools, and has 
non-x86 endianness.  I have access to an older Solaris box which finds 
bugs that Linux or Windows would never find.

(6) OpenVPN has the --gremlin option which can be used to simulate basic 
man-in-the-middle and DoS attacks, as well as simulate terrible network 
conditions with not only lots of dropped packets, but corrupted packets as 

(7) Be sceptical about programming practices which promise increased 
performance, but do it at the expense of stability or make your software 
more opaque to defect analysis.  Multithreading is a good example.  When I 
use it, I use it very cautiously, and I've gone out of my way to structure 
OpenVPN so that multithreading is not required.  Some might argue that the 
C language itself promotes programming practices which sacrifice stability 
for performance.  There's some truth to that, but I doubt anyone is going 
to leave the C/C++ world anytime soon for tasks such as programming OSes, 
device drivers, under-the-hood network software, and low-level crypto.  I 
think it's more likely that compile-time defect detection tools, like the 
Stanford code checker, will continue to improve, and this to a certain 
extent will help to bail out large C projects (such as operating systems) 
as these projects evolve and complexify.


Openvpn-users mailing list