Re: [SC-L] re-writing college books [was: Re: A banner year for software bugs | Tech News on ZDNet]
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
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
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
| 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
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
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
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