Michael Southwell wrote:
Chris Snyder and I are writing a book entitled "Pro PHP Security" to be
published by Apress. We have written the following there: "The openSSL
functions tend to deal with resources, in-memory pointers to keys,
certificates, etc, rather than the actual values themselves; even on
export, you pass a variable to the function and the exported value is
returned by reference. Our inference is that the authors of the module
wished to limit the number of copies of these values in memory, both for
performance and security reasons." Can anyone verify whether this is
indeed the reason, or if not, explain what the reason is? Thanks very
much in advance.
The OpenSSL library is not anyhow different from almost any other C
based library, starting with libc (standard C library). The C paradigm
favors dealing with object references rather then objects themselves
because there is no easy way to pass mutable (say, via
copy-on-write technique) "shadows" of objects around from function to
function. (In PHP, you can pass an array down the function so
that function could modify a single member of the array and pass the
modified array further, without affecting the very original array
in the topmost caller).
Argument passing in C is always by value, but programmers prefer
to pass only simple scalar variables (int, char) or _memory pointers_
this way. The problem is that the passing by value is too literal:
when copy of a value is performed, the copies of pointees pointed to
by the members of that value aren't made.
For example, if you have a structure with dynamically allocated members,
you could pass this structure by value, but the resulting copy of the
original structure would have members pointing to the same memory
locations as the original members did. If you repoint value's member
into another location, this would be a change visible only to the
current function and its descendants. However, if you change the
contents of the indirect member of this structure, you'll end up
with a change visible to the caller of the current function.
However, the above statements are all applicable only to the OpenSSL
C library, but not to the PHP's "openssl module" you are talking about.
You say that
"Our inference is that the authors of the module wished to limit the
number of copies of these values in memory, both for performance and
security reasons."
Given that the PHP openssl module relies on OpenSSL functions
to perform its tasks, there are several mostly unrelated I wanted to
highlight.
1. Your question does not belong to the OpenSSL development list,
as it deals with issues generally related to PHP's _wrapper_ around
the OpenSSL library but not to the OpenSSL library per se.
2. Translating the de-facto "best practice" way of doing things
from one language directly to another may seem very unusual for the
target language. What we're talking about here is a particular
example of such translation.
3. The easiest way to introduce a C library into the PHP world is to
teach PHP to understand the exact inputs and outputs of that library's
API. If the PHP module does precisely that, the most trustworthy
explanation for that would be the ... ease of implementation. Not any
kind of security concern, not a memory usage related concerns, not any
performance concerns, but the most blatant ease of implementation is
the key factor to understand why a C library was imported into the
PHP space this way or another.
3.1 If one would want to create a PHP interface to OpenSSL which would
manipulate the objects instead of references, this person would need
to create a set of functions to convert the C structures into PHP's
objects and PHP objects back into these structures. This task is
very daunting for the OpenSSL library, because of the following
reasons:
a) The convertor functions would need to be able to carefully
traverse the whole OpenSSL structure/object trees in order
to convert each elementary field into PHP's representation,
and the static depth of most OpenSSL object trees is quite
significant. Doing this without any kind of automatic tools
which grok the C structures definitions and automatically
produce the conversion code is unfeasible.
b) There are no objects in OpenSSL with fixed structure,
so the PHP's openssl module would have to be heavily tied
to a particular OpenSSL version in order to maintain binary
interoperability.
4. Given the nature of the OpenSSL library (namely, to provide some
security support), the C-like approach of passing the pointers
around may be either viewed as a security-conscious decision
(i.e., do not pass private keys or user data around), or, at the
other hand, it as a very dangerous and unfortunate feature. It allows
any receiver of the OpenSSL's generated data to interfere with
the guts of it, which could possibly introduce irrevocable changes
to the memory managed by the OpenSSL library and lead to program's
crash. Consequently, all statements about security (or insecurity)
of any decisions related to pass-by-value or pass-by-reference should
be written extremely carefully, certainly not like "this was so
because of "security reasons", and better be dropped altogether.
So, I would rewrite the following phrase
"Our inference is that the authors of the module wished to limit the
number of copies of these values in memory, both for performance and
security reasons."
into something like that:
"Our inference is that the openssl module it is a simple hack
to allow PHP programmers to use the OpenSSL library written at
a lower level language not easily supporting some of the
features to which PHP users have become accustomed."
Or something like that.
--
Lev Walkin
[EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
