Re: [SC-L] Bumper sticker definition of secure software

2006-07-18 Thread Rajeev Gopalakrishna
Reliability is concerned only with accidental failures while security has
to consider malicious attacks as well. The difference is in the intent of
the software user: benign or malicious.

And for a bumper sticker, here is one for the pessimists:

Secure Software is a Myth

and another version for the skeptics:

Is Secure Software a Myth?

:)

-rajeev


On Mon, 17 Jul 2006, Peter G. Neumann wrote:

 You suggest:

   Secure software is software that remains dependable despite efforts to
   compromise its dependability.

 You need a bigger-picture view that encompasses trustworthiness
 and assurance.

 Dependable systems are systems that remain dependable despite
 would-be compromises to their dependability.

 Trustworthy systems are systems that are worthy of being trusted
 to satisfy their requirements (for security, reliability, survivability,
 safety, or whatever).

 Security is generally too narrow by itself, because a system that is
 not reliable is not likely to be secure, especially when in
 unreliability mode!

 The principle of Keep It Simple is inherently unworkable with respect to
 security.  Security is inherently complex.  Trustworthiness is broader and
 even more complex.  But if you don't think about trustworthiness more
 broadly, what you get is not likely to be very secure.

 Forget the bumper sticker approach.

 ___
 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

___
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] Bumper sticker definition of secure software

2006-07-18 Thread Gadi Evron
On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote:
 Reliability is concerned only with accidental failures while security has
 to consider malicious attacks as well. The difference is in the intent of
 the software user: benign or malicious.
 
 And for a bumper sticker, here is one for the pessimists:
 
 Secure Software is a Myth
 
 and another version for the skeptics:
 
 Is Secure Software a Myth?
 
 :)

Again, this would speak only to a very small percentage of the
population. You me, maybe 10K people around the world if we are generous.

 
 -rajeev
 
 
 On Mon, 17 Jul 2006, Peter G. Neumann wrote:
 
  You suggest:
 
Secure software is software that remains dependable despite efforts to
compromise its dependability.
 
  You need a bigger-picture view that encompasses trustworthiness
  and assurance.
 
  Dependable systems are systems that remain dependable despite
  would-be compromises to their dependability.
 
  Trustworthy systems are systems that are worthy of being trusted
  to satisfy their requirements (for security, reliability, survivability,
  safety, or whatever).
 
  Security is generally too narrow by itself, because a system that is
  not reliable is not likely to be secure, especially when in
  unreliability mode!
 
  The principle of Keep It Simple is inherently unworkable with respect to
  security.  Security is inherently complex.  Trustworthiness is broader and
  even more complex.  But if you don't think about trustworthiness more
  broadly, what you get is not likely to be very secure.
 
  Forget the bumper sticker approach.
 
  ___
  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
 
 ___
 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
 

___
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] Resource limitation

2006-07-18 Thread Pete Shanahan
[EMAIL PROTECTED] wrote:
 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.
 

Been there, done that, watched computers go down again and again from this.

 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.
 

Most typical unix/linux environments contain aggregate resource meters - per
process limitations on resource usage.

 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.

Ah, now this would be due to the standard definition of a thread. If you used
something more akin to light weight processes then you could isolate this
resource consumption problem a little bit better.

A thread is the basic unit of processing, it was never intended to be a unit of
resource consumption.

 
 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.)
 

Yes, and this falls into general application design. Most network protocols are
designed around the concept of front loading information into the stack. Every
level puts more information at the front, not at the end.
This means that you can make decisions based on a very small piece of data,
allowing you to quickly process it, or kill it should it causes you problems.

If you're allowing such huge data packets and you haven't got the back-end
system in place to process them quickly, and without resource starvation, then
you're just looking to shoot yourself in the foot.

Every system on the planet has had to deal with these problems. From fork-bombs
through to excess network connections. A lot of them can be prevented using
resource limits. Depending on the OS, you can limit resource usage by either
individual process, or group of processes (typically referred to as a 
task-group).

Should an operating system not provide you with integrated features to protect
you from these resource consumptions, then you can quite easily create
monitoring tools that are integrated into the application to monitor and prevent
these kinds of things.
Under an OS like Solaris, you could use a facility like dtrace to monitor
resource use from both the application and OS level to make resource allocation
decisions. This facility would not need to be integrated into the application.

the problem is that a lot of the resource decisions that are made with
applications are more dependent on the administrator rather than the application
developer. After all, while an application developer may say '10% of physical
memory left is OK', and administrator might say 'but what about that other
service there that needs 15%'.

 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 

Re: [SC-L] Bumper sticker definition of secure software

2006-07-18 Thread Paolo Perego
Hi list, I'll introduce myself with a claim:
Software is like Titanic, pleople claim it was unsinkable. Securing is providing it power steering 

thesp0nge
On 7/18/06, Gadi Evron [EMAIL PROTECTED] wrote:
On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote: Reliability is concerned only with accidental failures while security has
 to consider malicious attacks as well. The difference is in the intent of the software user: benign or malicious. And for a bumper sticker, here is one for the pessimists: Secure Software is a Myth
 and another version for the skeptics: Is Secure Software a Myth? :)Again, this would speak only to a very small percentage of thepopulation. You me, maybe 10K people around the world if we are generous.
 -rajeev On Mon, 17 Jul 2006, Peter G. Neumann wrote:  You suggest:   Secure software is software that remains dependable despite efforts to
  compromise its dependability.   You need a bigger-picture view that encompasses trustworthiness  and assurance.   Dependable systems are systems that remain dependable despite
  would-be compromises to their dependability.   Trustworthy systems are systems that are worthy of being trusted  to satisfy their requirements (for security, reliability, survivability,
  safety, or whatever).   Security is generally too narrow by itself, because a system that is  not reliable is not likely to be secure, especially when in  unreliability mode!
   The principle of Keep It Simple is inherently unworkable with respect to  security.Security is inherently complex.Trustworthiness is broader and  even more complex.But if you don't think about trustworthiness more
  broadly, what you get is not likely to be very secure.   Forget the bumper sticker approach.   ___  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  ___ 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___Secure Coding mailing list (SC-L)
SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - 
http://www.securecoding.org/list/charter.php-- $cd /pub$more beerAngeL core developer: http://www.sikurezza.org/angel
 
___
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


[SC-L] bumper sticker slogan for secure software

2006-07-18 Thread SC-L Subscriber Dave Aronson
Paolo Perego [mailto:[EMAIL PROTECTED] writes:

  Software is like Titanic, pleople claim it was unsinkable. Securing is
  providing it power steering

But power steering wouldn't have saved it.  By the time the iceberg was 
spotted, there was not enough time to turn that large a boat.  Perhaps radar, 
but that doesn't make a very good analogy.  Maybe a thicker tougher hull and 
automatic compartment doors?

-Dave




___
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] bumper sticker slogan for secure software

2006-07-18 Thread Dana Epp
Or perhaps less arrogance in believing it won't sink.

Absolute security is a myth. As is designing absolutely secure software.
It is a lofty goal, but one of an absolute that just isn't achievable as
threats change and new attack patterns are found. Designing secure
software is about attaining a level of balance around software
dependability weighed against mitigated risks against said software to
acceptable tolerance levels, while at the same time ensuring said
software accomplishes the original goal... to solve some problem for the
user. 

On my office door is a bumper sticker I made. It simply says:

0x5

10 points to the first person to explain what that means. 


Regards,
Dana Epp 
[Microsoft Security MVP]
http://silverstr.ufies.org/blog/

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of SC-L Subscriber Dave
Aronson
Sent: Tuesday, July 18, 2006 7:53 AM
To: SC-L@securecoding.org
Subject: [SC-L] bumper sticker slogan for secure software

Paolo Perego [mailto:[EMAIL PROTECTED] writes:

  Software is like Titanic, pleople claim it was unsinkable. Securing
is   providing it power steering

But power steering wouldn't have saved it.  By the time the iceberg was
spotted, there was not enough time to turn that large a boat.  Perhaps
radar, but that doesn't make a very good analogy.  Maybe a thicker
tougher hull and automatic compartment doors?

-Dave




___
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

___
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] bumper sticker slogan for secure software

2006-07-18 Thread Andrew van der Stock

Best for older cars...
My other car is a bit more secure

Best for Volvos (or pick another high safety brand):
I wish my finance systems are as safe as this car

Honk if you want secure software

Who has your data? Ask for secure software next time

thanks,
Andrew

smime.p7s
Description: S/MIME cryptographic signature
___
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] bumper sticker slogan for secure software

2006-07-18 Thread Wietse Venema
Dana Epp:
 Or perhaps less arrogance in believing it won't sink.

Absolutely. Here's my $0.02:

secure software fails safely

Any non-trivial piece of software has defects. My challenge is not
to eliminate the last defect, but to make the system safe to use
(for some appropriate definition of safe) in the presence of defects.

Wietse
___
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] bumper sticker slogan for secure software

2006-07-18 Thread ...
well...
there's no possible definition...
unless programmers start thinking and acting in another way, and who 
commissions the software respect and pays for the real value of it, and 
users understand the value,

Secure Software is an Oxymoron


(there may be a reason why this has moron inside..) 


___
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