From ken at vanwyk.org Thu Nov 17 08:21:10 2005 From: ken at vanwyk.org (Kenneth R. van Wyk) Date: Thu, 17 Nov 2005 08:21:10 -0500 Subject: [SC-L] test posting Message-ID: <200511170821.10555@KRvW> this here is a test posting. please ignore. Ken From ken at vanwyk.org Thu Nov 17 08:33:01 2005 From: ken at vanwyk.org (Kenneth R. van Wyk) Date: Thu, 17 Nov 2005 08:33:01 -0500 Subject: [SC-L] test 2 Message-ID: <200511170833.01721@KRvW> Another test message. Ignore. Ken From beau at vanwyk.org Thu Nov 17 08:39:09 2005 From: beau at vanwyk.org (Beau Diddley van Wyk) Date: Thu, 17 Nov 2005 08:39:09 -0500 Subject: [SC-L] test Message-ID: <200511170839.09823@KRvW> another test. ignore. Ken From ken at krvw.com Fri Nov 18 17:13:53 2005 From: ken at krvw.com (Kenneth R. van Wyk) Date: Fri, 18 Nov 2005 17:13:53 -0500 (EST) Subject: [SC-L] Administrative: SC-L changes Message-ID: <40816.68.100.23.165.1132352033.squirrel@mail.krvw.com> Greetings all, FYI, I have moved the securecoding.org site and SC-L mailing list over to a different host. The new host should be quite a bit faster, as it's used by a much (!) smaller number of domains than the old one. More importantly, at least for SC-L, is that I've changed the mailing list manager from Majordomo to Mailman. That means that the user interface for subscribing, unsubscribing, digest vs. normal, etc., is now completely different. Additionally, Mailman automatically handles archiving of the list, so the list traffic (from now on) will be nicely archived for easy viewing and such. For any and all subscription changes, just point your browsers to http://www.securecoding.org/list/ and you'll see a link to the Mailman page. For those so inclined, it should now be easier for you to change between digest and non-digest format for the list. Mailman makes that quite easy for users. Please try to follow the instructions on the Mailman page. If that doesn't work, contact me and I'll be happy to make the change for you. Lastly, I did a bit of testing of Mailman before doing the cutover, but I'm by no means a Mailman expert (yet). I _hope_ that all goes smoothly, but I ask you all to be patient if there are any unexpected burps and such. Thanks for your patience. Cheers, Ken van Wyk --- KRvW Associates, LLC http://www.KRvW.com From Ken at krvw.com Mon Nov 21 15:46:56 2005 From: Ken at krvw.com (Kenneth R. van Wyk) Date: Mon, 21 Nov 2005 15:46:56 -0500 Subject: [SC-L] Slashdot | Developing Securely In Windows Message-ID: <200511211546.56804@KRvW> FYI, there's a review (by Jim Holmes) of Keith Brown's book, "The .NET Developer's Guide to Windows Security" available out on Slashdot at: http://books.slashdot.org/books/05/11/21/1442228.shtml The review summary reads, "Terrific coverage of how to go about securely developing .NET software". Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com From ken at krvw.com Tue Nov 22 11:06:18 2005 From: ken at krvw.com (Kenneth R. van Wyk) Date: Tue, 22 Nov 2005 11:06:18 -0500 (EST) Subject: [SC-L] ZDNet: Attackers switching to applications, media players Message-ID: <2718.208.54.14.25.1132675578.squirrel@mail.krvw.com> FYI, interesting article on ZDNet today citing a SANS study. The article says, among other things, "Online criminals shifted their attacks in 2005 from operating systems such as Windows to media players and software programs, according to a study released Tuesday." If the study's findings are correct, then it places an emphasis on organizations' software security efforts. IMHO, it's certainly not about "the perimeter" anymore (if it ever really was). Cheers, Ken P.S. On a list administrative front, it appears that the Mailman list manager seems to be working pretty well for us. One significant change that could impact you subscribers is that I've configured Mailman to discard incoming messages from anyone that is not subscribed to SC-L. So, if you use a local mail alias to read your SC-L, you might have difficulties submitting messages to the group. If that's the case, just drop me a note and I'll step you through setting things up so that your submissions don't get discarded. (The discarding has done wonders for reducing the amount of spam in my life.) -- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com From ken at krvw.com Tue Nov 22 11:16:18 2005 From: ken at krvw.com (Kenneth R. van Wyk) Date: Tue, 22 Nov 2005 11:16:18 -0500 (EST) Subject: [SC-L] Missing URL -- ZDNet: Attackers switching to applications, media players Message-ID: <3862.208.54.14.25.1132676178.squirrel@mail.krvw.com> Sorry, I neglected to include the URL for the story that I cited. It can be found at: http://news.zdnet.com/2100-1009_22-5966663.html?tag=zdfd.newsfeed Cheers, Ken From jeremy.epstein at webmethods.com Tue Nov 22 12:07:37 2005 From: jeremy.epstein at webmethods.com (Jeremy Epstein) Date: Tue, 22 Nov 2005 12:07:37 -0500 Subject: [SC-L] ZDNet: Attackers switching to applications, media play ers Message-ID: <5B10E50E14A4594EB1B5566B69AD94070C0E8560@maileast> Also reported in the Washington Post today: http://www.washingtonpost.com/wp-dyn/content/article/2005/11/21/AR2005112101 424.html?sub=AR (regisration required). The Post isn't known for their technology coverage; perhaps it's because SANS is local. --Jeremy > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk > Sent: Tuesday, November 22, 2005 11:06 AM > To: Secure Coding Mailing List > Subject: [SC-L] ZDNet: Attackers switching to applications, > media players > > FYI, interesting article on ZDNet today citing a SANS study. > The article says, among other things, "Online criminals > shifted their attacks in 2005 from operating systems such as > Windows to media players and software programs, according to > a study released Tuesday." > > If the study's findings are correct, then it places an > emphasis on organizations' software security efforts. IMHO, > it's certainly not about "the perimeter" anymore (if it ever > really was). > > Cheers, > > Ken > > P.S. On a list administrative front, it appears that the > Mailman list manager seems to be working pretty well for us. > One significant change that could impact you subscribers is > that I've configured Mailman to discard incoming messages > from anyone that is not subscribed to SC-L. So, if you use a > local mail alias to read your SC-L, you might have > difficulties submitting messages to the group. If that's the > case, just drop me a note and I'll step you through setting > things up so that your submissions don't get discarded. (The > discarding has done wonders for reducing the amount of spam > in my life.) > > -- > Kenneth R. van Wyk > KRvW Associates, LLC > http://www.KRvW.com > > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > From falcon at secureconsulting.net Fri Nov 25 14:25:23 2005 From: falcon at secureconsulting.net (Benjamin Tomhave) Date: Fri, 25 Nov 2005 14:25:23 -0500 Subject: [SC-L] application security reqs - standards comparison? Message-ID: <000201c5f1f5$fb8f9620$0a01a8c0@zippy> Greetings - new to the list, was reading through the archives, saw this recent post... Jari Pirhonen wrote: > Does anyone know or have a document, which would compare different security/auditing standards > from the application security point of view? For example ISO 17799, COBIT, ISF, VISA/MC, GAISP, > etc. I'd like to see, how much differences there really are and if one standard would cover all > the other standards on this particular area. I published a white paper last Summer that classifies, compares, and describes many of these methods. It's available online from http://falcon.secureconsulting.net/professional/papers/Alphabet_Soup.pdf and is scheduled for an updated release this Winter to account for the recent revisions of 17799, new release of 27001, finalized PCI DSS standards, upcoming revisions to CobiT, and so on. Your comments or corrections are welcomed. cheers, -ben --- Benjamin Tomhave, CISSP falcon at secureconsulting.net http://falcon.secureconsulting.net/ "We must scrupulously guard the civil liberties of all citizens, whatever their background. We must remember that any oppression, any injustice, any hatred is a wedge designed to attack our civilization." -President Franklin Delano Roosevelt From gem at cigital.com Wed Nov 30 09:44:00 2005 From: gem at cigital.com (Gary McGraw) Date: Wed, 30 Nov 2005 09:44:00 -0500 Subject: [SC-L] BSI: IEEE article on seven pernicious kingdoms Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB42100C@va-mail.cigital.com> Hi all, It has been some time since I announced an installment of "Building Security In" in IEEE Security & Privacy magazine. I have been busy writing a new book called "Software Security" to be released in February. The book is based on the idea of the touchpoints first introduced and discussed in the BSI series. You can find copies of the BSI articles here . The most recent article "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors" was co-authored with Katrina Tsipenyuk and Brian Chess. It is about how to classify and categorize security bugs. A complete list of the articles is pasted below. I am sure many of you already subscribe to S&P. If you don't yet, you should...check out . Note that you can subscribe for $29 even without being an IEEE member . BTW, the lead story in the new issue is covered by the NY Times today (FBI wiretapping hack). In related news, I am pleased to announce the existence of the Addison-Wesley Software Security Series which I will edit. More on that later. In the meantime, if you're interested in writing an in depth technical book about software security please let me know. gem Gary McGraw, Ph.D. CTO, Cigital http://www.cigital.com The S&P Building Security In series Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors (November/December 2005) Bridging the Gap Between Software Development and Information Security (September/October 2005) A Portal for Software Security (July/August 2005) Adopting a Software Security Improvement Program (May/June 2005) Knowledge for Software Security (March/April 2005) Software Penetration Testing (January/February 2005) Static Analysis for Security (November/December 2004) Software Security Testing (September/October 2004) Risk Analysis in Software Design (July/August 2004) Misuse and Abuse Cases: Getting Past the Positive (May/June 2004) Software Security (March/April 2004) ---------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------- From jet at flatline.net Mon Dec 5 11:12:19 2005 From: jet at flatline.net (j eric townsend) Date: Mon, 5 Dec 2005 11:12:19 -0500 Subject: [SC-L] How to find firms to do external code reviews? Message-ID: I'm working for an outfit that is looking for some external code review and external black-box testing of consumer electronics products. In the past, I've usually sent RFPs to firms I talked to at an RSA conference, but I didn't go last year and there's been some shuffling of companies since then. Any suggestions on where to post RFPs for this sort of thing? -- jet / KG6ZVQ jet at flatline.net pgp: 0xD0D8C2E8 AC9B 0A23 C61A 1B4A 27C5 F799 A681 3C11 D0D8 C2E8 From ljknews at mac.com Tue Dec 6 14:23:28 2005 From: ljknews at mac.com (ljknews) Date: Tue, 6 Dec 2005 14:23:28 -0500 Subject: [SC-L] How to find firms to do external code reviews? In-Reply-To: References: Message-ID: At 11:12 AM -0500 12/5/05, j eric townsend wrote: > I'm working for an outfit that is looking for some external code review and external black-box testing of consumer electronics products. > > In the past, I've usually sent RFPs to firms I talked to at an RSA conference, but I didn't go last year and there's been some shuffling of companies since then. > > Any suggestions on where to post RFPs for this sort of thing? comp.lang.ada (or whatever language fits). But I don't understand why it isn't white box testing if they have seen the code. -- Larry Kilgallen From Ken at krvw.com Tue Dec 13 10:54:46 2005 From: Ken at krvw.com (Kenneth R. van Wyk) Date: Tue, 13 Dec 2005 10:54:46 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection Message-ID: <200512131054.46244@KRvW> FYI, eWeek has an interesting article on Intel's "System Integrity Services," which aims to add hardware level protection against rootkits. Now, it seems to me that they're bundling all sorts of nasty critters in with their definition of "rootkit" but it's worth reading, IMHO. The detection mechanism seems to primarily be looking primarily for non-OS software modifying OS inhabited memory blocks. Wonder how they're definining (and maintaining the definition) of each... I also wonder how it'll impact near-OS software installations like, say, device drivers, authentication plug-ins, and other things that need to poke pretty deeply into the OS in order to install. Anyway, here's a URL to the article. http://www.eweek.com/article2/0,1895,1900533,00.asp Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com From itripn at gmail.com Tue Dec 13 12:28:48 2005 From: itripn at gmail.com (Ron Forrester) Date: Tue, 13 Dec 2005 09:28:48 -0800 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: <200512131054.46244@KRvW> References: <200512131054.46244@KRvW> Message-ID: On 12/13/05, Kenneth R. van Wyk wrote: > The detection mechanism seems to primarily be looking primarily for non-OS > software modifying OS inhabited memory blocks. Wonder how they're definining > (and maintaining the definition) of each... I also wonder how it'll impact > near-OS software installations like, say, device drivers, authentication > plug-ins, and other things that need to poke pretty deeply into the OS in > order to install. I have to admit, when I initially read about this I immediately dismissed it as nothing but marketing hype -- what little details they gave for the solution seemed to me to be less than practical and certainly would have issues adapting to targeted attempts to deceive the mechanism. I'd love to hear other peoples thoughts on the matter. -- rjf& From ljknews at mac.com Tue Dec 13 11:38:19 2005 From: ljknews at mac.com (ljknews) Date: Tue, 13 Dec 2005 11:38:19 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: <200512131054.46244@KRvW> References: <200512131054.46244@KRvW> Message-ID: At 10:54 AM -0500 12/13/05, Kenneth R. van Wyk wrote: > FYI, eWeek has an interesting article on Intel's "System Integrity Services," > which aims to add hardware level protection against rootkits. Now, it seems > to me that they're bundling all sorts of nasty critters in with their > definition of "rootkit" but it's worth reading, IMHO. > > The detection mechanism seems to primarily be looking primarily for non-OS > software modifying OS inhabited memory blocks. Wonder how they're definining > (and maintaining the definition) of each... I also wonder how it'll impact > near-OS software installations like, say, device drivers, authentication > plug-ins, and other things that need to poke pretty deeply into the OS in > order to install. > > Anyway, here's a URL to the article. > > http://www.eweek.com/article2/0,1895,1900533,00.asp Gee this sounds just like virus wars, using add-on products to make up for weakness in the operating system. A reliable operating system would not permit such modifications in the first place -- Larry Kilgallen From bellovin at acm.org Tue Dec 13 11:20:01 2005 From: bellovin at acm.org (Steven M. Bellovin) Date: Tue, 13 Dec 2005 11:20:01 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection Message-ID: <20051213162001.C6E093BFD35@berkshire.machshav.com> In message <200512131054.46244 at KRvW>, "Kenneth R. van Wyk" writes: >FYI, eWeek has an interesting article on Intel's "System Integrity Services," >which aims to add hardware level protection against rootkits. Now, it seems >to me that they're bundling all sorts of nasty critters in with their >definition of "rootkit" but it's worth reading, IMHO. > >The detection mechanism seems to primarily be looking primarily for non-OS >software modifying OS inhabited memory blocks. Wonder how they're definining >(and maintaining the definition) of each... I also wonder how it'll impact >near-OS software installations like, say, device drivers, authentication >plug-ins, and other things that need to poke pretty deeply into the OS in >order to install. > >Anyway, here's a URL to the article. > >http://www.eweek.com/article2/0,1895,1900533,00.asp > Put another way, Sony's DRM stunt, though ill-conceived and poorly executed, would have been *authorized* if they'd cleaned up the permission request just a little bit. --Steve Bellovin, http://www.stevebellovin.com From mshines at purdue.edu Tue Dec 13 15:19:12 2005 From: mshines at purdue.edu (Michael S Hines) Date: Tue, 13 Dec 2005 15:19:12 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: <20051213162001.C6E093BFD35@berkshire.machshav.com> Message-ID: <00db01c60022$7c290930$4fa7d280@OS00009> Doesn't a hardware 'feature' such as this lock software into a two-state model (user/priv)? Who's to say that model is the best? Will that be the model of the future? Wouldn't a two-state software model that works be more effective? It's easier to change (patch) software than to rewire hardware (figuratively speaking). Just wondering... Mike Hines ----------------------------------- Michael S Hines mshines at purdue.edu From ljknews at mac.com Tue Dec 13 15:47:05 2005 From: ljknews at mac.com (ljknews) Date: Tue, 13 Dec 2005 15:47:05 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: References: <200512131054.46244@KRvW> Message-ID: At 9:28 AM -0800 12/13/05, Ron Forrester wrote: > On 12/13/05, Kenneth R. van Wyk wrote: >> The detection mechanism seems to primarily be looking primarily for non-OS >> software modifying OS inhabited memory blocks. Wonder how they're definining >> (and maintaining the definition) of each... I also wonder how it'll impact >> near-OS software installations like, say, device drivers, authentication >> plug-ins, and other things that need to poke pretty deeply into the OS in >> order to install. > > I have to admit, when I initially read about this I immediately > dismissed it as nothing but marketing hype -- what little details they > gave for the solution seemed to me to be less than practical and > certainly would have issues adapting to targeted attempts to deceive > the mechanism. > > I'd love to hear other peoples thoughts on the matter. For a test of their generalized characterization of the problem, consider how well they might do analyzing VMS running on Itanium. If the "non-OS software" attempted to trick the "OS software" into doing something from an inner mode, their external approach seems intractable. On the other hand, "non-OS software" calls to "OS software" regularly result in changes to memory protected against outer mode access. -- Larry Kilgallen From cradle at umd.edu Tue Dec 13 16:20:36 2005 From: cradle at umd.edu (David Eisner) Date: Tue, 13 Dec 2005 16:20:36 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: References: <200512131054.46244@KRvW> Message-ID: <439F3B24.7070603@umd.edu> Ron Forrester wrote: > On 12/13/05, Kenneth R. van Wyk wrote: > >> The detection mechanism seems to primarily be looking primarily for non-OS >> software modifying OS inhabited memory blocks. Wonder how they're definining >> (and maintaining the definition) of each... I also wonder how it'll impact >> near-OS software installations like, say, device drivers, authentication >> plug-ins, and other things that need to poke pretty deeply into the OS in >> order to install. >> > > I have to admit, when I initially read about this I immediately > dismissed it as nothing but marketing hype -- what little details they > gave for the solution seemed to me to be less than practical and > certainly would have issues adapting to targeted attempts to deceive > the mechanism. > A bit more detail: http://www.intel.com/technology/magazine/research/runtime-integrity-1205.htm http://www.intel.com/technology/comms/download/system_integrity_services.pdf I haven't read these carefully, but it reminds me a bit of trusted computing [1]. In fact, one of the authors (first link) is a member of the Trusted Computing Group. Wouldn't it be funny if proposed rootkit "cures" turn out to provide a good platform for more formidable DRM technology? -David [1] http://www-personal.si.umich.edu/~rwash/projects/trusted/ From mudge at uidzero.org Tue Dec 13 18:01:08 2005 From: mudge at uidzero.org (mudge) Date: Tue, 13 Dec 2005 18:01:08 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: <00db01c60022$7c290930$4fa7d280@OS00009> References: <00db01c60022$7c290930$4fa7d280@OS00009> Message-ID: There was a lady who went to Purdue, I believe her name was Carla Brodley. She is a professor at Tufts currently. One of her projects, I'm not sure whether it is ongoing or historic, was surrounding hardware based stack protection. There wasn't any protection against heap / pointer overflows and I don't know how it fares when stack trampoline activities (which can be valid, but are rare outside of older objective-c code). www.smashguard.org and https://engineering.purdue.edu/ ResearchGroups/ SmashGuard/smash.html have more data. I'm not sure if this is a similar solution to what Intel might be pursuing. I believe the original "smashguard" work was based entirely on Alpha chips. cheers, .mudge On Dec 13, 2005, at 15:19, Michael S Hines wrote: > Doesn't a hardware 'feature' such as this lock software into a two- > state model > (user/priv)? > > Who's to say that model is the best? Will that be the model of the > future? > > Wouldn't a two-state software model that works be more effective? > > It's easier to change (patch) software than to rewire hardware > (figuratively speaking). > > Just wondering... > > Mike Hines > ----------------------------------- > Michael S Hines > mshines at purdue.edu > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/ > listinfo/sc-l > List charter available at - http://www.securecoding.org/list/ > charter.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20051213/92c6f8ea/attachment.html From ge at linuxbox.org Tue Dec 13 20:24:16 2005 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 14 Dec 2005 03:24:16 +0200 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: References: <200512131054.46244@KRvW> Message-ID: <439F7440.5020104@linuxbox.org> >>http://www.eweek.com/article2/0,1895,1900533,00.asp > > > Gee this sounds just like virus wars, using add-on products to make > up for weakness in the operating system. > > A reliable operating system would not permit such modifications in > the first place Whatever happened with Intel NX technology? Anyone followed up on that? "Rootkits" in this case seem to be *more* a good name for this tech than what rootkits actually are. Gadi. From Greenarrow1 at msn.com Tue Dec 13 21:23:41 2005 From: Greenarrow1 at msn.com (Greenarrow 1) Date: Tue, 13 Dec 2005 18:23:41 -0800 Subject: [SC-L] Intel turning to hardware for rootkit detection References: <200512131054.46244@KRvW> Message-ID: The root kit blahs, another fact of users not paying attention to what they are opening or installing whether it be the home user or the corporate IT. So the Intel program alerts you, well any good firewall should also alert you of outgoing or programs communicating not authorized by you. I feel the major problem is not detecting them, it is the removal of Root Kits which can cause other programs to malfunction or the OS to crash. I did not see any explanation from Intel of how to get rid of them if you happen to be one of the unfortunate. Maybe I read the article wrong but is it not a little to late to be alerted after the fact. They need to develop a program that will detect a root kit before it gets to the registry like AV's do if it detects a virus. Major AV vendors are working on this now and from what I had read and seen they are really having a problem with root kits. There are some registry programs that do not allow anything in until the user authorizes it so would not this defeat a root kit. I know this as I have one and even though it is a pain when I install trusted software or hardware nothing gets changed or entered into the registry unless I authorize it. Even if it does not require a registry entry my other program does not allow any new processes unless I authorize them. I know they work as I have bench tested numerous changes even using honey pot viruses which did not get by my programs. The Sony Cd I used was not allowed since it was trying to install in the registry which my registry program alerted me to. Which means the root kit never made it to my registry. Happy Holidays to all. Regards, George Greenarrow1 InNetInvestigations-Forensics ----- Original Message ----- From: "Ron Forrester" To: "Kenneth R. van Wyk" Cc: "Secure Coding Mailing List" Sent: Tuesday, December 13, 2005 9:28 AM Subject: Re: [SC-L] Intel turning to hardware for rootkit detection > On 12/13/05, Kenneth R. van Wyk wrote: > > The detection mechanism seems to primarily be looking primarily for > > non-OS > > software modifying OS inhabited memory blocks. Wonder how they're > > definining > > (and maintaining the definition) of each... I also wonder how it'll > > impact > > near-OS software installations like, say, device drivers, authentication > > plug-ins, and other things that need to poke pretty deeply into the OS > > in > > order to install. > > I have to admit, when I initially read about this I immediately > dismissed it as nothing but marketing hype -- what little details they > gave for the solution seemed to me to be less than practical and > certainly would have issues adapting to targeted attempts to deceive > the mechanism. > > I'd love to hear other peoples thoughts on the matter. > > -- > rjf& > > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > From crispin at novell.com Wed Dec 14 04:33:48 2005 From: crispin at novell.com (Crispin Cowan) Date: Wed, 14 Dec 2005 01:33:48 -0800 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: References: <00db01c60022$7c290930$4fa7d280@OS00009> Message-ID: <439FE6FC.80109@novell.com> Smashguard, if I recall correctly, offers approximately the protection of existing compiler methods, but with the added fun of requiring modified (non-existent) hardware. The referenced hardware in the IEEE article and the intel.com pages appears to be some descendant of Palladium; it is a hardware integrity checker/attestation mechanism. A small, hardware-enforced core performs a chain of crypto-checks prior to boot strapping the BIOS, and then the OS, and makes itself available to applications. Thus an application can (more or less) "prove" to a remote machine that the BIOS, kernel, and application are in fact the "approved" versions that the remote machine wants to see. The closest published work would be Bill Arbaugh's dissertation and associated papers. Real security benefit: remote machine can detect that your box has not been rootkit'd. Hoarding "benefit": remote machine can detect that you are running the approved DRM-enforcing media player so that (for instance) it can enforce that you only get to play that movie the specified number of times and you don't get to copy it. Malignant effect: Document master at an organization can make all documents transient, so that whistle-blowers can no longer access the documents they are trying to use to blow the whistle on such as, say, Enron, WorldCom, or Abu Grab-ass. Be very, very careful about tolerating strong-attestation hardware. The implications are profound, for both good and evil. Crispin mudge wrote: > > There was a lady who went to Purdue, I believe her name was Carla > Brodley. She is a professor at Tufts currently. One of her projects, > I'm not sure whether it is ongoing or historic, was surrounding > hardware based stack protection. There wasn't any protection against > heap / pointer overflows and I don't know how it fares when stack > trampoline activities (which can be valid, but are rare outside of > older objective-c code). > > www.smashguard.org and https://engineering.purdue.edu/ > ResearchGroups/SmashGuard/smash.html have more data. > > I'm not sure if this is a similar solution to what Intel might be > pursuing. I believe the original "smashguard" work was based entirely > on Alpha chips. > > cheers, > > .mudge > > > On Dec 13, 2005, at 15:19, Michael S Hines wrote: > >> Doesn't a hardware 'feature' such as this lock software into a >> two-state model >> (user/priv)? >> >> Who's to say that model is the best? Will that be the model of the >> future? >> >> Wouldn't a two-state software model that works be more effective? >> >> It's easier to change (patch) software than to rewire hardware >> (figuratively speaking). >> >> Just wondering... >> >> Mike Hines >> ----------------------------------- >> Michael S Hines >> mshines at purdue.edu >> >> _______________________________________________ >> Secure Coding mailing list (SC-L) >> SC-L at 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 at securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com From mshines at purdue.edu Wed Dec 14 08:40:23 2005 From: mshines at purdue.edu (Michael S Hines) Date: Wed, 14 Dec 2005 08:40:23 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: Message-ID: <001201c600b3$ef2e9030$4fa7d280@OS00009> Isn't Smashguard the same technology (in software) added to the latest Microsoft .NET compiler and run time? While protecting against one method of hijacking a system (altering the function return address) - it really doesn't protect from inserting your own code into a stream and then using an existing jump to jump to your code - does it? Nor does it protect from altering the system managed data blocks? That is to say - it only protects one form of a hijack attack. Or am I missing something? Mike Hines Smashguard most recent CACM publication (Nov 05) is at - https://engineering.purdue.edu/ResearchGroups/SmashGuard/cacm.pdf if you are interested. The Smashguard Group web site is at - https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF.html I'm not affiliated with that group at Purdue - being on the Admin side. ----------------------------------- Michael S Hines mshines at purdue.edu _____ From: mudge [mailto:mudge at uidzero.org] Sent: Tuesday, December 13, 2005 6:01 PM To: Hines, Michael S. Cc: 'Secure Coding Mailing List' Subject: Re: [SC-L] Intel turning to hardware for rootkit detection There was a lady who went to Purdue, I believe her name was Carla Brodley. She is a professor at Tufts currently. One of her projects, I'm not sure whether it is ongoing or historic, was surrounding hardware based stack protection. There wasn't any protection against heap / pointer overflows and I don't know how it fares when stack trampoline activities (which can be valid, but are rare outside of older objective-c code). www.smashguard.org and https://engineering.purdue.edu/ ResearchGroups/SmashGuard/smash.html have more data. I'm not sure if this is a similar solution to what Intel might be pursuing. I believe the original "smashguard" work was based entirely on Alpha chips. cheers, .mudge On Dec 13, 2005, at 15:19, Michael S Hines wrote: Doesn't a hardware 'feature' such as this lock software into a two-state model (user/priv)? Who's to say that model is the best? Will that be the model of the future? Wouldn't a two-state software model that works be more effective? It's easier to change (patch) software than to rewire hardware (figuratively speaking). Just wondering... Mike Hines ----------------------------------- Michael S Hines mshines at purdue.edu _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20051214/fb91d21e/attachment.html From gem at cigital.com Wed Dec 14 09:14:00 2005 From: gem at cigital.com (Gary McGraw) Date: Wed, 14 Dec 2005 09:14:00 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB564F6C@va-mail.cigital.com> No, that's a copy of stackguard. The real problem with all of these approaches is that they don't fix the root problem. Finding and removing buffer overflow conditions with a static analysis tool is far superior. gem -----Original Message----- From: Michael S Hines [mailto:mshines at purdue.edu] Sent: Wed Dec 14 09:03:55 2005 To: 'Secure Coding Mailing List' Subject: RE: [SC-L] Intel turning to hardware for rootkit detection Isn't Smashguard the same technology (in software) added to the latest Microsoft .NET compiler and run time? While protecting against one method of hijacking a system (altering the function return address) - it really doesn't protect from inserting your own code into a stream and then using an existing jump to jump to your code - does it? Nor does it protect from altering the system managed data blocks? That is to say - it only protects one form of a hijack attack. Or am I missing something? Mike Hines Smashguard most recent CACM publication (Nov 05) is at - https://engineering.purdue.edu/ResearchGroups/SmashGuard/cacm.pdf if you are interested. The Smashguard Group web site is at - https://engineering.purdue.edu/ResearchGroups/SmashGuard/BoF.html I'm not affiliated with that group at Purdue - being on the Admin side. ----------------------------------- Michael S Hines mshines at purdue.edu _____ From: mudge [mailto:mudge at uidzero.org] Sent: Tuesday, December 13, 2005 6:01 PM To: Hines, Michael S. Cc: 'Secure Coding Mailing List' Subject: Re: [SC-L] Intel turning to hardware for rootkit detection There was a lady who went to Purdue, I believe her name was Carla Brodley. She is a professor at Tufts currently. One of her projects, I'm not sure whether it is ongoing or historic, was surrounding hardware based stack protection. There wasn't any protection against heap / pointer overflows and I don't know how it fares when stack trampoline activities (which can be valid, but are rare outside of older objective-c code). www.smashguard.org and https://engineering.purdue.edu/ ResearchGroups/SmashGuard/smash.html have more data. I'm not sure if this is a similar solution to what Intel might be pursuing. I believe the original "smashguard" work was based entirely on Alpha chips. cheers, .mudge On Dec 13, 2005, at 15:19, Michael S Hines wrote: Doesn't a hardware 'feature' such as this lock software into a two-state model (user/priv)? Who's to say that model is the best? Will that be the model of the future? Wouldn't a two-state software model that works be more effective? It's easier to change (patch) software than to rewire hardware (figuratively speaking). Just wondering... Mike Hines ----------------------------------- Michael S Hines mshines at purdue.edu _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php ---------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------- From ljknews at mac.com Wed Dec 14 08:50:45 2005 From: ljknews at mac.com (ljknews) Date: Wed, 14 Dec 2005 08:50:45 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: <439FE6FC.80109@novell.com> References: <00db01c60022$7c290930$4fa7d280@OS00009> <439FE6FC.80109@novell.com> Message-ID: At 1:33 AM -0800 12/14/05, Crispin Cowan wrote: > Smashguard, if I recall correctly, offers approximately the protection > of existing compiler methods, but with the added fun of requiring > modified (non-existent) hardware. > > The referenced hardware in the IEEE article and the intel.com pages > appears to be some descendant of Palladium; it is a hardware integrity > checker/attestation mechanism. A small, hardware-enforced core performs > a chain of crypto-checks prior to boot strapping the BIOS, and then the > OS, and makes itself available to applications. Thus an application can > (more or less) "prove" to a remote machine that the BIOS, kernel, and > application are in fact the "approved" versions that the remote machine > wants to see. The closest published work would be Bill Arbaugh's > dissertation and associated papers. That sounds very much like DEC's Distributed Systems Security Architecture, which was never an implemented product. -- Larry Kilgallen From ljknews at mac.com Wed Dec 14 11:03:23 2005 From: ljknews at mac.com (ljknews) Date: Wed, 14 Dec 2005 11:03:23 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB564F6C@va-mail.cigital.com> References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB564F6C@va-mail.cigital.com> Message-ID: At 9:14 AM -0500 12/14/05, Gary McGraw wrote: > No, that's a copy of stackguard. The real problem with all of these > approaches is that they don't fix the root problem. Finding and removing > buffer overflow conditions with a static analysis tool is far superior. But still better is using a programming language that does not allow buffer overflows. -- Larry Kilgallen From gem at cigital.com Wed Dec 14 12:38:49 2005 From: gem at cigital.com (Gary McGraw) Date: Wed, 14 Dec 2005 12:38:49 -0500 Subject: [SC-L] Intel turning to hardware for rootkit detection Message-ID: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB564F78@va-mail.cigital.com> Ah yes. Type safety to all, and to all a good night. gem -----Original Message----- From: ljknews [mailto:ljknews at mac.com] Sent: Wed Dec 14 11:36:20 2005 To: Secure Coding Mailing List Subject: RE: [SC-L] Intel turning to hardware for rootkit detection At 9:14 AM -0500 12/14/05, Gary McGraw wrote: > No, that's a copy of stackguard. The real problem with all of these > approaches is that they don't fix the root problem. Finding and removing > buffer overflow conditions with a static analysis tool is far superior. But still better is using a programming language that does not allow buffer overflows. -- Larry Kilgallen _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php ---------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------- From weld at vulnwatch.org Wed Dec 14 12:38:40 2005 From: weld at vulnwatch.org (Chris Wysopal) Date: Wed, 14 Dec 2005 12:38:40 -0500 (EST) Subject: [SC-L] Intel turning to hardware for rootkit detection In-Reply-To: References: <3F5AB9CDDAD2CC4A80D0FCDCF2755DFB564F6C@va-mail.cigital.com> Message-ID: On Wed, 14 Dec 2005, ljknews wrote: > At 9:14 AM -0500 12/14/05, Gary McGraw wrote: > > No, that's a copy of stackguard. The real problem with all of these > > approaches is that they don't fix the root problem. Finding and removing > > buffer overflow conditions with a static analysis tool is far superior. > > But still better is using a programming language that does not allow > buffer overflows. This isn't a solution to code that is already deployed which is the problem that stackguard and static analysis address. -Chris From dwheeler at ida.org Wed Dec 14 16:40:27 2005 From: dwheeler at ida.org (David A. Wheeler) Date: Wed, 14 Dec 2005 16:40:27 -0500 Subject: [SC-L] Countering Trusting Trust through Diverse Double-Compiling References: <200512140404.jBE44Pkw042323@ratsass.krvw.com> Message-ID: <43A0914B.7030705@ida.org> Everyone here should be familiar with Ken Thompson's famous "Reflections on Trusting Trust." If not, see: http://www.acm.org/classics/sep95/ The "trusting trust" attack subverts the compiler binary; if the attacker succeeds, you're doomed. Well, til now. I've written a paper on an approach to counter this attack. See: "Countering Trusting Trust through Diverse Double-Compiling" http://www.acsa-admin.org/2005/abstracts/47.html You can get data to reproduce this, and some related material, from my personal site: http://www.dwheeler.com/trusting-trust Here's the abstract: "An Air Force evaluation of Multics, and Ken Thompson's famous Turing award lecture "Reflections on Trusting Trust," showed that compilers can be subverted to insert malicious Trojan horses into critical software, including themselves. If this attack goes undetected, even complete analysis of a system's source code will not find the malicious code that is running, and methods for detecting this particular attack are not widely known. This paper describes a practical technique, termed diverse double-compiling (DDC), that detects this attack and some unintended compiler defects as well. Simply recompile the purported source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary. This technique has been mentioned informally, but its issues and ramifications have not been identified or discussed in a peer-reviewed work, nor has a public demonstration been made. This paper describes the technique, justifies it, describes how to overcome practical challenges, and demonstrates it." I think you'll find this interesting. (Note: I posted a similar message to Bugtraq earlier, but I thought some of you might not have seen it.) --- David A. Wheeler From Ken at krvw.com Wed Dec 14 19:41:46 2005 From: Ken at krvw.com (Kenneth R. van Wyk) Date: Wed, 14 Dec 2005 19:41:46 -0500 Subject: [SC-L] Countering Trusting Trust through Diverse Double-Compiling In-Reply-To: <43A0914B.7030705@ida.org> References: <200512140404.jBE44Pkw042323@ratsass.krvw.com> <43A0914B.7030705@ida.org> Message-ID: <200512141941.47006@KRvW> On Wednesday 14 December 2005 16:40, David A. Wheeler wrote: > I've written a paper on an approach to counter this attack. See: > "Countering Trusting Trust through Diverse Double-Compiling" > http://www.acsa-admin.org/2005/abstracts/47.html Thanks for sharing it here, David. > Here's the abstract: > "... Simply recompile the purported source code twice: once with a second > (trusted) compiler, and again using the result of the first compilation. > If the result is bit-for-bit identical with the untrusted > binary, then the source code accurately represents the binary. ..." This reminded me of an old class of PC viruses (circa 1992) that evaded detection by file scanners by hooking the S-DOS file read interrupt and returning the original, uninfected version of infected files whenever a program opened up an infected file for reading. It tricked a lot of file scanners at the time. If I'm not mistaken, it was the DIR-II family of viruses. I'm sure that you've taken that sort of evasive action into account, but I thought that I'd mention it here for the SC-L folks. Heck, by today's rather loose definitions of what a rootkit is, perhaps the DIR-II family was the first malware to feature rootkit-like stealth techniques. Cheers, Ken van Wyk -- KRvW Associates, LLC http://www.KRvW.com From bellovin at acm.org Wed Dec 14 23:10:42 2005 From: bellovin at acm.org (Steven M. Bellovin) Date: Wed, 14 Dec 2005 23:10:42 -0500 Subject: [SC-L] Countering Trusting Trust through Diverse Double-Compiling Message-ID: <20051215041042.91A793C01BF@berkshire.machshav.com> In message <200512141941.47006 at KRvW>, "Kenneth R. van Wyk" writes: > >This reminded me of an old class of PC viruses (circa 1992) that evaded >detection by file scanners by hooking the S-DOS file read interrupt and >returning the original, uninfected version of infected files whenever a >program opened up an infected file for reading. It tricked a lot of file >scanners at the time. If I'm not mistaken, it was the DIR-II family of >viruses. I'm sure that you've taken that sort of evasive action into >account, but I thought that I'd mention it here for the SC-L folks. > And there is, as I recall, a Linux piece of malware that uses a loadable kernel module of some sort to hide a back door in init -- if it's not opened by pid 1, it gives the real file; otherwise, it gives the Trojan'ed version. --Steve Bellovin, http://www.stevebellovin.com From Ken at krvw.com Thu Dec 15 08:59:29 2005 From: Ken at krvw.com (Kenneth R. van Wyk) Date: Thu, 15 Dec 2005 08:59:29 -0500 Subject: [SC-L] Managing the insider threat through code obfuscation Message-ID: <200512150859.29934@KRvW> This morning, an article caught my attention -- "Managing the insider threat through code obfuscation", http://www.itmanagersjournal.com/article.pl?sid=05/12/13/1736253 The article's premise is that, because attackers can find out a great deal about the internals of databases and such by decompiling bytecode (in Java and .NET), bytecode should be obfuscated to hide its internal details. The article points to several commercial bytecode obfuscation products: http://www.devdirect.com/ALL/OBFUSCATIORS_PCAT_2014.aspx I hadn't heard of this approach before, although I'm quite familiar with how easy it is to decompile Java bytecode. My questions for the group are: o Anyone here have any good/bad experiences with bytecode obfuscation? o What is the impact on performance of the bytecode? o How about compatibility with various JVMs? o How much protection do these obfuscators really provide? o Is this all just a bunch of product marketing hooey? Well, at least the article uses the term "threat" correctly... Cheers, Ken van Wyk --- KRvW Associates, LLC http://www.KRvW.com From jose at monkey.org Thu Dec 15 09:26:06 2005 From: jose at monkey.org (Jose Nazario) Date: Thu, 15 Dec 2005 09:26:06 -0500 (EST) Subject: [SC-L] Managing the insider threat through code obfuscation In-Reply-To: <200512150859.29934@KRvW> References: <200512150859.29934@KRvW> Message-ID: On Thu, 15 Dec 2005, Kenneth R. van Wyk wrote: > The article's premise is that, because attackers can find out a great > deal about the internals of databases and such by decompiling bytecode > (in Java and .NET), bytecode should be obfuscated to hide its internal > details. The article points to several commercial bytecode obfuscation > products: http://www.devdirect.com/ALL/OBFUSCATIORS_PCAT_2014.aspx if the person can develop exploits against the holes in the code, what makes you think they can't fire up a runtime debugger and trace the code execution and discover the same things? the biggest threat internally isn't the one or two people per thousand who can and will do this, it's the much larger number of people who wont use exploit development techniques to access things they shouldn't. bytecode obfuscation does nothing to stop that. ________ jose nazario, ph.d. jose at monkey.org http://monkey.org/~jose/ http://infosecdaily.net/ http://www.wormblog.com/ From jeremy.epstein at webmethods.com Thu Dec 15 10:00:38 2005 From: jeremy.epstein at webmethods.com (Jeremy Epstein) Date: Thu, 15 Dec 2005 07:00:38 -0800 Subject: [SC-L] Managing the insider threat through code obfuscation Message-ID: <5B10E50E14A4594EB1B5566B69AD94070C4CA953@maileast> Ken, I looked into this a couple of years ago to protect against intellectual property theft (e.g., reverse engineering) and to make it harder to bypass software licensing techniques. My conclusion at that point was that the obfuscation didn't actually do much good (it was still fairly easy to figure out what was going on). It introduced an extra risky step - our developers want to do their debugging/QA on unobfuscated versions so they can figure out what goes wrong, but you then have to replicate all of your QA on the obfuscated version to make sure that the obfuscator didn't break anything. [I hope that no one would test one version and release another!] And if there was a discrepancy, it was likely to be difficult to find what went wrong. Most importantly for us, it made support a royal pain - stack traces no longer meant anything. And we had to be *very* careful not to obfuscate any published or undocumented-but-known interfaces. My conclusion is that it's better than just marketing hooey - there is some technical advantage - but that if you have an extensible product and/or you have to provide support, the pain is worse than the advantage. --Jeremy > -----Original Message----- > From: sc-l-bounces at securecoding.org > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Kenneth R. van Wyk > Sent: Thursday, December 15, 2005 8:59 AM > To: Secure Coding Mailing List > Subject: [SC-L] Managing the insider threat through code obfuscation > > This morning, an article caught my attention -- "Managing the > insider threat through code obfuscation", > http://www.itmanagersjournal.com/article.pl?sid=05/12/13/1736253 > > The article's premise is that, because attackers can find out > a great deal about the internals of databases and such by > decompiling bytecode (in Java and .NET), bytecode should be > obfuscated to hide its internal details. The article points > to several commercial bytecode obfuscation products: > http://www.devdirect.com/ALL/OBFUSCATIORS_PCAT_2014.aspx > > I hadn't heard of this approach before, although I'm quite > familiar with how easy it is to decompile Java bytecode. My > questions for the group are: > > o Anyone here have any good/bad experiences with bytecode obfuscation? > o What is the impact on performance of the bytecode? > o How about compatibility with various JVMs? > o How much protection do these obfuscators really provide? > o Is this all just a bunch of product marketing hooey? > > Well, at least the article uses the term "threat" correctly... > > Cheers, > > Ken van Wyk > --- > KRvW Associates, LLC > http://www.KRvW.com > _______________________________________________ > Secure Coding mailing list (SC-L) > SC-L at securecoding.org > List information, subscriptions, etc - > http://krvw.com/mailman/listinfo/sc-l > List charter available at - > http://www.securecoding.org/list/charter.php > From Ken at krvw.com Thu Dec 15 10:09:08 2005 From: Ken at krvw.com (Kenneth R. van Wyk) Date: Thu, 15 Dec 2005 10:09:08 -0500 Subject: [SC-L] Managing the insider threat through code obfuscation In-Reply-To: References: <200512150859.29934@KRvW> Message-ID: <200512151009.08548@KRvW> On Thursday 15 December 2005 09:26, Jose Nazario wrote: > if the person can develop exploits against the holes in the code, what > makes you think they can't fire up a runtime debugger and trace the code > execution and discover the same things? Nothing makes me think that at all; in fact, I was quite skeptical of the various product claims, which is why I wanted to hear about others' experience with them. Cheers, Ken -- KRvW Associates, LLC http://www.KRvW.com From bishop at cs.ucdavis.edu Thu Dec 15 11:42:40 2005 From: bishop at cs.ucdavis.edu (Matt Bishop) Date: Thu, 15 Dec 2005 08:42:40 -0800 Subject: [SC-L] Managing the insider threat through code obfuscation In-Reply-To: <200512150859.29934@KRvW> References: <200512150859.29934@KRvW> Message-ID: <43A19D00.3020307@cs.ucdavis.edu> Hi, Ken, > This morning, an article caught my attention -- "Managing the insider threat > through code obfuscation", > http://www.itmanagersjournal.com/article.pl?sid=05/12/13/1736253 > > The article's premise is that, because attackers can find out a great deal > about the internals of databases and such by decompiling bytecode (in Java > and .NET), bytecode should be obfuscated to hide its internal details. The > article points to several commercial bytecode obfuscation products: > http://www.devdirect.com/ALL/OBFUSCATIORS_PCAT_2014.aspx I heard about code obfuscation in the late 1970's. A friend (and fellow student) in my graduate program said a company he worked at did exactly that. But the goal was *not* security; it was copyright protection. If anyone copied their binary, and claimed to have written it independently (and so did not need to pay a licensing fee), the company could easily prove to a court that the other user had not written it on their own by showing the convoluted logic in the program. I don't remember if he said they ever actually had to do this in court, but it seemed a pretty effective way to trace code lineage. The application was not one in which speed was critical, so the loss of speed due to the obfuscation was apparently tolerable (if not unnoticeable). I don't remember the language involved, but suspect pretty strongly it was *not* Java, because our discussion was some 15-20 years before Java was released ... :-) Cheers to all! Matt From dana at vulscan.com Thu Dec 15 12:49:07 2005 From: dana at vulscan.com (Dana Epp) Date: Thu, 15 Dec 2005 09:49:07 -0800 Subject: [SC-L] Managing the insider threat through code obfuscation References: <200512150859.29934@KRvW> <200512151009.08548@KRvW> Message-ID: <9AE3FC06F0A89A43A4D6F667955082C46F52@sbsmain.Vulscan.local> There are no absolutes here. Obfuscation has its place. I use Xenocode's Obfuscator for my .NET code. I do not do it to try to hide bad code from intense scrutiny from potential attackers. I do it to hide business logic from the looky-loos who have tools like Reflector and may want to blatently rip it off. (which has happened before) Weighing my risks accordingly, I expect that once the byte code is converted to native instructions on the target system, that any competent person can easily look at the disassembly and do their bidding. If they are gods with disassemblers, all the power to them. But they can do that with any code on the system, be it driven from bytecode converted to native or directly linked with the linker. So the threat level is the same at that point. Obfuscation is just another layer of defense for business logic from what I would consider 'layer one' attackers. Depending on the tools you use it can work, and work well. It's designed to mitigate against a certain type of threat. However, anyone with enough patience, a copy of Gary and Greg's "Exploiting Software" and a copy of IDA Pro will be able to break the shackles of such tools and get deep into the bowels of the executing code. Nothing is going to stop that. Now let's look at your original example of being able to get a great deal of information about the internals of databases etc. The reality is that such information shouldn't be IN the application in the first place. When possible secrets like db passwords should use the native operating system's security mechanisms (ie: Trusted connections, Windows Authentication, DPAPI etc when working on Windows) to store and manage credentials. Rather that concatinating query strings (which are harder to obfuscate btw) try to use things like stored procedures (where appropriate) that keeps the db structure on the server while at the same time giving another layer of validation control for input. I know I am preaching to the choir here. My point is that no matter what the language is, and what the threat is you are expecting to mitigate against, different tools can do different things. Obfuscation has it's place. As does a deep hole, some cement and a shovel. You can dig your own bunker however you see fit. How strong you make it depends on what sort of attack you are fretting about. --- Regards, Dana Epp [Blog: http://silverstr.ufies.org/blog/] ________________________________ From: sc-l-bounces at securecoding.org on behalf of Kenneth R. van Wyk Sent: Thu 12/15/2005 7:09 AM To: Jose Nazario Cc: Secure Coding Mailing List Subject: Re: [SC-L] Managing the insider threat through code obfuscation On Thursday 15 December 2005 09:26, Jose Nazario wrote: > if the person can develop exploits against the holes in the code, what > makes you think they can't fire up a runtime debugger and trace the code > execution and discover the same things? Nothing makes me think that at all; in fact, I was quite skeptical of the various product claims, which is why I wanted to hear about others' experience with them. Cheers, Ken -- KRvW Associates, LLC http://www.KRvW.com _______________________________________________ Secure Coding mailing list (SC-L) SC-L at securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://krvw.com/pipermail/sc-l/attachments/20051215/4e39806a/attachment.html From james.stibbards at cloakware.com Thu Dec 15 16:25:36 2005 From: james.stibbards at cloakware.com (James Stibbards) Date: Thu, 15 Dec 2005 16:25:36 -0500 Subject: [SC-L] Managing the insider threat through code obfuscation Message-ID: <200512152125.jBFLPkQF010196@mail.cloakware.com> Hi Jeremy (and Ken), Obfuscation of Java bytecode (like other "machine-level" instruction sets) will ultimately depend on what level of hiding is being done. Principally, whether you're really just scattering the data (i.e. using a secret scatter algorithm), or actually encrypt/decrypting it, it then moves the problem to being one of secure key gen/storage/usage. My company - Cloakware - is firmly planted in the "software protection" field, focusing on hardening of Digital Rights Management and other content and IP protection system, for our customers. We have IP in the area of secure key storage, called "White Box Crypto", which solves the probem well for normal (read: all but the intel-grade needs). We use a variety of techniques - currently in C and C++, and will be extending that to include Java shortly. The techniques have varying impacts on code-size and/or performance-preserving, with associated tradeoffs against security level/strength of mechanism. As you point out - if the goal is to hide the data and/or implementation at runtime, then traditional support can be a problem. Stack traces - if you can get them from within an "anti-debug" enabled application or driver, may tell you very little (by design). I do know of one "obfuscator" that also has a free downloadable "anti-obfuscator" tool available so that customers can debug their applications. Make me wonder, what they were thinking... that attackers wouldn't notice? Let me know if you'd like to be part of the discussion as our Java work rolls out, and I'll set up a briefing. Hoping this is an "acceptably tasteful" posting from a vendor... :) Regards, - James James W. Stibbards Director, Systems Engineering Cloakware Federal "secure software ... from the inside out" 703.752.4836 office 571.232.7210 cell Previous message: ---------------------------------------------------------------------------- ---- Jeremy Epstein jeremy.epstein at webmethods.com Thu Dec 15 10:00:38 EST 2005 Ken, I looked into this a couple of years ago to protect against intellectual property theft (e.g., reverse engineering) and to make it harder to bypass software licensing techniques. My conclusion at that point was that the obfuscation didn't actually do much good (it was still fairly easy to figure out what was going on). It introduced an extra risky step - our developers want to do their debugging/QA on unobfuscated versions so they can figure out what goes wrong, but you then have to replicate all of your QA on the obfuscated version to make sure that the obfuscator didn't break anything. [I hope that no one would test one version and release another!] And if there was a discrepancy, it was likely to be difficult to find what went wrong. Most importantly for us, it made support a royal pain - stack traces no longer meant anything. And we had to be *very* careful not to obfuscate any published or undocumented-but-known interfaces. My conclusion is that it's better than just marketing hooey - there is some technical advantage - but that if you have an extensible product and/or you have to provide support, the pain is worse than the advantage. --Jeremy From info at secappdev.org Wed Dec 21 14:38:10 2005 From: info at secappdev.org (Johan Peeters) Date: Wed, 21 Dec 2005 20:38:10 +0100 Subject: [SC-L] secure application development course Message-ID: <43A9AF22.3040602@secappdev.org> Katholieke Universiteit Leuven organizes an intensive secure application development course for experienced software practitioners, in partnership with Solvay Business School and L-Sec (Leuven Security Excellence Consortium) from February 20th to 24th 2006 in Leuven, Belgium. The course is aimed at software architects, designers, developers, testers and technical project managers and is limited to 25 places for optimal interaction.Leading world experts teach this course, including prof. dr. ir. Bart Preneel, who heads COSIC, the renowned crypto lab, prof. dr. ir. Frank Piessens, who pioneered teaching secure software development at university level, Ken van Wyk, co-founder of CERT Coordination Center and author of the widely acclaimed O'Reilly book "Secure Coding: Principles and Practices" and Danny De Cock whose web site is recognized as the foremost repository of technical information on the Belgian eID card. The course focuses on secure software engineering principles and techniques for countering threats and vulnerabilities in today's target environments. It provides participants with a thorough preparation for secure application development. Participants who complete the course will be able to: * Use mainstream security technologies, * Identify security related requirements, * Design secure application architectures, * Design cost-effective security features, * Avoid coding vulnerabilities, * Ascertain security qualities in existing applications. In order to benefit optimally from the course, participants must have a working knowledge of most of the following: * An unmanaged programming language such as C or C++; * A managed programming language such as Java or C#; * Key Internet applications such as mail, directory services, network file systems, remote procedure calls. For further information and registration details, visit http://www.secappdev.org. -- Johan Peeters program director http://www.secappdev.org +32 16 649000