Comments on: Is “Software Protection” Software Security? http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/ Sun, 13 May 2012 16:44:00 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Kyle Quest http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-168 Kyle Quest Wed, 05 Aug 2009 18:20:25 +0000 http://www.cigital.com/justiceleague/?p=211#comment-168 Just a note... The author, Christian Collberg, is a university professor, so his approach is very academic (and he actually had a class on this subject). The book is filled with lots of theory and fancy math formulas :-))) It's really good in what it's trying to do, but if you expect a hands-on manual then the book is not for you. It's more about "design" then implementation" :-) Just a note… The author, Christian Collberg, is a university professor, so his approach is very academic (and he actually had a class on this subject). The book is filled with lots of theory and fancy math formulas :-) )) It’s really good in what it’s trying to do, but if you expect a hands-on manual then the book is not for you. It’s more about “design” then implementation” :-)

]]> By: Chris Wysopal http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-167 Chris Wysopal Wed, 05 Aug 2009 01:20:22 +0000 http://www.cigital.com/justiceleague/?p=211#comment-167 I totally agree with Kyle. I wrote an article for SecurityFocus on obfuscation. The fact that the good guys and the bad guys use it should tell us something. http://www.securityfocus.com/columnists/498 Excerpt: "Obfuscation by itself is not good or bad but it has led to the situation where users can’t determine if the behavior of obfuscated software is good or bad. While it would be a controversial measure, perhaps it's time to treat any code that exhibits unknown behavior as bad. If obfuscation technology was ever perfected we would have perfect DRM and perfect malware. Yet, that outcome is unlikely. The computer ultimately has to decipher and follow a software program’s true instructions. Each new obfuscation technique has to abide by this requirement and, thus, will be able to be reverse engineered." I totally agree with Kyle. I wrote an article for SecurityFocus on obfuscation. The fact that the good guys and the bad guys use it should tell us something.

http://www.securityfocus.com/columnists/498

Excerpt:

“Obfuscation by itself is not good or bad but it has led to the situation where users can’t determine if the behavior of obfuscated software is good or bad. While it would be a controversial measure, perhaps it’s time to treat any code that exhibits unknown behavior as bad.

If obfuscation technology was ever perfected we would have perfect DRM and perfect malware. Yet, that outcome is unlikely. The computer ultimately has to decipher and follow a software program’s true instructions. Each new obfuscation technique has to abide by this requirement and, thus, will be able to be reverse engineered.”

]]> By: Kyle Quest http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-166 Kyle Quest Sat, 01 Aug 2009 04:30:59 +0000 http://www.cigital.com/justiceleague/?p=211#comment-166 It would have been great to be in the same group as Greg Hogland, who wrote the number one rootkit book, but I ended up going with a different publisher for a number of reasons... including the fact that they are local, which greatly simplifies the process. I actually own 5 books from this series (including the "Surreptitious Software" book, of course :-)))) It would have been great to be in the same group as Greg Hogland, who wrote the number one rootkit book, but I ended up going with a different publisher for a number of reasons… including the fact that they are local, which greatly simplifies the process.

I actually own 5 books from this series (including the “Surreptitious Software” book, of course :-) )))

]]> By: gem http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-165 gem Fri, 31 Jul 2009 20:41:15 +0000 http://www.cigital.com/justiceleague/?p=211#comment-165 Hi kyle, Let me know if you would like your book to be considered for the AWL Software Security series as well. gem Hi kyle,

Let me know if you would like your book to be considered for the AWL Software Security series as well.

gem

]]> By: Kyle Quest http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-164 Kyle Quest Fri, 31 Jul 2009 20:36:14 +0000 http://www.cigital.com/justiceleague/?p=211#comment-164 I'm more interested in software security as well, which is why the book I'm writing is focused on dealing with applications running on people's computers including the applications that use "software protection". In a way it's the opposite of the "Surreptitious Software" book, which is why this topic got my interest :-) I’m more interested in software security as well, which is why the book I’m writing is focused on dealing with applications running on people’s computers including the applications that use “software protection”. In a way it’s the opposite of the “Surreptitious Software” book, which is why this topic got my interest :-)

]]> By: gem http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-163 gem Fri, 31 Jul 2009 20:01:55 +0000 http://www.cigital.com/justiceleague/?p=211#comment-163 hi kyle, Yep. I think you'll find many of the approaches you describe in the book (which is called "Surreptitious Software" and not "Software Protection".) Incidentally, as you might imagine I am much more interested in software security than in software protection (or protecting software). Funny how big a difference a word makes. That's why I had a hard time determining whether to include the book in the series. Too late now! gem hi kyle,

Yep. I think you’ll find many of the approaches you describe in the book (which is called “Surreptitious Software” and not “Software Protection”.)

Incidentally, as you might imagine I am much more interested in software security than in software protection (or protecting software). Funny how big a difference a word makes. That’s why I had a hard time determining whether to include the book in the series. Too late now!

gem

]]> By: Kyle Quest http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-162 Kyle Quest Fri, 31 Jul 2009 18:08:50 +0000 http://www.cigital.com/justiceleague/?p=211#comment-162 I completely agree that we'll see more what I'd call "application customization" in the future and we need to be prepared for it. The process has already begun with basic things like ASLR. More "application customization" techniques will be utilized that will customize application environments in many different ways. What I don't agree about is the role of the "software protection" systems in this process. They were not designed for it. They might have some intersecting features, but these features are simply implementation byproducts of their main goal, which is to protect IP by turning software into a black box. Instead of trying to use the "software protection" systems as "application security" systems I'd focus on "application security" systems that are designed specifically for this purpose. They'd have the "application customization" features necessary to provide the diversity we talked about without the negative features of the "software protection" systems that they used to accomplish their task. For example, for a pure "application customization" software there's no need for VM detection, debugger detection, SSDT hooks, and file system filter drivers that take over the entire system. Application security, host intrusion prevention systems, and even "software protection" systems are actually some of my specialties, so I've been on both sides of the fence. Dealing with black box pieces of code is quite a pain when you need to verify that this "magic" code is safe. And when I designed my last "software protection" system its goals didn't include software exploitation prevention :-) All I'm saying is that it's best to leave "software protection" as it to do its job and to have specialized "application customization" products that focus on the application security using various "diversity" mechanisms. I completely agree that we’ll see more what I’d call “application customization” in the future and we need to be prepared for it. The process has already begun with basic things like ASLR. More “application customization” techniques will be utilized that will customize application environments in many different ways. What I don’t agree about is the role of the “software protection” systems in this process. They were not designed for it. They might have some intersecting features, but these features are simply implementation byproducts of their main goal, which is to protect IP by turning software into a black box. Instead of trying to use the “software protection” systems as “application security” systems I’d focus on “application security” systems that are designed specifically for this purpose. They’d have the “application customization” features necessary to provide the diversity we talked about without the negative features of the “software protection” systems that they used to accomplish their task. For example, for a pure “application customization” software there’s no need for VM detection, debugger detection, SSDT hooks, and file system filter drivers that take over the entire system. Application security, host intrusion prevention systems, and even “software protection” systems are actually some of my specialties, so I’ve been on both sides of the fence. Dealing with black box pieces of code is quite a pain when you need to verify that this “magic” code is safe. And when I designed my last “software protection” system its goals didn’t include software exploitation prevention :-) All I’m saying is that it’s best to leave “software protection” as it to do its job and to have specialized “application customization” products that focus on the application security using various “diversity” mechanisms.

]]> By: gem http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-161 gem Fri, 31 Jul 2009 16:01:19 +0000 http://www.cigital.com/justiceleague/?p=211#comment-161 hi kyle, I think you're focusing a bit too much attention on the IP protection stuff (which you are right about...). I agree that maintenance and bug fixing is a mess in systems using obfuscation. Imagine the headaches that automatic update would have if commercial systems used more obfuscation! Nevertheless, I think it behooves us to pay attention to this technology and these ideas because we will be living in a world chock full of them soon. gem hi kyle,

I think you’re focusing a bit too much attention on the IP protection stuff (which you are right about…). I agree that maintenance and bug fixing is a mess in systems using obfuscation. Imagine the headaches that automatic update would have if commercial systems used more obfuscation! Nevertheless, I think it behooves us to pay attention to this technology and these ideas because we will be living in a world chock full of them soon.

gem

]]> By: Kyle Quest http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-160 Kyle Quest Fri, 31 Jul 2009 03:42:04 +0000 http://www.cigital.com/justiceleague/?p=211#comment-160 Diversity as a security mechanism is indeed a good concept. When application environments are different in each deployment it's hard to have a reliable exploit. However, this is not the goal of the "software protection" systems. The IP protection is though. Some implementations might use techniques that would introduce this diversity, but I'd claim that these are two different things that sometimes intersect in their low level implementation. The biggest problem with the "software protection" systems is their black box nature that prevents the host environment from properly verifying the safety of the application in question. It is possible to have systems that introduce the divirsity without complete isolation from the host environment. I can use a gun as a hammer, but it doesn't mean the gun was designed for it :-) Diversity as a security mechanism is indeed a good concept. When application environments are different in each deployment it’s hard to have a reliable exploit. However, this is not the goal of the “software protection” systems. The IP protection is though. Some implementations might use techniques that would introduce this diversity, but I’d claim that these are two different things that sometimes intersect in their low level implementation. The biggest problem with the “software protection” systems is their black box nature that prevents the host environment from properly verifying the safety of the application in question. It is possible to have systems that introduce the divirsity without complete isolation from the host environment. I can use a gun as a hammer, but it doesn’t mean the gun was designed for it :-)

]]> By: gem http://www.cigital.com/justice-league-blog/2009/07/29/is-software-protection-software-security/#comment-159 gem Thu, 30 Jul 2009 17:53:54 +0000 http://www.cigital.com/justiceleague/?p=211#comment-159 hi kyle, Parts of "software protection" are indeed about IP protection, but not all aspects. As an example, consider the idea of diversity as a security mechanism. I was at a DoD meeting this week with Fred Schneider from Cornell and he claimed that some aspects of diversity (carried out using some of the techniques that Christian talks about in his book) have a demonstrable relationship with type safety. Put in simple terms, if you're stuck with crappy languages like C++, then obfuscation may help you with security as much as type safety helps with modern languages like Java. Why would that be? Because attackers can't script up one attack that works against all instances of a given codebase. If you want to take a deep dive into this, here is a pointer to Fred's paper on the idea: http://www.cs.cornell.edu/fbs/publications/punningJrnl.pdf Regardless of that work, I think if you take a look at the book, you'll see why the ideas in it go WAY past IP protection. Thanks for your comment. gem hi kyle,

Parts of “software protection” are indeed about IP protection, but not all aspects. As an example, consider the idea of diversity as a security mechanism. I was at a DoD meeting this week with Fred Schneider from Cornell and he claimed that some aspects of diversity (carried out using some of the techniques that Christian talks about in his book) have a demonstrable relationship with type safety.

Put in simple terms, if you’re stuck with crappy languages like C++, then obfuscation may help you with security as much as type safety helps with modern languages like Java. Why would that be? Because attackers can’t script up one attack that works against all instances of a given codebase.

If you want to take a deep dive into this, here is a pointer to Fred’s paper on the idea: http://www.cs.cornell.edu/fbs/publications/punningJrnl.pdf

Regardless of that work, I think if you take a look at the book, you’ll see why the ideas in it go WAY past IP protection.

Thanks for your comment.

gem

]]>