|
|
|
|
@ -1,7 +1,7 @@
|
|
|
|
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
|
|
|
|
|
|
|
|
|
|
<!-- "Secure Programming for Linux and Unix HOWTO",
|
|
|
|
|
Copyright (C) 1999-2002 David A. Wheeler
|
|
|
|
|
Copyright (C) 1999-2003 David A. Wheeler
|
|
|
|
|
http://www.dwheeler.com/secure-programs -->
|
|
|
|
|
|
|
|
|
|
<!-- WARNING!!! This book is MUCH LARGER than the tiny little HOWTO's
|
|
|
|
|
@ -134,20 +134,21 @@ http://www.gocsi.com/press/20020407.html
|
|
|
|
|
<firstname>David</firstname> <othername role="mi">A.</othername><surname>Wheeler</surname>
|
|
|
|
|
</author>
|
|
|
|
|
<address><email>dwheeler@dwheeler.com</email></address>
|
|
|
|
|
<pubdate>v3.005, 30 December 2002</pubdate>
|
|
|
|
|
<edition>v3.005</edition>
|
|
|
|
|
<pubdate>v3.007, 16 February 2003</pubdate>
|
|
|
|
|
<edition>v3.007</edition>
|
|
|
|
|
<!-- FYI: The LDP claims they don't use the "edition" tag. -->
|
|
|
|
|
<copyright>
|
|
|
|
|
<year>1999</year>
|
|
|
|
|
<year>2000</year>
|
|
|
|
|
<year>2001</year>
|
|
|
|
|
<year>2002</year>
|
|
|
|
|
<year>2003</year>
|
|
|
|
|
<holder>David A. Wheeler</holder>
|
|
|
|
|
</copyright>
|
|
|
|
|
|
|
|
|
|
<legalnotice>
|
|
|
|
|
<para>
|
|
|
|
|
This book is Copyright (C) 1999-2002 David A. Wheeler.
|
|
|
|
|
This book is Copyright (C) 1999-2003 David A. Wheeler.
|
|
|
|
|
Permission is granted to copy, distribute and/or modify
|
|
|
|
|
this book under the terms of the GNU Free Documentation License (GFDL),
|
|
|
|
|
Version 1.1 or any later version published by the Free Software Foundation;
|
|
|
|
|
@ -168,8 +169,11 @@ guidelines for writing secure programs for Linux and Unix systems.
|
|
|
|
|
Such programs include application programs used as viewers of remote data,
|
|
|
|
|
web applications (including CGI scripts),
|
|
|
|
|
network servers, and setuid/setgid programs.
|
|
|
|
|
Specific guidelines for C, C++, Java, Perl, PHP, Python, TCL,
|
|
|
|
|
Specific guidelines for C, C++, Java, Perl, PHP, Python, Tcl,
|
|
|
|
|
and Ada95 are included.
|
|
|
|
|
For a current version of the book, see
|
|
|
|
|
<ulink url="http://www.dwheeler.com/secure-programs">
|
|
|
|
|
http://www.dwheeler.com/secure-programs</ulink>
|
|
|
|
|
</para>
|
|
|
|
|
</abstract>
|
|
|
|
|
|
|
|
|
|
@ -200,7 +204,7 @@ and Ada95 are included.
|
|
|
|
|
<keyword>Perl</keyword>
|
|
|
|
|
<keyword>PHP</keyword>
|
|
|
|
|
<keyword>Python</keyword>
|
|
|
|
|
<keyword>TCL</keyword>
|
|
|
|
|
<keyword>Tcl</keyword>
|
|
|
|
|
<keyword>Ada</keyword>
|
|
|
|
|
<keyword>Ada95</keyword>
|
|
|
|
|
</keywordset>
|
|
|
|
|
@ -237,7 +241,7 @@ These guidelines were developed as a survey of
|
|
|
|
|
(along with additional observations by the author),
|
|
|
|
|
reorganized into a set of larger principles.
|
|
|
|
|
This book includes specific guidance for a number of languages,
|
|
|
|
|
including C, C++, Java, Perl, PHP, Python, TCL, and Ada95.
|
|
|
|
|
including C, C++, Java, Perl, PHP, Python, Tcl, and Ada95.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -1044,8 +1048,12 @@ http://www.dwheeler.com/secure-programs</ulink>.
|
|
|
|
|
<title>View of Various Experts</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Here are a few quotes from people who have examined the topic.
|
|
|
|
|
Bruce Schneier argues that smart engineers should ``demand
|
|
|
|
|
First, let's exampine what security experts have to say.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Bruce Schneier is a well-known expert on computer security and cryptography.
|
|
|
|
|
He argues that smart engineers should ``demand
|
|
|
|
|
open source code for anything related to security'' [Schneier 1999],
|
|
|
|
|
and he also discusses some of the preconditions which must be met to make
|
|
|
|
|
open source software secure.
|
|
|
|
|
@ -1076,7 +1084,12 @@ to spot and fix, ``Not only because more people can look at it, but,
|
|
|
|
|
more importantly, because the model forces people to write more clear
|
|
|
|
|
code, and to adhere to standards. This in turn facilitates security review''
|
|
|
|
|
[Rijmen 2000].
|
|
|
|
|
Elias Levy (Aleph1) discusses some of the problems in making open source
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Elias Levy (Aleph1) is the former moderator of one of the most
|
|
|
|
|
popular security discussion groups - Bugtraq.
|
|
|
|
|
He discusses some of the problems in making open source
|
|
|
|
|
software secure in his article
|
|
|
|
|
<ulink url="http://www.securityfocus.com/commentary/19">"Is Open Source
|
|
|
|
|
Really More Secure than Closed?"</ulink>.
|
|
|
|
|
@ -1090,6 +1103,49 @@ than its closed source counterpart.
|
|
|
|
|
But make no mistake, simply being open source is no guarantee of security.
|
|
|
|
|
</para>
|
|
|
|
|
</blockquote>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Whitfield Diffie is the
|
|
|
|
|
co-inventor of public-key cryptography (the basis of all Internet security)
|
|
|
|
|
and chief security officer and senior staff engineer at Sun Microsystems.
|
|
|
|
|
In his 2003 article
|
|
|
|
|
<ulink url="http://zdnet.com.com/2100-1107-980938.html">
|
|
|
|
|
Risky business: Keeping security a secret</ulink>,
|
|
|
|
|
he argues that proprietary vendor's claims that their software
|
|
|
|
|
is more secure because it's secret is nonsense.
|
|
|
|
|
He identifies and then counters two main claims made by proprietary vendors:
|
|
|
|
|
(1) that release of code benefits attackers more than anyone else because
|
|
|
|
|
a lot of hostile eyes can also look at open-source code, and
|
|
|
|
|
that (2) a few expert eyes are better than several random ones.
|
|
|
|
|
He first notes that while giving programmers access to a piece of software
|
|
|
|
|
doesn't guarantee they will study it carefully,
|
|
|
|
|
there is a group of programmers who can be expected to care deeply:
|
|
|
|
|
Those who either use the software personally or work for an
|
|
|
|
|
enterprise that depends on it.
|
|
|
|
|
"In fact, auditing the programs on which an enterprise depends for
|
|
|
|
|
its own security is a natural function of the enterprise's own
|
|
|
|
|
information-security organization."
|
|
|
|
|
He then counters the second argument, noting that
|
|
|
|
|
"As for the notion that open source's usefulness to opponents
|
|
|
|
|
outweighs the advantages to users, that argument flies in
|
|
|
|
|
the face of one of the most important principles in security:
|
|
|
|
|
A secret that cannot be readily changed should be regarded as a vulnerability."
|
|
|
|
|
He closes noting that
|
|
|
|
|
<blockquote>
|
|
|
|
|
<para>
|
|
|
|
|
"It's simply unrealistic to depend on secrecy for security in
|
|
|
|
|
computer software.
|
|
|
|
|
You may be able to keep the exact workings of the program out of general
|
|
|
|
|
circulation, but can you prevent the code from being
|
|
|
|
|
reverse-engineered by serious opponents? Probably not."
|
|
|
|
|
</para>
|
|
|
|
|
</blockquote>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
John Viega's article
|
|
|
|
|
<ulink url="http://dev-opensourceit.earthweb.com/news/000526_security.html">"The Myth of Open Source Security"</ulink> also discusses
|
|
|
|
|
issues, and summarizes things this way:
|
|
|
|
|
@ -1103,8 +1159,12 @@ for and fix security holes -- can also lull people into a false
|
|
|
|
|
sense of security.
|
|
|
|
|
</para>
|
|
|
|
|
</blockquote>
|
|
|
|
|
<ulink url="http://www.linuxworld.com/linuxworld/lw-1998-11/lw-11-ramparts.html">Michael H. Warfield's "Musings on open source security"</ulink> is much
|
|
|
|
|
more positive about the impact of open source software on security.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
<ulink url="http://www.linuxworld.com/linuxworld/lw-1998-11/lw-11-ramparts.html">Michael H. Warfield's "Musings on open source security"</ulink> is
|
|
|
|
|
very positive about the impact of open source software on security.
|
|
|
|
|
In contrast,
|
|
|
|
|
Fred Schneider doesn't believe that open source helps security, saying
|
|
|
|
|
``there is no reason to believe that the many eyes inspecting (open)
|
|
|
|
|
source code would be successful in identifying bugs that allow
|
|
|
|
|
@ -1146,6 +1206,7 @@ metrics that can reflect security delivered to the customer.''
|
|
|
|
|
</para>
|
|
|
|
|
</blockquote>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Scott A. Hissam and Daniel Plakosh's
|
|
|
|
|
<ulink url="http://www.ics.uci.edu/~wscacchi/Papers/New/IEE_hissam.pdf">
|
|
|
|
|
@ -1167,6 +1228,9 @@ and attackers correctly surmised that a similar problem might be still be in
|
|
|
|
|
Windows (and it was).
|
|
|
|
|
Unless OSS/FS programs are forbidden, this kind of learning is difficult
|
|
|
|
|
to prevent.
|
|
|
|
|
Therefore, the existance of an OSS/FS program can reveal the vulnerabilities
|
|
|
|
|
of both the OSS/FS and proprietary program performing the same function -
|
|
|
|
|
but at in this example, the OSS/FS program was fixed first.
|
|
|
|
|
</para>
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
@ -3563,7 +3627,7 @@ harder to understand; hopefully the text in this section will help you
|
|
|
|
|
Note that, in some circumstances, software cannot be used unless it
|
|
|
|
|
has undergone a CC evaluation by an accredited laboratory.
|
|
|
|
|
This includes certain kinds of uses in the U.S. Department of Defense
|
|
|
|
|
(as specified by NSTISP Number 11, which requires that before some
|
|
|
|
|
(as specified by NSTISSP Number 11, which requires that before some
|
|
|
|
|
products can be used they must be evaluated or enter evaluation),
|
|
|
|
|
and in the future such a requirement may
|
|
|
|
|
also include some kinds of uses for software in the U.S. federal government.
|
|
|
|
|
@ -7568,9 +7632,10 @@ his or her protection goals.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
A good overview of various desing principles for security is available in
|
|
|
|
|
<ulink url="http://www.csl.sri.com/neumann/chats2.html">
|
|
|
|
|
Peter Neumann's CHATS Principles</ulink>
|
|
|
|
|
A good overview of various design principles for security is available in
|
|
|
|
|
Peter Neumann's
|
|
|
|
|
<ulink url="http://www.csl.sri.com/users/neumann/chats.html#4">
|
|
|
|
|
Principled Assuredly Trustworthy Composable Architectures</ulink>.
|
|
|
|
|
<!--
|
|
|
|
|
???: Add:
|
|
|
|
|
http://www.csl.sri.com/neumann/chats2.pdf
|
|
|
|
|
@ -7690,17 +7755,37 @@ then they might be able to gain control of a user who ran the game.
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
If creating a new group isn't sufficient, consider creating a
|
|
|
|
|
new pseudouser (really, a special role) to manage a set of resources.
|
|
|
|
|
new pseudouser (really, a special role) to manage a set of resources -
|
|
|
|
|
often a new pseudogroup (again, a special role) is also created just
|
|
|
|
|
to run a program.
|
|
|
|
|
Web servers typically do this; often web servers are set up with a special
|
|
|
|
|
user (``nobody'') so that they can be isolated from other users.
|
|
|
|
|
Indeed, web servers are instructive here: web servers typically need
|
|
|
|
|
root privileges to start up (so they can attach to port 80), but once
|
|
|
|
|
started they usually shed all their privileges and
|
|
|
|
|
run as the user ``nobody''.
|
|
|
|
|
Again, usually the pseudouser doesn't own the primary program it runs,
|
|
|
|
|
so breaking into the account doesn't allow for changing the program itself.
|
|
|
|
|
As a result, breaking into a running web server normally does not
|
|
|
|
|
automatically break the whole system's security.
|
|
|
|
|
started they usually shed all their privileges and run as the user ``nobody''.
|
|
|
|
|
However, don't use the ``nobody'' account (unless you're writing a
|
|
|
|
|
webserver); instead, create your own pseudouser or new group.
|
|
|
|
|
The purpose of this approach is to isolate different programs,
|
|
|
|
|
processes, and data from each other,
|
|
|
|
|
by exploiting the operating system's ability to keep users and groups separate.
|
|
|
|
|
If different programs shared the same account, then breaking into one program
|
|
|
|
|
would also grant privileges to the other.
|
|
|
|
|
Usually the pseudouser should not own the programs it runs;
|
|
|
|
|
that way, an attack who breaks into the account cannot change
|
|
|
|
|
the program it runs.
|
|
|
|
|
By isolating different parts of the system into running separate users
|
|
|
|
|
and groups, breaking one part will not necessarily break the
|
|
|
|
|
whole system's security.
|
|
|
|
|
<!--
|
|
|
|
|
Martijn Vernooij noted http://httpd.apache.org/docs/mod/core.html#user :
|
|
|
|
|
|
|
|
|
|
The user should have no privileges which result in it being able to
|
|
|
|
|
access files which are not intended to be visible to the outside world,
|
|
|
|
|
and similarly, the user should not be able to execute code which is not
|
|
|
|
|
meant for httpd requests. It is recommended that you set up a new user
|
|
|
|
|
and group specifically for running the server. Some admins use user nobody,
|
|
|
|
|
but this is not always possible or desirable.
|
|
|
|
|
-->
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -10131,6 +10216,14 @@ Mozilla/Netscape to implement this soon too.
|
|
|
|
|
You should set HttpOnly on for any cookie you send, unless you have
|
|
|
|
|
scripts that need the cookie, to counter certain kinds of cross-site
|
|
|
|
|
scripting (XSS) attacks.
|
|
|
|
|
However, the HttpOnly flag can be circumvented in a variety of ways,
|
|
|
|
|
so using as your primary defense is inappropriate.
|
|
|
|
|
Instead, it's a helpful secondary defense that may help save you in
|
|
|
|
|
case your application is written incorrectly.
|
|
|
|
|
<!-- See http://www.whitehatsec.com/news.html
|
|
|
|
|
http://www.extremetech.com/article2/0,3973,841047,00.asp
|
|
|
|
|
and the Bugtraq discussion, 23 Jan 2003.
|
|
|
|
|
-->
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -10287,14 +10380,14 @@ to remove just those characters:
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
|
<title>Encoding</title>
|
|
|
|
|
<title>Encoding (Quoting)</title>
|
|
|
|
|
<para>
|
|
|
|
|
An alternative to removing the special characters is to encode them
|
|
|
|
|
so that they don't have any special meaning.
|
|
|
|
|
This has several advantages over filtering the characters,
|
|
|
|
|
in particular, it prevents data loss.
|
|
|
|
|
If the data is "mangled" by the process from the user's point of view,
|
|
|
|
|
at least with encoding it's possible to reconstruct the
|
|
|
|
|
at least when the data is encoded it's possible to reconstruct the
|
|
|
|
|
data that was originally sent.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
@ -10312,10 +10405,40 @@ As noted above, although in theory '>' doesn't need to be quoted,
|
|
|
|
|
because some browsers act on it (and fill in a '<') it needs to be quoted.
|
|
|
|
|
There's a minor complexity with the double-quote character,
|
|
|
|
|
because '&quot;' only needs to be
|
|
|
|
|
used inside attributes, and some old browsers don't properly render it.
|
|
|
|
|
used inside attributes, and some extremely old browsers don't
|
|
|
|
|
properly render it.
|
|
|
|
|
If you can handle the additional complexity, you can try to encode '"'
|
|
|
|
|
only when you need to, but it's easier to simply encode it and ask
|
|
|
|
|
users to upgrade their browsers.
|
|
|
|
|
Few users will use such ancient browsers, and the double-quote character
|
|
|
|
|
encoding has been a standard for a long time.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Scripting languages may consider implementing specialized auto-quoting types,
|
|
|
|
|
the interesting approach developed in the web application framework
|
|
|
|
|
<ulink url="http://www.mems-exchange.org/software/quixote">Quixote</ulink>.
|
|
|
|
|
Quixote includes a "template" feature which allows easy mixing of HTML text
|
|
|
|
|
and Python code; text generated by a template is passed back to the web browser
|
|
|
|
|
as an HTML document.
|
|
|
|
|
As of version 0.6, Quixote has two kinds of text (instead of a single
|
|
|
|
|
kind as most such languages).
|
|
|
|
|
Anything which appears in a literal, quoted string is of type "htmltext,"
|
|
|
|
|
and it is assumed to be exactly as the programmer wanted it to be
|
|
|
|
|
(this is reasoble, since the programmer wrote it).
|
|
|
|
|
Anything which takes the form of an ordinary Python string, however,
|
|
|
|
|
is automatically quoted as the template is executed.
|
|
|
|
|
As a result, text from a database or other external source is
|
|
|
|
|
automatically quoted, and cannot be used for a cross-site scripting attack.
|
|
|
|
|
Thus, Quixote implements a safe default -
|
|
|
|
|
programmers no longer need to worry about quoting every bit of text
|
|
|
|
|
that passes through the application (bugs involving too much quoting
|
|
|
|
|
are less likely to be a security problem, and will be obvious in testing).
|
|
|
|
|
Quixote uses an open source software license, but because of its
|
|
|
|
|
venue identification it is probably GPL-incompatible, and is used by
|
|
|
|
|
organizations such as the
|
|
|
|
|
<ulink url="http://lwn.net">Linux Weekly News</ulink>.
|
|
|
|
|
<!-- See http://lwn.net/Articles/19552/ -->
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -10389,6 +10512,7 @@ the codes to UTF-8, and then encode it.
|
|
|
|
|
See <xref linkend="Validating-uris"> for more about validating URIs.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
|
|
</sect2>
|
|
|
|
|
@ -12185,12 +12309,17 @@ use correctly).
|
|
|
|
|
<para>
|
|
|
|
|
In Ada95, the Unbounded_String type is often more flexible than the
|
|
|
|
|
String type because it is automatically resized as necessary.
|
|
|
|
|
However, don't store especially sensitive values such as passwords
|
|
|
|
|
However, don't store especially sensitive secret values such as passwords
|
|
|
|
|
or secret keys in an Unbounded_String, since core dumps and page areas
|
|
|
|
|
might still hold them later.
|
|
|
|
|
Instead, use the String type for this data, lock it into memory
|
|
|
|
|
while it's used, and overwrite the data as
|
|
|
|
|
soon as possible with some constant value such as (others => ' ').
|
|
|
|
|
Use the Ada pragma Inspection_Point on the object holding the secret
|
|
|
|
|
after erasing the memory.
|
|
|
|
|
That way, you can be certain that
|
|
|
|
|
the object containing the secret will really be erased
|
|
|
|
|
(and that the the overwriting won't be optimized away).
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -12209,10 +12338,10 @@ various supports for full formal proof of the code if desired.
|
|
|
|
|
<ulink url="http://www.sparkada.com">See the SPARK website for more
|
|
|
|
|
information</ulink>.
|
|
|
|
|
To my knowledge, there are no OSS/FS SPARK tools.
|
|
|
|
|
SPARK doesn't permit use of the Unbounded_String type, but still,
|
|
|
|
|
if you're storing passwords and private keys you should lock them into memory
|
|
|
|
|
(if appropriate - SPARK is often used in environments where
|
|
|
|
|
paging does not occur) and overwrite them as soon as possible.
|
|
|
|
|
If you're storing passwords and private keys you should still
|
|
|
|
|
lock them into memory if appropriate
|
|
|
|
|
and overwrite them as soon as possible.
|
|
|
|
|
Note that SPARK is often used in environments where paging does not occur.
|
|
|
|
|
</para>
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
@ -12540,54 +12669,288 @@ Code obfuscation doesn't really hide the code from serious attackers.
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
<sect1 id="tcl">
|
|
|
|
|
<title>TCL</title>
|
|
|
|
|
<title>Tcl</title>
|
|
|
|
|
<para>
|
|
|
|
|
Tcl stands for ``tool command language'' and is pronounced ``tickle.''
|
|
|
|
|
TCL is divided into two parts: a language and a library.
|
|
|
|
|
The language is a simple text language, intended for issuing commands
|
|
|
|
|
Tcl is divided into two parts: a language and a library.
|
|
|
|
|
The language is a simple language, originally intended for issuing commands
|
|
|
|
|
to interactive programs and including basic programming capabilities.
|
|
|
|
|
The library can be embedded in application programs.
|
|
|
|
|
You can find more information about Tcl at sites such as the
|
|
|
|
|
<ulink url="http://www.tcl.tk/">Tcl.tk</ulink> and the
|
|
|
|
|
<ulink url="http://www.sco.com/Technology/tcl/Tcl.html">Tcl WWW Info</ulink>
|
|
|
|
|
web page and the comp.lang.tcl FAQ launch page at
|
|
|
|
|
<ulink url="http://www.tclfaq.wservice.com/tcl-faq">http://www.tclfaq.wservice.com/tcl-faq</ulink>.
|
|
|
|
|
My thanks go to Wojciech Kocjan for providing some of this detailed
|
|
|
|
|
information on using Tcl in secure applications.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
You can find more information about TCL at sites such as the
|
|
|
|
|
<ulink url="http://www.sco.com/Technology/tcl/Tcl.html">TCL WWW Info</ulink>
|
|
|
|
|
web page.
|
|
|
|
|
Probably of most interest are Safe-TCL (which creates a sandbox in TCL)
|
|
|
|
|
and Safe-TK (which implements a sandboxed portable GUI for Safe-TCL), as
|
|
|
|
|
well as the WebWiseTclTk Toolkit permits TCL packages to be automatically
|
|
|
|
|
For some security applications, especially interesting components of Tcl
|
|
|
|
|
are Safe-Tcl (which creates a sandbox in Tcl)
|
|
|
|
|
and Safe-TK (which implements a sandboxed portable GUI for Safe Tcl), as
|
|
|
|
|
well as the WebWiseTclTk Toolkit which permits Tcl packages to be automatically
|
|
|
|
|
located and loaded from anywhere on the World Wide Web.
|
|
|
|
|
You can find more about the latter from
|
|
|
|
|
<ulink url="http://www.cbl.ncsu.edu/software/WebWiseTclTk">http://www.cbl.ncsu.edu/software/WebWiseTclTk</ulink>.
|
|
|
|
|
It's not clear to me how much code review this has received.
|
|
|
|
|
More useful information is available from the comp.lang.tcl FAQ launch
|
|
|
|
|
page at
|
|
|
|
|
<ulink url="http://www.tclfaq.wservice.com/tcl-faq">http://www.tclfaq.wservice.com/tcl-faq</ulink>.
|
|
|
|
|
However, it's worth noting that TCL's desire to be a small, ``simple''
|
|
|
|
|
language results in a language that can be rather limiting;
|
|
|
|
|
see
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Tcl's original design goal to be a small, simple
|
|
|
|
|
language resulted in a language that was originally somewhat limiting
|
|
|
|
|
and slow.
|
|
|
|
|
For an example of the limiting weaknesses in the original language, see
|
|
|
|
|
<ulink url="http://sdg.lcs.mit.edu/~jchapin/6853-FT97/Papers/stallman-tcl.html">
|
|
|
|
|
Richard Stallman's ``Why You Should Not Use TCL''</ulink>.
|
|
|
|
|
For example, TCL's notion that there is essentially
|
|
|
|
|
only one data type (string) can
|
|
|
|
|
make many programs harder to write (as well as making them slow).
|
|
|
|
|
Also, when I've written TCL programs
|
|
|
|
|
I've found that it's easy to accidentally create TCL programs where
|
|
|
|
|
malicious input strings can cause untoward and unexpected behavior.
|
|
|
|
|
For example, an attackers may be able to cause your TCL program
|
|
|
|
|
to do unexpected things by sending characters with special meaning to TCL
|
|
|
|
|
such as embedded spaces, double-quote, curly braces,
|
|
|
|
|
dollar signs, or brackets (or create input
|
|
|
|
|
Richard Stallman's ``Why You Should Not Use Tcl''</ulink>.
|
|
|
|
|
For example, Tcl was originally designed to really support only
|
|
|
|
|
one data type (string).
|
|
|
|
|
Thankfully, these issues have been addressed over time.
|
|
|
|
|
In particular, version 8.0 added support for more data types
|
|
|
|
|
(integers are stored internally as integers, lists as lists and so on).
|
|
|
|
|
This improves its capabilities, and in particular improves its speed.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
As with essentially all scripting languages,
|
|
|
|
|
Tcl has an "eval" command that parses and executes arbitrary Tcl commands.
|
|
|
|
|
And like all such scripting languages, this eval command needs to be
|
|
|
|
|
used especially carefully, or an attacker could insert
|
|
|
|
|
characters in the input to cause malicious things to occur.
|
|
|
|
|
For example, an attackers may be able insert characters
|
|
|
|
|
with special meaning to Tcl
|
|
|
|
|
such as embedded whitespace (including space and newline),
|
|
|
|
|
double-quote, curly braces, square brackets,
|
|
|
|
|
dollar signs, backslash, semicolon, or pound sign (or create input
|
|
|
|
|
to cause these characters to be created during processing).
|
|
|
|
|
Thus, I don't recommend TCL for writing programs which must
|
|
|
|
|
This also applies to any function that passes data to eval as well
|
|
|
|
|
(depending on how eval is called).
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Here is a small example that may make this concept clearer;
|
|
|
|
|
first, let's define a small function and then interactively invoke it
|
|
|
|
|
directly - note that these uses are fine:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
proc something {a b c d e} {
|
|
|
|
|
puts "A='$a'"
|
|
|
|
|
puts "B='$b'"
|
|
|
|
|
puts "C='$c'"
|
|
|
|
|
puts "D='$d'"
|
|
|
|
|
puts "E='$e'"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
% # This works normally:
|
|
|
|
|
% something "test 1" "test2" "t3" "t4" "t5"
|
|
|
|
|
A='test 1'
|
|
|
|
|
B='test2'
|
|
|
|
|
C='t3'
|
|
|
|
|
D='t4'
|
|
|
|
|
E='t5'
|
|
|
|
|
|
|
|
|
|
% # Imagine that str1 is set by an attacker:
|
|
|
|
|
% set str1 {test 1 [puts HELLOWORLD]}
|
|
|
|
|
|
|
|
|
|
% # This works as well
|
|
|
|
|
% something $str1 t2 t3 t4 t5
|
|
|
|
|
A='test 1 [puts HELLOWORLD]'
|
|
|
|
|
B='t2'
|
|
|
|
|
C='t3'
|
|
|
|
|
D='t4'
|
|
|
|
|
E='t5'
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
|
|
However, continuing the example, let's see how "eval"
|
|
|
|
|
can be incorrectly and correctly called.
|
|
|
|
|
If you call eval in an incorrect (dangerous) way, it
|
|
|
|
|
allows attackers to misuse it.
|
|
|
|
|
However, by using commands like list or lrange to correctly
|
|
|
|
|
group the input, you can avoid this problem:
|
|
|
|
|
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
% # This is the WRONG way - str1 is interpreted.
|
|
|
|
|
% eval something $str1 t2 t3
|
|
|
|
|
HELLOWORLD
|
|
|
|
|
A='test'
|
|
|
|
|
B='1'
|
|
|
|
|
C=''
|
|
|
|
|
D='t2'
|
|
|
|
|
E='t3'
|
|
|
|
|
|
|
|
|
|
% # Here's one solution, using "list".
|
|
|
|
|
% eval something [list $str1 t2 t3 t4 t5]
|
|
|
|
|
A='test 1 [puts HELLOWORLD]'
|
|
|
|
|
B='t2'
|
|
|
|
|
C='t3'
|
|
|
|
|
D='t4'
|
|
|
|
|
E='t5'
|
|
|
|
|
|
|
|
|
|
% # Here's another solution, using lrange:
|
|
|
|
|
% eval something [lrange $str1 0 end] t2
|
|
|
|
|
A='test'
|
|
|
|
|
B='1'
|
|
|
|
|
C='[puts'
|
|
|
|
|
D='HELLOWORLD]'
|
|
|
|
|
E='t2'
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
Using lrange is useful when concatenating arguments to a called
|
|
|
|
|
function, e.g., with more complex libraries using callbacks.
|
|
|
|
|
In Tcl, eval is often used to create a one-argument version of a function
|
|
|
|
|
that takes a variable number of arguments, and you need to be careful
|
|
|
|
|
when using it this way.
|
|
|
|
|
Here's another example (presuming that you've defined a "printf" function):
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
proc vprintf {str arglist} {
|
|
|
|
|
eval printf [list $str] [lrange $arglist 0 end]
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
% printf "1+1=%d 2+2=%d" 2 4
|
|
|
|
|
% vprintf "1+1=%d 2+2=%d" {2 4}
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Fundamentally, when passing a command that will be eventually
|
|
|
|
|
evaluated, you must pass Tcl commands as a properly built list,
|
|
|
|
|
and not as a (possibly concatentated) string.
|
|
|
|
|
For example, the "after" command runs a Tcl command after a given
|
|
|
|
|
number of milliseconds; if the data in $param1 can be controlled by
|
|
|
|
|
an attacker, this Tcl code is dangerously wrong:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
# DON'T DO THIS if param1 can be controlled by an attacker
|
|
|
|
|
after 1000 "someCommand someparam $param1"
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
This is wrong, because if an attacker can control the value of $param1,
|
|
|
|
|
the attacker can control the program.
|
|
|
|
|
For example, if the attacker can cause $param1 to have
|
|
|
|
|
'[exit]', then the program will exit.
|
|
|
|
|
Also, if $param1 would be '; exit', it would also exit.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Thus, the proper alternative would be:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
after 1000 [list someCommand someparam $param1]
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
Even better would be something like the following:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
set cmd [list someCommand someparam]
|
|
|
|
|
after 1000 [concat $cmd $param1]
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Here's another example showing what you shouldn't do,
|
|
|
|
|
pretending that $params is data controlled by possibly malicious user:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
set params "%-20s TESTSTRING"
|
|
|
|
|
puts "'[eval format $params]'"
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
will result in:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
'TESTSTRING '
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
But, when if the untrusted user sends data with an embedded newline,
|
|
|
|
|
like this:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
set params "%-20s TESTSTRING\nputs HELLOWORLD"
|
|
|
|
|
puts "'[eval format $params]'"
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
The result will be this (notice that the attacker's code was executed!):
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
HELLOWORLD
|
|
|
|
|
'TESTINGSTRING '
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
Wojciech Kocjan suggests that the
|
|
|
|
|
simplest solution in this case is to convert this to a list using
|
|
|
|
|
lrange, doing this:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
set params "%-20s TESTINGSTRING\nputs HELLOWORLD"
|
|
|
|
|
puts "'[eval format [lrange $params 0 end]]'"
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
The result would be:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
'TESTINGSTRING '
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
Note that this solution presumes that the potentially malicious
|
|
|
|
|
text is concatenated to the end of the text; as with all languages,
|
|
|
|
|
make sure the attacker cannot control the format text.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
As a matter of style always use curly braces
|
|
|
|
|
when using if, while, for, expr, and any other command which
|
|
|
|
|
parses an argument using expr/eval/subst.
|
|
|
|
|
Doing this will avoid
|
|
|
|
|
a common error when using Tcl called unintended double substitution
|
|
|
|
|
(aka double substitution).
|
|
|
|
|
This is best explained by example; the following code is incorrect:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
while ![eof $file] {
|
|
|
|
|
set line [gets $file]
|
|
|
|
|
}
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
The code is incorrect because the "![eof $file]" text will be evaluated
|
|
|
|
|
by the Tcl parser when the while command is executed the first time,
|
|
|
|
|
and not re-evaluated in every iteration as it should be.
|
|
|
|
|
Instead, do this:
|
|
|
|
|
<programlisting width="65">
|
|
|
|
|
<![CDATA[
|
|
|
|
|
while {![eof $file]} {
|
|
|
|
|
set line [gets $file]
|
|
|
|
|
}
|
|
|
|
|
]]>
|
|
|
|
|
</programlisting>
|
|
|
|
|
Note that both the condition, and the action to be performed,
|
|
|
|
|
are surrounded by curly braces.
|
|
|
|
|
Although there are cases where the braces are redundant, they never hurt,
|
|
|
|
|
and when you fail to include the curly braces where they're needed
|
|
|
|
|
(say, when making a minor change) subtle and hard-to-find
|
|
|
|
|
errors often result.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
More information on good Tcl style can be found in documents such as
|
|
|
|
|
<ulink url="http://www.tcl.tk/doc/styleGuide.pdf">
|
|
|
|
|
Ray Johnson's Tcl Style Guide</ulink>.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
In the past, I have stated that
|
|
|
|
|
I don't recommend Tcl for writing programs which must
|
|
|
|
|
mediate a security boundary.
|
|
|
|
|
If you do choose to do so, be especially careful to ensure that user
|
|
|
|
|
input cannot ``fool'' the program.
|
|
|
|
|
On the other hand, I know of no strong reason (other than
|
|
|
|
|
insufficient review) that TCL programs can't be used to implement mobile code.
|
|
|
|
|
There are certainly TCL advocates who will advocate more use than I do,
|
|
|
|
|
and TCL is one of the few languages with
|
|
|
|
|
a ready-made sandbox implementation.
|
|
|
|
|
Tcl seems to have improved since that time, so while I cannot guarantee
|
|
|
|
|
Tcl will work for your needs, I can't guarantee that any other language
|
|
|
|
|
will work for you either.
|
|
|
|
|
Again, my thanks to Wojciech Kocjan who provided some
|
|
|
|
|
of these suggestions on how to
|
|
|
|
|
write Tcl code for secure applications.
|
|
|
|
|
</para>
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
|
|
@ -13599,6 +13962,9 @@ immutable (they will not be overwritten until garbage-collected and
|
|
|
|
|
then reused, possibly a far time in the future).
|
|
|
|
|
Instead, in Java use char[] to store a password, so it can be
|
|
|
|
|
immediately overwritten.
|
|
|
|
|
In Ada, use type String (an array of characters),
|
|
|
|
|
and not type Unbounded_String, to make sure
|
|
|
|
|
that you have control over the contents.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -13610,6 +13976,10 @@ to stores that are no longer used - this is often referred to as
|
|
|
|
|
"dead store removal."
|
|
|
|
|
Unfortunately, if the write is really to overwrite the value of a secret,
|
|
|
|
|
this means that code that appears to be correct will be silently discareded.
|
|
|
|
|
Ada provides the pragma Inspection_Point; place this after the
|
|
|
|
|
code erasing the memory, and that way you can be certain that
|
|
|
|
|
the object containing the secret will really be erased
|
|
|
|
|
(and that the the overwriting won't be optimized away).
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
@ -13622,7 +13992,7 @@ the C/C++ compilers gcc version 3 or higher, SGI MIPSpro, and the Microsoft
|
|
|
|
|
compilers eliminated simple inlined calls to memset
|
|
|
|
|
intended to overwrite secrets.
|
|
|
|
|
This is allowed by the C and C++ standards.
|
|
|
|
|
Other compilers (such as gcc less than version 3) preserved the inlined
|
|
|
|
|
Other C/C++ compilers (such as gcc less than version 3) preserved the inlined
|
|
|
|
|
call to memset at all optimization levels, showing that the issue
|
|
|
|
|
is compiler-specific.
|
|
|
|
|
Simply declaring that the destination data is volatile doesn't
|
|
|
|
|
@ -13716,8 +14086,14 @@ A survey of legal issues is available at the ``Crypto Law Survey'' site,
|
|
|
|
|
Often, your software should provide a way to
|
|
|
|
|
reject ``too small'' keys, and let the user set what ``too small'' is.
|
|
|
|
|
For RSA keys, 512 bits is too small for use.
|
|
|
|
|
Some believe that 1024 bits for RSA keys are not enough either, based
|
|
|
|
|
on recent work by Bernstein; you may want to
|
|
|
|
|
There is increasing evidence that
|
|
|
|
|
1024 bits for RSA keys is not enough either;
|
|
|
|
|
Bernstein has suggested techniques that simplify brute-forcing RSA, and
|
|
|
|
|
other work based on it
|
|
|
|
|
(such as Shamir and Tromer's "Factoring Large Numbers with the TWIRL device")
|
|
|
|
|
now suggests that 1024 bit keys can be broken in a year
|
|
|
|
|
by a $10 Million device.
|
|
|
|
|
You may want to
|
|
|
|
|
make 2048 bits the minimum for RSA if you really want a secure system,
|
|
|
|
|
and you should certainly do so if you plan to use those keys after 2015.
|
|
|
|
|
For more about RSA specifically, see
|
|
|
|
|
@ -13732,30 +14108,136 @@ cryptographic algorithm issues, see
|
|
|
|
|
<title>Cryptographic Protocols</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
For protocols, try to use standard-conforming protocols
|
|
|
|
|
such as SSL (soon to be TLS), SSH, IPSec, GnuPG/PGP, and Kerberos.
|
|
|
|
|
Many of these overlap somewhat in functionality, but each has
|
|
|
|
|
a ``specialty'' niche.
|
|
|
|
|
SSL (soon to be TLS) is the primary method for protecting http (web)
|
|
|
|
|
transactions.
|
|
|
|
|
PGP-compatible protocols (implemented in PGP and GnuPG) are a primary
|
|
|
|
|
method for securing email end-to-end.
|
|
|
|
|
When you need a security protocol, try to use standard-conforming protocols
|
|
|
|
|
such as IPSec, SSL (soon to be TLS), SSH, S/MIME, OpenPGP/GnuPG/PGP,
|
|
|
|
|
and Kerberos.
|
|
|
|
|
Each has advantages and disadvantages;
|
|
|
|
|
many of them overlap somewhat in functionality, but each tends to be
|
|
|
|
|
used in different areas:
|
|
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Internet Protocol Security (IPSec).
|
|
|
|
|
IPSec provides encryption and/or authentication at the IP packet level.
|
|
|
|
|
However, IPSec is often used in a way that
|
|
|
|
|
only guarantees authenticity of two
|
|
|
|
|
communicating hosts, not of the users.
|
|
|
|
|
As a practical matter, IPSec usually requires low-level support
|
|
|
|
|
from the operating system (which not all implement) and
|
|
|
|
|
an additional keyring server that must be configured.
|
|
|
|
|
Since IPSec can be used as a "tunnel" to secure packets belonging to
|
|
|
|
|
multiple users and multiple hosts, it is especially useful for
|
|
|
|
|
building a Virtual Private Network (VPN) and connecting a remote machine.
|
|
|
|
|
As of this time, it is much less often used to secure communication
|
|
|
|
|
from individual clients to servers.
|
|
|
|
|
The new version of the Internet Protocol, IPv6, comes with
|
|
|
|
|
IPSec ``built in,'' but IPSec also works with the more common IPv4 protocol.
|
|
|
|
|
Note that if you use IPSec, don't use the encryption mode without the
|
|
|
|
|
authentication, because the authentication also acts as
|
|
|
|
|
integrity protection.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Secure Socket Layer (SSL) / TLS.
|
|
|
|
|
SSL/TLS works over TCP and tunnels other protocols using TCP, adding
|
|
|
|
|
encryption, authentication of the server, and optional authentication
|
|
|
|
|
of the client (but authenticating clients using SSL/TLS requires
|
|
|
|
|
that clients have configured X.509 client certificates, something
|
|
|
|
|
rarely done).
|
|
|
|
|
SSL version 3 is widely used; TLS is a later adjustment to SSL that
|
|
|
|
|
strengthens its security and improves its flexibility.
|
|
|
|
|
Currently there is a slow transition going on from SSLv3 to TLS, aided
|
|
|
|
|
because implementations can easily try to use TLS and then back off to SSLv3
|
|
|
|
|
without user intervention.
|
|
|
|
|
Unfortunately, a few bad SSLv3 implementations cause problems with the
|
|
|
|
|
backoff, so you may need a preferences setting to allow users to skip
|
|
|
|
|
using TLS if necessary.
|
|
|
|
|
Don't use SSL version 2, it has some serious security weaknesses.
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
SSL/TLS is the primary method for protecting http (web) transactions.
|
|
|
|
|
Any time you use an "https://" URL, you're using SSL/TLS.
|
|
|
|
|
Other protocols that often use SSL/TLS include POP3 and IMAP.
|
|
|
|
|
SSL/TLS usually use a separate TCP/IP port
|
|
|
|
|
number from the unsecured port, which the IETF is a little unhappy about
|
|
|
|
|
(because it consumes twice as many ports; there are solutions to this).
|
|
|
|
|
SSL is relatively easy to use in programs, because
|
|
|
|
|
most library implementations allow programmers to use operations
|
|
|
|
|
similar to the operations on standard sockets like
|
|
|
|
|
SSL_connect(), SSL_write(), SSL_read(), etc.
|
|
|
|
|
A widely used OSS/FS implementation of SSL (as well as other capabilities)
|
|
|
|
|
is OpenSSL, available at
|
|
|
|
|
<ulink url="http://www.openssl.org">http://www.openssl.org</ulink>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
OpenPGP and S/MIME.
|
|
|
|
|
There are two competing, essentially incompatible standards for
|
|
|
|
|
securing email: OpenPGP and S/MIME.
|
|
|
|
|
OpenPHP is based on the PGP application; an OSS/FS implementation is
|
|
|
|
|
GNU Privacy Guard from
|
|
|
|
|
<ulink url="http://www.gnupg.org">http://www.gnupg.org</ulink>.
|
|
|
|
|
Currently, their certificates are often not interchangeable;
|
|
|
|
|
work is ongoing to repair this.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
SSH.
|
|
|
|
|
SSH is the primary method of securing ``remote terminals'' over an
|
|
|
|
|
internet, and it also includes methods for
|
|
|
|
|
tunelling X Windows sessions.
|
|
|
|
|
However, it's been extended to support single sign-on and
|
|
|
|
|
general secure tunelling for TCP streams, so it's often
|
|
|
|
|
used for securing other data streams too (such as CVS accesses).
|
|
|
|
|
The most popular implementation of SSH is OpenSSH
|
|
|
|
|
<ulink url="http://www.openssh.com">http://www.openssh.com</ulink>,
|
|
|
|
|
which is OSS/FS.
|
|
|
|
|
Typical uses of SSH allows the client to authenticate that the
|
|
|
|
|
server is truly the server, and
|
|
|
|
|
then the user enters a password to authenticate the user
|
|
|
|
|
(the password is encrypted and sent to the other system for verification).
|
|
|
|
|
Current versions of SSH can store private keys, allowing users to not
|
|
|
|
|
enter the password each time.
|
|
|
|
|
To prevent man-in-the-middle attacks, SSH records keying information
|
|
|
|
|
about servers it talks to; that means that typical use of
|
|
|
|
|
SSH is vulnerable to a man-in-the-middle attack during the
|
|
|
|
|
very first connection, but it can detect problems afterwards.
|
|
|
|
|
In contrast, SSL generally uses a certificate authority, which eliminates
|
|
|
|
|
the first connection problem but requires special setup (and payment!) to
|
|
|
|
|
the certificate authority.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Kerberos.
|
|
|
|
|
Kerberos is a protocol for single sign-on and authenticating users
|
|
|
|
|
against a central authentication and key distribution server. Kerberos
|
|
|
|
|
works by giving authenticated users "tickets", granting them access to
|
|
|
|
|
various services on the network.
|
|
|
|
|
When clients then contact servers, the servers can verify the tickets.
|
|
|
|
|
Kerberos is a primary method for securing and supporting authentication
|
|
|
|
|
on a LAN, and for establishing shared secrets (thus, it needs to be
|
|
|
|
|
used with other algorithms for the actual protection of communication).
|
|
|
|
|
SSH is the primary method of securing ``remote terminals'' over an
|
|
|
|
|
internet, e.g., telnet-like and X windows connections, though it's often
|
|
|
|
|
used for securing other data streams too (such as CVS accesses).
|
|
|
|
|
Note that there are two major versions of the SSH protocol, and there
|
|
|
|
|
are several choices for key types and so on; see its documentation
|
|
|
|
|
for more information.
|
|
|
|
|
OpenSSH is an open source implementation of SSH.
|
|
|
|
|
IPSec is the primary method for securing lower-level packets and
|
|
|
|
|
``all'' packets, so it's particularly useful for securing
|
|
|
|
|
virtual private networks and remote machines.
|
|
|
|
|
The new version of the Internet Protocol, IPv6, comes with
|
|
|
|
|
IPSec ``built in,'' but IPSec also works with the more common IPv4 protocol.
|
|
|
|
|
Note that to use Kerberos, both the client and server have to include
|
|
|
|
|
code to use it, and since not everyone has a Kerberos setup, this has
|
|
|
|
|
to be optional - complicating the use of Kerberos in some programs.
|
|
|
|
|
However, Kerberos is widely used.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Many of these protocols allow you to select a number of different
|
|
|
|
|
@ -14026,6 +14508,44 @@ for most environments isn't necessary.
|
|
|
|
|
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
<sect2 id="rmac">
|
|
|
|
|
<title>Randomized Message Authentication Mode (RMAC)</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
<ulink url="http://csrc.nist.gov/CryptoToolkit/modes">
|
|
|
|
|
NIST has developed and proposed
|
|
|
|
|
a new mode</ulink> for using cryptographic algorithms called
|
|
|
|
|
<ulink url="http://www.counterpane.com/crypto-gram-0301.html">
|
|
|
|
|
Randomized Message Authentication Code (RMAC)</ulink>.
|
|
|
|
|
RMAC is intended for use as a message authentication code technique.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Although there's a formal proof showing that RMAC is secure, the
|
|
|
|
|
proof depends on the highly questionable assumption that
|
|
|
|
|
the underlying cryptographic algorithm
|
|
|
|
|
meets the "ideal cipher model" - in particular, that the algorithm is
|
|
|
|
|
secure against a variety of specialized attacks, including related-key attacks.
|
|
|
|
|
Unfortunately, related-key attacks are poorly studied for many algorithms;
|
|
|
|
|
this is not the kind of property or attack that most people worry about
|
|
|
|
|
when analyzing with cryptographic algorithms.
|
|
|
|
|
It's known triple-DES doesn't have this properly, and it's unclear if
|
|
|
|
|
other widely-accepted algorithms like AES have this property
|
|
|
|
|
(it appears that AES is at least weaker against related key attacks than
|
|
|
|
|
usual attacks).
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The best advice right now is "don't use RMAC".
|
|
|
|
|
There are other ways to do message authentication, such as HMAC
|
|
|
|
|
combined with a cryptographic hash algorithm (e.g., HMAC-SHA1).
|
|
|
|
|
HMAC isn't the same thing (e.g., technically it doesn't include a
|
|
|
|
|
nonce, so you should rekey sooner), but the theoretical weaknesses
|
|
|
|
|
of HMAC are merely theoretical, while the problems in RMAC seem far
|
|
|
|
|
more important in the real world.
|
|
|
|
|
</para>
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
<sect2 id="crypto-other">
|
|
|
|
|
<title>Other Cryptographic Issues</title>
|
|
|
|
|
|
|
|
|
|
@ -14271,9 +14791,11 @@ This tool isn't really specific to security.
|
|
|
|
|
<ulink url="http://www.immunitysec.com/spike.html">SPIKE</ulink>
|
|
|
|
|
is a "fuzzer creation kit", i.e., it's a toolkit designed to
|
|
|
|
|
create "random" tests to find security problems.
|
|
|
|
|
The SPIKE toolkit is particularly designed for protocol analysis by
|
|
|
|
|
simulating network protocol clients, and SPIKE proXy is a tool built on
|
|
|
|
|
SPIKE to test web applications.
|
|
|
|
|
SPIKE includes a few pre-canned tests.
|
|
|
|
|
As of version 2.7 its documentation is weak (the author knows this
|
|
|
|
|
is a problem and plans to fix it).
|
|
|
|
|
SPIKE is licensed under the GPL.
|
|
|
|
|
</para></listitem>
|
|
|
|
|
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
@ -14594,6 +15116,20 @@ getting constantly subverted for years at a time.
|
|
|
|
|
|
|
|
|
|
<!-- ??? maybe someday add Logging discussion -->
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Follow best practices and common conventions when leading a
|
|
|
|
|
software development project.
|
|
|
|
|
If you are leading an open source software / free software project,
|
|
|
|
|
some useful guidelines can be found in
|
|
|
|
|
<ulink url="http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/index.html">
|
|
|
|
|
Free Software Project Management HOWTO</ulink> and
|
|
|
|
|
<ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">
|
|
|
|
|
Software Release Practice HOWTO</ulink>;
|
|
|
|
|
you should also read
|
|
|
|
|
<ulink url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar">
|
|
|
|
|
The Cathedral and the Bazaar</ulink>.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Every once in a while, review security guidelines like this one.
|
|
|
|
|
At least re-read the conclusions in <xref linkend="conclusion">,
|
|
|
|
|
|
gferg