Re: [Lit.] Buffer overruns - LONG
From: John A. Malley (102667.2235_at_compuserve.com)
Date: 02/03/05
- Next message: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Previous message: David Wagner: "Re: [Lit.] Buffer overruns"
- In reply to: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 03 Feb 2005 00:09:03 -0800
David Wagner wrote:
[...]
>
> Let me make sure I understand what you mean by "hazard". Does that
> term refer to the potential impact of a bug? i.e., if risk = cost of
> harmful event * probability of harmful event, does "hazard" get at the
> 'cost of harmful event' part of the equation?
Yes, that's it. The hazard is the effect of the security bug defined in
terms of costs in one or more scales of value. I think we need a common,
community-accepted definition for the value scale(s) to gauge the
effects of security bugs on the intended function(s) of the
Internet-connected application.
In the avionics world, we gauge the effects of the malfunctions and the
loss of functions assigned to software by their effects on the crew
(workload, the level of attention they can devote to events after the
failure), the airframe (attitude and altitude changes, stalling, hull
loss, etc.) and on the passengers (discomfort, injury, a few deaths, a
lot of deaths.)
>
> If so, then I agree that techniques for reducing the impact of a bug
> are important. My view is that this is exactly what ABC is aimed at;
> ABC does not reduce the probability of a harmful event, but (for many
> applications) is intended to reduce the cost of the harmful event.
> (If we use plain C without ABC, then the potential downside associated
> with a potential buffer overrun bug is essentially unbounded badness.)
I agree that ABC is a means or method of achieving an objective
established for the development and fielding of Internet-connected
software that carries out its intended function with a level of
confidence in its security when doing so.
Qualifying/quantifying the potential downside associated with the buffer
overrun bug (its hazard) depends on the intended function of the
Internet-connected application.
Consider an Internet-connected Calendar application that gives today's
date and time, and synchronizes over the Internet with a central atomic
clock source. Let's assume it's a minor inconvenience for the wrong time
or date to be displayed, or for the clock to stop. Bugs causing these
errors in intended function result in minor inconveniences.
Let the intended function be to provide time as a stand-alone device in
the the control hub of the US Midwest power grid. Workers look at it
hanging up there on the wall. A malicious attack over the Internet
could exploit the buffer overrun bug and allow the attacker to enter
misleading dates or times. That's a minor hazard.
Now let the intended function be to provide time to the operator of the
server and O/S running the "Master Control Program" responsible for
switching 3 phase distribution lines on and off the grid. The clock runs
as a process on that server's O/S. Assume we run it with root
privileges. Now that same malicious attack over the Internet could
potentially allow the attacker to get root privileges and ultimately
control of the MCP, and thus the grid. (Eh, it's just a hypothetical
example..) But the same buffer overflow bug could have drastically
different hazards depending on the intended function.
It might be sufficient to just use visual inspection of the code by the
author of the code in the stand-alone case, because the hazard due to a
potential buffer overflow is not that severe.
I would want to see a lot more effort in the second case, like ABC, or
rules against running insignificant processes with root privileges, etc.
I would expect more steps to be taken in the second case because of the
potential hazard due to a potential security bug.
What I see as important is 1) establishing the objectives to achieve
when specifying and developing the software to ensure security while
ensuring the intended functions of the application. It's analogous to
the objectives in DO-178B driven by safety while ensuring the intended
functions, and 2) spelling out the kinds of methods/means to achieve
those objectives in response to the increased severity of the hazards
associated with the potential security bugs.
The methods to achieve those objectives are specific tactics like when
and how to use partitioning and sandboxes, principle of lease privilege,
privilege separation, etc., as you mention below -
>
> There are many other techniques like this in computer security, including
> the principle of least privilege, sandboxing, privilege separation, and
> so on. They are extremely useful, and thinking about how to architect
> systems (at a high level) so that the impact of harmful events is
> minimized is a very useful mindset (albeit often a challenging design
> problem). I feel this is a rich area for improving system security.
I agree, and I see ways of relating this to the methods and means of
achieving certain community-accepted objectives during the specification
and development of Internet-connected applications.
>
>
> Have you seen _Writing Secure Code, _Building Secure Software_,
> and _Security Engineering_? Three excellent books in a vaguely
> similar topic area.
I have "Security Engineering" and have read _most_ but not all of it. I
recommend it to people who express any curiosity about systems
engineering and security. I'll look for the other two at the local
Barnes and Noble this weekend. I did recently pick up a copy of
"Security Warrior" by Cryus Peikari and Anton Chuvakin and "SELINUX,
NSA's Open Source Security Enhanced Linux" by Bill McCarty, both from
O'Reilly Media. And a copy of "Cryptographic Security Architecture,
Design and Verification" by Peter Gutmann. (Ouch, the VISA charges will
hurt next month.) :-)
John A. Malley
102667.2235@compuserve.com
- Next message: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Previous message: David Wagner: "Re: [Lit.] Buffer overruns"
- In reply to: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Reply: David Wagner: "Re: [Lit.] Buffer overruns - LONG"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
