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
Re: [SC-L] On exploits, hubris, and software security
Ed Felten and I found out early on (back in 1996) that you can use the press as a lever to get companies to do the right thing. We learned this when releasing the very first Java Security hole. We found out that Sun paid much more attention once USA Today picked up the story from comp.risks. Later, we could disclose the problems responsibly, keeping a short leash on Microsoft, Netscape, and Sun without ever resorting to FULL disclosure. Our goal was to get the problems fixed with no nonsense. The companies also allowed the press to be responsibly involved. We discussed all of the problems we found in our books "Java Security" and "Securing Java", but without ever releasing code for the exploits. gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: Blue Boar [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 12:50 PM To: Gary McGraw Cc: SC-L@securecoding.org Subject: 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 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] 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] On exploits, hubris, and software security
Gary McGraw wrote: > Later, we could disclose the problems responsibly, keeping a short leash > on Microsoft, Netscape, and Sun without ever resorting to FULL > disclosure. Our goal was to get the problems fixed with no nonsense. > The companies also allowed the press to be responsibly involved. Are you familiar with the backstory on this one? While I acknowledge there is controversy on who is telling the truth, here's the 60-second summary, according to how I believe it happened. (And how I believe it happened is important, because other researchers also believe this, and are acting accordingly.): -Researchers show video demo at Black Hat of an attack against a wireless driver for a third-party NIC on a MacBook. They poke fun at Mac users. They claim it works against the driver for the built-in wireless, too. (They also claim it works against Windows drivers, *nix drivers, etc.. but no one cares for purposes of the controversy.) -Reporter reports it, uses sensational headline, backs up their story about the built-in card driver being vulnerable, too. Says researchers claim Apple "leaned" on them to remove the video demo of the built-in card exploit. -Researchers claim they told Apple. Apple denies it to reporters. Apple issues press releases denying it. Apple PR person goes on record as claiming Apple was not given one shred of evidence. Employer of one of the researchers appears to be keeping both researchers from saying anything to defend themselves. -Apple releases patch for the vulnerability (so says one of the researchers) and Apple claims credit for finding it. So, if you believe the researchers' side of the story, the press WAS involved, Apple denied it, threw around legal threats to gag the researchers, and then stole the credit. Ergo, the next set of researchers (who tend to believe the first set of researchers) say screw Apple, and release details in such a way that there can be no denial of what they found. Researchers will tend to take the word of other researchers over the vendors, and some researchers already have a tendency to just publish if they get flack from the vendor anyway. The actual hard truth of the situation isn't critical, the researchers will behave according to their perception of what happened. While I am extremely interested in the hard truth for this situation, we don't have it yet, we might never. I don't particularly want to debate the actual truth here, and I'm pretty sure Gary doesn't want us to, either. If you want to read a very good counterpoint from someone who believes more of Apple's side of the story, Dave Schroeder posed a detailed response on my blog entry that I referenced earlier. If you want to debate me on it in particular, please feel free to do so there. Again, the important bit is how Apple appears to behave, to people like the researchers. I have the same bias, and if I were any good at finding kernel vulnerabilities, I'd be treating Apple the same way about now. BB (Apologies for the length. I've already been debating this for a few days, and Gary DID invoke the Full Disclosure debate.) ___ 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] 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
[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=109717&WT.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
[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
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
