[SC-L] interesting presentation
from dawson engler's group: http://www.stanford.edu/~engler/softmc03-talk.pdf evaluates various checkers in various settings. ___ jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/ http://infosecdaily.net/
Re: [SC-L] Re: Application Sandboxing, communication limiting, etc.
SELinux. LIDS. systrace (Linux, BSD, MacOS X). a few things on FreeBSD i can't recall. i dont know what exists for the average user on Windows at the application level, but i do know that personal firewalls can help. untrusted programs can't access the network, either as a server or as a client. i know a few products exist for servers, typically restricted to server programs (ie IIS). so, some work is being done on that front, not enough yet. bear in mind that, just like with comcast's behavior restriction system making the FD news lately, power users of systems will complain and be annoyed when they find their access suddenly fettered. ___ jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/ http://infosecdaily.net/
Re: [SC-L] auditing
some advice ... look for tools to generate callgraphs from dynamic (runtime) analysis and static (run them over the compiler binary or the source code) analysis. graphing those relationships can be useful. one example: http://monkey.org/~jose/graphing/syscalls/ look for tools to do control flow analysis, again static or dynamic. build an annotated C library that you can use to preload and watch execution while the program runs (assuming you only have a binary available on a UNIX platform, i would't know how to do this on windows). invoke some of the old software cracker tricks ... look for tools to do known hole analysis, they can be as simple as grep or as complex as you can imagine ... this page has a few links to some tools at teh bottom which may be useful: http://www.dwheeler.com/flawfinder/ (several easy to use tools of varying sophistication are listed in these): http://www.linuxjournal.com//article.php?sid=5673 http://www.ida.liu.se/~johwi/research_publications/paper_nordsec2002_john_wilander.pdf http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf http://www.cs.berkeley.edu/~pbwell/papers/saswifi.pdf etc etc etc ... frankly the hard part if identifying the right terms to use. once you do that you're all set. big kudos to david wheeler for maintaining a nice repository of links (along with flawfinder, a pretty decent first pass tool). even more links to even more tools and techniques (scan the whole page): http://osq.cs.berkeley.edu/ remember. automated tools will only catch the things you already knew about. they help because they don't get tired, see cross eyed (typically), and can be fast. they fail because they're easy to confuse, they only work on what you know, and get prohibitively difficult to write and use for large forms of analysis. it's a hot topic, has attracted some of the best and brightest, and is a fertile area for all levels of research. if you're serious about studying it, learn compiler internals as a means to learn model building, study the language specification (spot the ambiguities is a fun game to play) and start hacking tools. dilligance, dilligance, dilligance. jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/
[SC-L] opinion, ACM Queue: Buffer Overrun Madness
thought some of you may find this editorial from the May 04 ACM Queue worth a read. ACM Queue is an interesting magazine and has a website at acmqueue.org. Buffer Overrun Madness ACM Queue vol. 2, no. 3 - May 2004 by Rodney Bates, Wichita State University Why do good programmers follow bad practices? In January 2003, the Slammer worm was reported to be the fastest spreading ever. Slammer gets access by exploiting a buffer overrun. If you peruse CERT (Computer Emergency Readiness Team) advisories or security upgrade releases, you will see that the majority of computer security holes are buffer overruns. These would be minor irritations but for the world's addiction to the weakly typed programming languages C and its derivative C++. jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/
Re: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
rather than talking in a vacuum, make sure you've read the latest ACM/IEEE-CS curriculum guidelines: http://www.acm.org/education/curricula.html http://sites.computer.org/ccse/ reputable undergrad institutions will focus on this, and many pre-college programs will teach preparing students for this (ie language choices and topic choices). enjoy. jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/
Re: [SC-L] Education and security -- another perspective (was "ACM Queue - Content")
BB and i chatted offline, so let me make my points more clearly: - have a look at what languages are being taught, it's been a while since some of us have looked. - if you don't like what you see, get involved. ie make sure security is listed and taught. ____ jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/
[SC-L] [paper] Model Checking One Million Lines of C Code
[Ed. I'm re-posting this, since it looks like I made a stupid typo the first time, which lead to the munging of the message's headers. Sorry for the inconvenience. This one should be correct... KRvW] an interesting paper. the authors evidently have made MOPS an addon package to GCC, which is something i've advocated before (make tools easy to use and integrated with the build environment). http://www.cs.berkeley.edu/~hchen/paper/ndss04.html Authors Hao Chen, Drew Dean, and David Wagner. Source Proceedings of the 11th Annual Network and Distributed System Security Symposium (NDSS), San Diego, CA, February 4--6, 2004. Abstract Implementation bugs in security-critical software are pervasive. Several authors have previously suggested model checking as a promising means to detect improper use of system interfaces and thereby detect a broad class of security vulnerabilities. In this paper, we report on our practical experience using MOPS, a tool for software model checking security-critical applications. As examples of security vulnerabilities that can be analyzed using model checking, we pick five important classes of vulnerabilities and show how to codify them as temporal safety properties, and then we describe the results of checking them on several significant Unix applications using MOPS. After analyzing over one million lines of code, we found more than a dozen new security weaknesses in important, widely-deployed applications. This demonstrates for the first time that model checking is practical and useful for detecting security weaknesses at large scale in real, legacy systems. ____ jose nazario, [EMAIL PROTECTED] http://monkey.org/~jose/ http://infosecdaily.net/
[SC-L] interesting articles on secure coding
found on InformIT.com: It never seemed to matter how the software we used was made. It didn't seem to matter much who made it either. We just grabbed it unquestioningly. That's changing. Today's software can definitely be bad for you, whether it's due to viruses, spyware, dialers, bugs, or merely baroque license agreements. Today you can hardly tell whether a particular piece of software is going to be good for you.or not. Source: Searching for Substance: The Road to Safe Software http://www.informit.com/articles/printerfriendly.asp?p=334819 Date: Sep 3, 2004 By Nigel McFarlane. - Everybody can use more secure code.and sometimes the best way to hone your skills is to listen to other programmers. Here are 18 concise tips offered by your fellow developers, each a specific (and opinionated!) piece of advice that you can put to work immediately. You may not agree with all these suggestions, but each is worth contemplating. Tipping the Scales Toward Secure Code http://www.informit.com/articles/printerfriendly.asp?p=332879 Date: Oct 1, 2004 By Rebecca Rohan. some interesting stuff has been posted there, look around and maybe something interesting will pop up. ____ jose nazario, ph.d.[EMAIL PROTECTED] http://monkey.org/~jose/ http://infosecdaily.net/
[SC-L] Former cybersecurity czar: Code-checking tools needed
FYI ... jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/ http://www.computerworld.com/securitytopics/security/story/0,10801,97988,00.html By Grant Gross DECEMBER 02, 2004 IDG NEWS SERVICE WASHINGTON -- Software vendors need automated tools that look for bugs in their code, but it may be a decade before many of those tools are mature and widely used, said the former director of cybersecurity for the U.S. Department of Homeland Security. Creating software assurance tools was one long-term focus of the DHS National Cybersecurity Division during Amit Yoran's tenure there, Yoran said today during the E-Gov Institute Homeland Security and Information Assurance Conferences in Washington. About 95% of software bugs come from 19 "common, well-understood" programming mistakes, Yoran said, and his division pushed for automation tools that comb software code for those mistakes. "Today's developers ... oftentimes don't have the academic discipline of software engineering and software development and training around what characteristics would create flaws in the program or lead to bugs," Yoran said. Government research into some such tools is in its infancy, however, he added. "This cycle will take years if not decades to complete," he said. "We're realistically a decade or longer away from the fruits of these efforts in software assurance." Yoran, who resigned from his DHS position in September after being on the job for a year, hinted at why he left, but sidestepped a question about the reasons. In the private sector, he had a "real objective" on how to move forward, he said. "When you move into a strategic and somewhat ill-defined role of 'protect cyberspace,' that's a very difficult mission to get your arms around," he said. "You show up to work on a Monday morning, you're ready to put your fingers to the keyboard, you've got a team of folks working with you, what do you do ... to secure cyberspace from within the Department of Homeland Security?" Most Internet resources are owned by the private sector, and the U.S. government has been hesitant to pass cybersecurity mandates, noted Yoran, former vice president of worldwide managed security services at Symantec Corp. With no operational or regulatory control over most of the Internet, the goal of securing cyberspace at DHS was difficult, he said. Asked if that lack of authority was a reason for leaving the post, Yoran said his successor will need to "look at go-forward issues" in cybersecurity that the division can best address. Yoran, however, defended President George W. Bush's National Strategy to Secure Cyberspace, released in February 2003. The strategy, which sets out five major cybersecurity recommendations, did not advocate regulation, and the White House took the right approach in developing those recommendations by consulting with private industry, Yoran said. "As the Department of Homeland Security ... implementing the national strategy is not our job; it's not our responsibility," he said. "It's the nation's job, it's the international technology community's job and responsibility. We can just help." The national strategy and efforts at DHS can help move cybersecurity efforts beyond the current "cat and mouse game" of finding vulnerabilities, assessing whether to patch them, and patching them when the problems become painful to companies, Yoran said. He predicted a "radical transformation" in the cybersecurity field within two to four years as more companies and government agencies accept technologies such as Web services, remote Internet access and RFID (radio frequency identification) tags. "In the next two to three years, you won't be able to define where your network begins and ends," Yoran said. "The paradigms we rely on today for protecting our information -- stronger firewalls, more accurate intrusion detection -- those types of technologies will be required, but they will be solving an increasingly small percentage of the challenges that are going to be facing us."
Re: [SC-L] Managing the insider threat through code obfuscation
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. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/ http://www.wormblog.com/ ___ 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] eWeek says "Apple's Switch to Intel Could Allow OS X Exploits"
some docs on buffer overflows on PPC: http://www.xfocus.org/documents/200408/5.html also: "The independent data and instruction caches of the PowerPC processor can cause a variety of problems with exploit and shellcode development." source: http://www.uninformed.org/?v=1&a=1&t=txt by HD Moore in short it's not quite as straightforward as it seems, but obviously possible, and that has been one of the hindrences to people developing attacks for the chip. unfortunately, there is no shortage of bugs to exploit on most common PPC OSes (AIX, OS X mainly). jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/ http://www.wormblog.com/ ___ 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] eWeek says "Apple's Switch to Intel Could Allow OS X Exploits"
a couple of technical resources i forgot: http://www.phrack.org/phrack/63/p63-0x10_PowerPC_Cracking_on_OSX_with_GDB.txt Reverse engineering - PowerPC Cracking on OSX with GDB http://www.phrack.org/phrack/63/p63-0x05_OSX_Heap_Exploitation_Technqiues.txt OS X heap exploitation techniques jose nazario, ph.d. [EMAIL PROTECTED] http://monkey.org/~jose/http://infosecdaily.net/ http://www.wormblog.com/ ___ 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
