Our "monolithic" program (which runs in well under a meg including
the program and all memory it uses) is monitored for correct hash (an
algorithm we have to give a 21 byte hash total of files for which I
have never seen two different files with the same hash) from an
off-site program AND onsite cron processes. It also has calls within
itself to validate it has not been de-compiled and modified. It has
timing alerts that make using gdb/dbx with break points virtually
impossible. It is also tied to the serial number of the AIX box or
network card address on others. If even one byte does not match what
was sent, email alerts are sent, the program is removed (after
document user ids dates and times), the port is disabled, and so
forth. Nothing is impenetrable, but an ordinary patching is not
going to do the job.
Secondly, dynamic libraries if shared by say 10 programs could be
modified for some purpose OTHER than my program. They may be
debugging their software, and hence write a log file of data, not
realizing that they are logging my raw credit card data. My software
then becomes non-compliant due to the innocent actions of others. Or
their software may require a certain version that has a vulnerability
that I can't live with. And I don't want to have to monitor this.
Third, I certify my software with the static link. I know -- and the
PCI compliance auditors know -- that it is compliant. If I have no
control over dynamic libraries I have no way of KNOWING I am
compliant in that environment. Neither does the customer or the
auditor. Stray debug logging is, in fact, one of the primary causes
of non-PCI compliance.
Fourth, I use different compiler switches than the open source
(different thread choices, different one-char default behavior,
etc). How that works without a static link is an open question (and
there are many other issues).
The point of a static link is that ... it is static. You know what
your program will do and you know how it will behave and you have
tested, certified, and deployed in that manner. It is easy to
validate that it has not been harassed. The point of a dynamic link
is to allow O/S updates that fix perceived bugs/holes. In some
situations this may not be a good thing (like say in my stray debug
example). And usually not relevant. I might be using only one
particular encryption. The fixes might be for others. And ... as
usual with all software, sometimes fixes also have unintended consequences.
I still think that the highest security is achieved with a static
link. The easiest to keep current and updated is obviously the
dynamic link. So that balance should be what decides.
E
At 12:13 PM 10/30/2011, you wrote:
> There are taste issues on this -- but you may be happier with a
> static link. It will load a giga-blip faster too with static link,
> and you won't even notice :-) A lot will depend on what your
> software is and how much of it. We have thousands of customers. We
> do credit cards which requires certification and you cannot (should
> not) allow the customer to change "your" software by installing a
> dynamic library. In fact, what if they built themselves their own
> libraries that wrote the unencrypted text out to a file? Then they
> could steal credit card numbers. BAD BAD BAD. It is a security hole
> to allow dynamic libraries because you have no control on what is
> really there.
If the code is running at the customer site, you have no control over
it, whether it's static or dynamic linked. It might be a giga-blip
easier for your customer/attacker to patch a dll, put it's still
trivial to patch your monolithic program.
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
(928) 301-7537 Cell
Vertical Integrated Computer Systems, LLC
Metropolis Support, LLC
For Metropolis support and VICS MBA Support!!!! http://www.vicsmba.com
For pictures: http://www.vicsmba.com/ourpics/index.html
(You can see why we love this state :-) )
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
