Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]

2006-11-03 Thread Crispin Cowan
David Crocker wrote:
 Unfortunately, there are at least two situations in which C++ is a more 
 suitable
 alternative to Java and C#:

 - Where performance is critical. Run time of C# code (using the faster .NET 
 2.0
 runtime) can be as much as double the run time of a C++ version of the same
 algorithm. Try telling a large company that it must double the size of its
 compute farms so you can switch to a better programming language!

 - In hard real-time applications where garbage collection pauses cannot be
 tolerated.
   
Except that in both of those cases, C++ is not appropriate either. That
is a case for C.

Crispin

-- 
Crispin Cowan, Ph.D.  http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
 Hack: adroit engineering solution to an unanticipated problem
 Hacker: one who is adroit at pounding round pegs into square holes

___
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] Apple Places Encrypted Binaries in Mac OS X

2006-11-03 Thread Kenneth Van Wyk
Here's a somewhat interesting link to an eweek article that discusses  
Apple's use of encryption to protect some of its OS X binaries:


http://www.eweek.com/article2/0,1895,2050875,00.asp

Of course, encrypting binaries isn't anything new, but it's  
interesting (IMHO) to see how it's being used in a real OS.  The  
article cites speculation as to whether Apple uses encryption for  
anti-piracy or anti-reverse-engineering.


Another interesting side topic (though not mentioned in this article)  
is code obfuscation, which is being increasingly used for both  
purposes as well.  Course, some coders have been inadvertently doing  
code obfuscation for years.  ;-\


Cheers,

Ken
-
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com






PGP.sig
Description: This is a digitally signed message part
___
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] On exploits, hubris, and software security

2006-11-03 Thread Gary McGraw
Hi all,

We all know that there is nothing more powerful for causing software
security change than a flashy exploit demonstration.  Once again, this
has come to the fore in the actions of an IU student who took a well
known boarding pass vulnerability and wrote a script to make it real.
Just after that, a Congressman called for his arrest and the FBI/TSA
showed up at his house with a search warrant and took away his machines.

My latest darkreading article is about the situation:
http://www.darkreading.com/document.asp?doc_id=109717WT.svl=tease3_2

The main thing I wonder is, what do you think?  When you have a hot
demonstration of an exploit, how do you responsibly release it?  What
role do such demonstrations play in moving software security forward?

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
book www.swsec.com 



This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.


___
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] Apple Places Encrypted Binaries in Mac OS X

2006-11-03 Thread Leichter, Jerry
| Here's a somewhat interesting link to an eweek article that discusses
| Apple's use of encryption to protect some of its OS X binaries:
| http://www.eweek.com/article2/0,1895,2050875,00.asp
| 
| Of course, encrypting binaries isn't anything new, but it's
| interesting (IMHO) to see how it's being used in a real OS.  The
| article cites speculation as to whether Apple uses encryption for
| anti-piracy or anti-reverse-engineering.
Actually, it's pretty clear why they are doing it, if you look at
the pieces they encrypt.  The Finder and Dock have no particularly
valuable intellectual property in them, but they are fundamental to
the GUI.  Encrypting them means that a version of OS X that's been
modified to boot on non-Apple hardware won't have a GUI, thus
limiting its attractiveness to non-hackers.  To really get the
result to be widely used, someone would have to write a replacement
for these components that looked enough like the original.  And
of course, since they built a general-purpose mechanism, nothing
prevents Apple encrypting other components later.

Rosetta (the binary translator for PowerPC programs) isn't an essential
program.  Apple may simply consider it valuable, but I think it's more
likely that they may be preparing the way for the next step:  Encrypting
applications they deliver as native.  Since the encryption isn't
supported on PowerPC, running those applications under Rosetta would
provide a quick way to get around encryption for the native versions of
applications.

It is worth pointing out that while Darwin, the underlying OS, is
open source, no part of the GUI code, or Rosetta, or any of
Apple's applications, have ever been open source.

-- 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] On exploits, hubris, and software security

2006-11-03 Thread SC-L Subscriber Dave Aronson
Gary McGraw [mailto:[EMAIL PROTECTED] writes:

 The main thing I wonder is, what do you think? When you have a hot
 demonstration of an exploit, how do you responsibly release it?

This isn't so much about that, in the usual sense. This was, as you say, a 
well-known vulnerability, one screamingly obvious to anybody who bothered to 
think about how to get around the No-Fly List. Bruce Schneier wrote about it on 
his blog long ago, as did many others.

 What role do such demonstrations play in moving software security forward?

It could help dramatically. Not so much because of the demo itself, which will 
of course be ignored by the Powers that Be, but the publicity around it. That 
might possibly eventually make enough of a dent in the public consciousness, to 
wake them up to the fact that what the PTBs have been doing is almost all just 
security THEATER.

However, it depends how much the media gives background. Unfortunately, even a 
brief blurb like this flaw in the No-Fly List concept has been well known for 
several years is unlikely to be aired or printed, since it takes valuable 
time/space away from the latest scandals of skanky socialites and other such 
much more important news. Without this little bit of trivia, the sheeple will 
just ass-u-me that the demo-giver was, as the PTBs will insinuate, a malefactor 
in league with $ENEMY[$YEAR], and deserves to be shipped off to the Git-lag.

-Dave

-- 
Dave Aronson
Specialization is for insects. -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/



___
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] On exploits, hubris, and software security

2006-11-03 Thread Blue Boar
Gary McGraw wrote:
 The main thing I wonder is, what do you think?  When you have a hot
 demonstration of an exploit, how do you responsibly release it?  What
 role do such demonstrations play in moving software security forward?

To pick one extreme, I believe there are times when intentionally 
blindsiding a vendor is appropriate:
http://ryanlrussell.blogspot.com/2006/11/you-want-mac-wireless-bugs.html

BB
___
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] Apple Places Encrypted Binaries in Mac OS X

2006-11-03 Thread Leichter, Jerry
BTW, an interesting fact has been pointed out by Amit Singh, author
of a book describing Mac OS X internals:  The first generation of
x86-based Mac's - or at least some of them - contained a TPM chip
(specifically, the Infineon SKB 9635 TT 1.2.  However, Apple
never used the chip - in fact, they didn't even provide a driver
for it.  It certainly was not used in generating the encrypted
binaries.  Proof?  The most recent revision of the Macbook Pro
does *not* contain a TPM chip.

So in fact Apple is not using the TPM to certify a machine as
being real Apple hardware.  Presumably one can hack out the
decryption key - it's in the software somewhere

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