[SC-L] Resource limitation

2006-07-17 Thread leichter_jerrold
I was recently looking at some code to do regular expression matching,
when it occurred to me that one can produce fairly small regular
expressions that require huge amounts of space and time.  There's
nothing in the slightest bit illegal about such regexp's - it's just
inherent in regular expressions that such things exist.

Or consider file compression formats.  Someone out there has a hand-
constructed zip file that corresponds to a file with more bytes than
there are particles in the universe.  Again, perfectly legal as it
stands.

Back in the old days, when users ran programs in their own processes and
operating systems actually bothered to have a model of resource usage
that they enforced, you could at least ensure that the user could only
hurt himself if handed such an object.  These days, OS's tend to ignore
resource issues - memory and time are, for most legitimate purposes,
too cheap to meter - and in any case this has long moved outside of
their visibility:  Clients are attaching to multi-thread servers, and
all the OS sees is the aggregate demand.

Allocating huge amounts of memory in almost any multi-threaded app is
likely to cause problems.  Yes, the thread asking for the memory will
die - but unless the code is written very defensively, it stands a
good chance of bring down other threads, or the whole application,
along with it:  Memory is a global resource.

We recently hardened a network protocol against this kind of problem.
You could transfer arbitrary-sized strings over the link.  A string
was sent as a 4-byte length in bytes, followed by the actual data.
A request for 4 GB would fail quickly, breaking the connection.  But
a request for 2 GB might well succeed, starving the rest of the
application.  Worse, the API supports groups of requests - e.g.,
arguments to a function.  Even though the individual requests might
look reasonable, the sum of them could crash the application.  This
makes the hardened code more complex:  You can't just limit the
size of an individual request, you have to limit the total amount
of memory allocated in multiple requests.  Also, because in general
you don't know what the total will be ahead of time, you end up
having to be conservative, so that if a request gets right up close
to the limit, you won't cause the application problems.  (This, of
course, could cause the application *other* problems.)

Is anyone aware of any efforts to control these kinds of vulnerabili-
ties?  It's something that cries out for automation:  Getting it right
by hand is way too hard.  Traditional techniques - strong typing,
unavoidable checking of array bounds and such - may be required for a
more sophisticated approach, but they don't in and of themselves help:
One can exhaust resources with entirely legal requests.

In addition, the kinds of resources that you can exhaust this way is
broader than you'd first guess.  Memory is obvious; overrunning a thread
stack is perhaps less so.  (That will *usually* only affect the thread
in question, but not always.)  How about file descriptors?  File space?
Available transmission capacity for a variety of kinds of connections?

-- Jerry

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Comparing Scanning Tools

2006-06-07 Thread leichter_jerrold
| Date: Mon, 5 Jun 2006 16:50:17 -0400
| From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED]
| To: sc-l@securecoding.org
| Subject: [SC-L] Comparing Scanning Tools
| 
| The industry analyst take on tools tends to be slightly different than
| software practitioners at times. Curious if anyone has looked at Fortify
and
| has formed any positive / negative / neutral opinions on this tool and
| others...
We evaluated a couple of static code scanning tools internally.  The
following is an extract from an analysis I did.  I've deliberately
omitted comparisons - you want to know about Fortify, not how it
compares to other products (which raises a whole bunch of other
issues), and included the text below.  Standard disclaimers:  This
is not EMC's position, it's my personal take.

Caveats:  This analysis is based on a 3-hour vendor presentation.  The
presenter may have made mistakes, and I certainly don't claim that my
recall of what he said is error-free.  A later discussion with others
familiar with Fortify indicated that the experience we had is typical,
but is not necessarily the right way to evaluate the tool.  Effective
use of Fortify requires building a set of rules appropriate to a
particular environment, method of working, constraints, etc., etc. 
This takes significant time (6 months to a year) and effort, but
it was claimed that once you've put in the effort, Fortify is a
very good security scanner.  I am not in a position to evaluate that
claim myself.

BTW, one thing not called out below is that Fortify can be quite slow.
Our experience in testing was that a Fortify scan took about twice as
long as a C++ compile/link cycle, unless you add data flow analysis -
in which case the time is much, much larger.

The brief summary:  In my personal view, Fortify is a worthwhile tool,
but it would not be my first choice.  (Given the opportunity to choose
two tools, it would probably be my second.)  Others involved in the
evaluation reached the opposite conclusion, and rated Fortify first.

-- Jerry

Fortify

Fortify is aimed as a tool for use in a security audit.  It is
deliberately biased in the direction of flagging all potential
security issues.  It provides two kinds of analysis - what they call
semantic and data flow.  Neither use of terminology is consistent
with industry practice.  Their semantic analysis is better described
as a syntactic analysis:  It looks at surface features of the
program (use of certain calls, for example).  It mainly ignores
context.  Fortify's own representative describe this analysis as a
super grep.  This analysis is driven by a large database of rules,
which can be extended.  (In industry practice, a semantic analysis
would look deeply at the meaning of the program.)

Data flow analysis is better called taint analysis.  It traces all
data from external sources to find code that might incorrectly rely on
it.

When run on our code, semantic analysis reports about 3000 problems.
We looked closely at quite a number of them, and with a single
exception (where the code was so complex that no one could be sure),
they were false positives.  For a security audit, that's probably OK.
The problem is: What does one do with the false positives?  If this is
an isolated audit, the answer is - ignore them.  But in practice code
is always changing, so you'll have to audit it again.  How do you
avoid dealing with the same false positives every time?

A look at the problems showed that in many if not most of the cases we
looked at, there was no practical way to change the code to stop the
complaints.  You can permanently suppress individual complaints, but
doing so appears to be very hazardous:  The suppression is based on
the line on which the problem was found.  It could well be that this
is a false positive because of the surrounding context - and that
context might change.  For example, if a line has an array reference
a[i] that is safe because we can prove based on a test 10 lines
earlier that i is in range - something that Fortify itself cannot do,
since it does no value flow analysis - then we might suppress the
warning.  But a later revision to the code could eliminate the test,
and we apparently would not receive a warning.

The data flow analysis gives more useful results.  While the vendor
was here, we only had data flow analysis for a very small subset of
the code:  Producing this is an extremely long process (days of CPU
time).  Again, there were many false positives, though I would
consider almost all of them to be legitimate, in the sense that the
program could not possibly have known certain things about our
environment that would be needed to eliminate the warning.  However,
in some cases, the messages were hard to understand:  There was
insufficient information in the result to figure out just why the
program had reached the conclusion it had.  Based on what the vendor
told us, effective use of the data flow analysis 

Re: [SC-L] Where are developers who know how to develop secure so ftware?

2006-06-07 Thread leichter_jerrold
On Mon, 5 Jun 2006, David A. Wheeler wrote:
| ... One reason is that people can get degrees in
| Computer Security or Software Engineering without knowing how to
| develop software that receives hostile data.  Even the
| Software Engineering Body of Knowledge essentially
| omits security issues (a supplement is being developed,
| thankfully, though it's not REQUIRED)
| 
| If you have connections with your local university, try to talk
| them into increasing the amount of education they provide in
| developing secure software (where software development is done).
| I give away a book on this topic, as part of my effort to get the
| information disseminated
Keep in mind that you can run into a fundamental conflict about what
a university education is supposed to be about.

At least where computer science departments are part of the liberal
arts school, their fundamental view is that they are there to teach
concepts, not to train people for work.  The view is that, if you want
someone who knows the basics of today's technologies, hire a graduate
of a vocational school.  Universities produce people who know how to
think about technology and can learn the details of any particular
technology when they need to.  University programming assignments
focus on the ideas, not on the trivial minutia of validating input,
for example.  A university cryptography course will likely be heavy
on theory, light on how to safely apply cryptographic primitives.  Any
secure computing courses at universities are likely to focus on what
someone identifies as broad principles, not on how to avoid buffer
overflows in C - much less on how to restructure existing horrible
C code so that you can eliminate its buffer overflows.  (When I ask
the typical university-trained CS major How do you recognize that a
class has been designed well? about the only answer I am likely to
get is that the member fields are all private and accessed through
getters and setters.  Sigh.)

I don't want to get into a debate about the validity of this approach,
but recognize that it's there and it's not going away.  I would also
be very careful about any sentence that starts you can get a degree
without knowing X, because you'll be astounded to learn just what
you can substitute for X.  For example, very few CS graduates have
any understanding of even the most fundamental facts about floating
point arithmetic.  (Ask them how many times a loop that starts an FP
value at 0.0 and adds 0.1 to it until the result equal 1.0 will execute.)

When I interview new college graduates, on almost all subjects, I assume
that, if they got a good college education, they understand basic
principles and will be able to use them to learn specifics.  But on the
real practice of software development, what they haven't learned through
co-op programs or other work experience, I'll have to train them on.
(It's also my view that design, architecture, non-trivial secure coding,
and so on cannot be taught in the way that sciences are taught, by
someone lecturing from the front of the room.  They need to be taught as
art or writing is taught - by example and by practice and critique.
This is something university CS departments are rarely set up to do.)

-- Jerry
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] By default, the Verifier is disabled on .Net and Java

2006-05-15 Thread leichter_jerrold
| Kevin is correct, a type confusion attack will allow the bypass of the 
| security manager simply because via a type confusion attack you will be
able 
| to change what the security manager is 'seeing'
| 
| So in an environment where you have a solid Security Policy (enforced by a

| Security Manager) but the verifier is NOT enabled, then to jump out of the

| sandbox all that you need to do is to create a Type Confusion exploit that

| allows you to access a private member that either: calls the protected 
| resource directly or disables the Security Manager (which based on the 
| description provided is the demo that I think Ed Felten did)
| 
| I will stick to my guns and say that in a Virtual Machine environment like

| the JVM or CLR it doesn't make sense to have the overhead of a security 
| system (like CAS or Security Manager) if the verifier is disabled
This is taking a bit too extreme a point of view.

The issue here is what's trusted, and for what purpose.  *Something* has
to be trusted.  The verifier, the security manager, the JVM - if you
can't trust these, you have no hope.

The Java/.Net defaults explicitly say:  (a) I trust the compiler not to
generate dangerous code; (b) I trust the local user not to put stuff
on the local disk where it can be executed unless it came from the
compiler and he trusts it; (c) I trust the OS to protect the stuff on
the local disk.  On the other hand, I *don't* trust stuff that comes
off the network.

Given the realities of the last 10 years of virus-like attacks, this
trust model may well be questionable.  But keep in mind that just
because a Java application passes every verification and is acceptable
to even a very strict security policy doesn't mean it isn't a trojan
horse at a higher semantic level!

Verifying bytecodes certainly blocks many attack vectors, and is a
fine idea - but things are not all black and white.  Runtime
checking will inherently cost you performance.  Someone will
always have an application where the extra cost is too high
relative to the risk of running unverified.

Rather than absolute statements about requiring verification
for all user-written code - while leaving it off for the
large volume of system-provided code - we need a more nuanced
view, a better way to quantify risks and costs and trade them
off.  Otherwise, the same forces that to this day argue that
Java is unacceptable because of the overhead of garbage
collection will continue to push for writing in completely
unsafe languages.
-- Jerry

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php