Attacks against security components have been fairly common on server operating systems for decades; on PC’s this wasn’t always necessary because of security models that resembled swiss cheese. Since the beginning of the 21st century, Microsoft has been working diligently to close obvious holes (for the most part.) As a result, researchers have shifted their focus to the attack surface of security-centric code on PC’s. Case in point; in the past several years we’ve seen loads of advisories released for vulnerabilities in anti-virus software. Read the Yankee Group’s “Fear and Loathing in Las Vegas: The Hackers Turn Pro” for a more in-depth analysis of this trend. One area in particular where I feel PC protection is lacking is automated software security update mechanisms; there is a lot of room for improvement.

According to Hewlett-Packard, Digital Equipment Corporation was the first in the industry to perform patch delivery in 1983. Prior to this, updates were commonly delivered on tape by private courier. At one of 2600’s HOPE conferences, Kevin Mitnick spoke about an analog attack he had used to compromise this process during the social engineering panel. The gist of it was that he wore a UPS uniform (procured from a costume store) and delivered the “update” tape to his mark with a login trojan on it. Later, Mitnick became known for using SYN floods and TCP hijacking against Tsutomo Shimomura. Some sources even refer to this sort of digital man-in-the-middle as “The Mitnick Attack.”

Many software update components don’t use public key infrastructure to cryptographically verify the validity of the update server (i.e. SSL) or the updated package (i.e. digital signature.) This is a problem. Impersonating the software update server is usually trivial. Wi-Fi access point impersonation, DNS cache poisoning, ARP spoofing, session hijacking, and compromising the legitimate update server are all possibilities.

Some applications–I’m not going to name any names–rely on HTTP (note that I didn’t say HTTPS) for downloading packages after checking for updates instead of using a separate file transfer manager program or internal update component. This is much easier to reverse engineer than a custom update solution. Sometimes the attacker can allow the real update server to carry out most of the process and simply shoehorn their malcode into the update session(s) after initial preconditions are met.

SSL won’t save the day either unless it’s implemented properly. I’ve seen plaintext updaters with digital signatures that are safer than some HTTPS updaters. Apple Software Update is a good example of an effective plaintext digital signature approach. See SECOBJADV-2008-01 (CVE-2008-3249) for a description of a software updater with an erroneous SSL implementation.

The issue is further complicated because software updaters themselves need to be updated in order to resolve such vulnerabilities. Typically this requires a major architectural modification. What’s worse is that breaking the updater would force users to manually update. Hoyvin-Glayvin!

When you think about it, time really is all we have. It’s what you have at your disposal, to do anything and everything. It seems that we’re better off not knowing when it comes to security–for our own good. Can it really be so utilitarian?

To anybody out there writing exploits: make sure you’re doing it just for fun. Currently, there are no outlets for any financial gain that will accurately measure your time investment or fairly compensate your hard work.

Security Objectives’ own Shane Macaulay “owned” Vista SP1 in the PWN2OWN contest at CanSecWest 2008 by exploiting a bug in Adobe Flash. As a result of the contest’s categorization of the bug as third-party, the exploit was grossly under-appraised (especially when considering cross-platform targets and the fact that it would work well into the future with Vista’s new Service Pack.) Sure, it technically was a bug in a third-party application, but this particular third-party application happens to be installed on just about every Internet-enabled PC. According to Adobe, “Adobe® Flash® Player is the world’s most pervasive software platform, used by over 2 million professionals and reaching over 98% of Internet-enabled desktops in mature markets as well as a wide range of devices.”

Even if Shane was unfairly compensated, it doesn’t matter because at least he used “responsible disclosure” — or does it? I highly doubt that the people in charge of the companies writing buggy software and brokering bug information have any idea about the amount of work and skill that goes into discovering an exploitable bug, let alone writing a proof-of-concept for it. As it stands, software companies are setting themselves up for a black market in digital weapons trading of unprecedented proportions.

Here’s something else to think about.. I expect Adobe to patch this one rather quickly given all the publicity. How long does it take for a vendor to fix a given vulnerability when it is reported to them directly? Even some of the brokered “upcoming advisories” on 3Com’s ZDI site are many months or even years stale. This “patchtile dysfunction” will increase the value of a 0-day exploit exponentially.

Time is money and to make up for lost time, Mr. Macaulay decided to sell the laptop he had won on eBay. An innocent bystander at the contest dubbed this decision “from pwn to pawn.” So why not? Laptops get sold on eBay everyday–but not this one. It wasn’t long before eBay pulled Mr. Macaulay’s item from auction on the first of April, ostensibly as an April Fool’s shenanigan. This came as a surprise to me. Things to consider here:

• The laptop may or may not have had forensic evidence of the controlled attack that occurred during the contest.
• Even so, Mr. Macaulay is a responsible discloser and would not have shipped the laptop until the bug was patched.
• Mr. Macaulay’s and Mr. Sotirov’s autographs should have increased the laptop value, regardless.

This incident, in a way, reminded me of eBay’s great fearwall debacle from a few years ago (CVE-2005-4131.) In that case, there were several key differences: an information broker such as ZDI was not involved, a pseudonym was being used, the code statements where the memory corruption occurred were disclosed, and no computer hardware was for sale. Nevertheless, I respect eBay’s decision to discontinue the auction as this is obviously a very controversial issue.

Brokering information? How can you do it? From experience, the idea of using an escrow service and 3rd party verification is largely ineffective. It would appear that ZDI is the only show in town. Of course there’s that auction service, but you have to send them your exploit first so how does that work? It appears that they’re still trying to do business by the way, despite alleged legal troubles. I’m subscribed to their mailing list and they send out an e-mail every time new information goes up for auction; they put up a dozen or so new exploits last week but it would appear that few if any were sold. Where do we go from here? Is brokering information even possible?

Imagine for a moment a scenario where a dozen or so exploits of critical severity related to a single software company are posted to Full Disclosure with rumors of many more circulating in the underground and exploits actively being carried out in the wild. Now imagine shareholders shorting that company’s stock. I suppose that the vulnerability information might be more realistically valued in a situation such as this. Anyone have any other ideas?

Having just caught up on some of the conference “Source Boston”, I can’t help but call out some of the musings of Andrew Jaquith. Something of a more technical abstract can be read at the code project’s article by Jeffrey Walton (pay special attention to Robin Hood and Friar Tuck). If anybody doubt’s the current trend of sophistication in malware, I’m sure it is somebody who is currently penetrated. I’ve had the opportunity to devote specific analysis on occasion over the years to MAL code and its impact on the enterprise. I know FOR SURE the level of sophistication is on the rise. One thing I had to deal with recently, the extent of capability afforded by most desktop OS’s being so advanced, the majority of functionality desired by MAL code is pre-deployed. Unfortunately paving the way for configuration viruses and their ability to remain undetected in that all they are is an elaborate set of configuration settings. You can imagine, a configuration virus has the entire ability of your OS at its disposal, any VPN/IPSEC, self-(UN) healing, remote administration, etc… The issue is then, how do you determine if that configuration is of MAL intent, it’s surely there for a reason and valid in many deployments. The harm is only when connected to a larger entity/botnet that harm begins to affect a host. Some random points to add hard learned through experience;

• Use a native execution environment
  • VMWare, prevents the load or typical operation of many MAL code variants
    • I guess VM vendors have a big win here for a while, until the majority of targets are VM hosts.
• Have an easily duplicated disk strategy
  • MAC systems are great for forensics, target disk mode and ubiquitous fire-wire allows for live memory dumps and ease of off-line disk analysis (without a drive carrier).
  • I’m planning a hash-tree based system to provision arbitrarily sized block checksums of clean/good files, useful of diff’ing out the noise for arbitrary medium (memory, disk, flash).
• Install a Chinese translator locally
  • As you browse Chinese hack sites, (I think all Russian site’s are so quiet these days due to the fact that they are financially driven, while Chinese are currently motivated by nationalistic motivators), you need to translate locally. Using a .com translation service is detected and false content is rendered, translate locally to avoid that problem.
    • Also, keep notes on lingo.. there are no translation-hack dictionaries yet. (I guess code pigeon is referring to a homing pigeon, naturally horse/wood code is a Trojan).

Unfortunately part of the attacker advantage is the relatively un-coordinated fashion defenders operate, not being able to trust or vet your allies to compare notes can be a real pain. One interesting aspect of a MAL system recently analyzed was the fact that that it had no persistent signature. It’s net force mobility so complete, that the totality of its functionality could shift boot-to-boot, so long as it compromised a boot-up driver it would rise again. The exalted C. Brown put it best, “Good grief!” http://www.codeproject.com/KB/cpp/VirusProtect.aspx http://www.sourceboston.com/blog/?p=25

Microsoft Security Bulletin

MS08-010 – Critical CVE-2008-0076

None of the flaws I’ve ever found on Microsoft platforms have ever been public (that is, they have all been derived from internal projects) and it’s nice to see at least in this round of fixes that my bug scored a perfect 10.0 (a dime) on the bulletin. I actually did not test as many platforms and configurations as Microsoft. For those of you that are unaware, bug regression and the overall triage process can become quite intensive. I knew that this vulnerability/flaw/bug/exploit/whatever had wide reaching appeal, fairly easy to see from the fact that all architectures and versions as far back as possible are marked critical.

As with all doings in the security space, walking a line between disclosure and tight-lipped mums, the word practice is not easy. So, what can be said here? Nothing? Something? I guess I have to write something, the marketoid’s wouldn’t be happy if I did not.

Before I digress into any technical discussion, I will take this opportunity to say something about the exploit sales “industry?”. In this world, everything and everybody has their place, that said, any individual that thinks exploits are worth any money, has another thing coming. Look at it this way, if you’re in the business of purchasing information (exploits), by definition you are unaware of the value of that information thereby inherently you are in a position to devalue the time and emotional investment into the derivation of that work. So this means, you’re never going to get back enough cash to make up for your time, EVER!! Where I do see some value in exploit brokers, is exclusively in the capacity of having them take the burden of dealing with uninformed software vendors (the Microsoft/IBM/others process is fairly straight forward).

Now that that’s all done with, I don’t really want to talk about the exploit, at least until some poorly constructed version winds up in metasploit. I will say though that the bulletin is correct in its description and synopsis.

The fact that there are no mitigating factors or workarounds possible, gives me some incentive and reassurance that the tools and methodologies that we’re building into our product offering works.

We’re ramping up development for a big push this quarter and will be uploading some more screenshots and related minutia in the coming months.

Our product in brief is an automated tool for native application flaw finding. It can assess, at runtime in a dynamic way, the integrity of a given binary application. This process then produces test cases and reproductions of what is necessary to trigger the flaw for a developer (this way, reducing regression rates due to bug fixes as it’s much easier to fix something when you can interact with it as opposed to a simple warning message).

We’re working on a management interface (on top of the technical one), that will also enable the lay person to identify architectural problems in arbitrary software also. This is actually quite simple (with the support of our engine), in essence, a landscape or tomography view is laid out before the user, with associated peaks and valleys, this then changes over time (4D), and represents the surface area of your application binary’s response to input. That is, a dynamic environment that is rooted by a system of systems methodology. What becomes apparent is that (if you are in the capacity to fix these issues yourself), as time goes on, and you assign various resources (people) to fix the peaks and turn them into valley’s. The rate at which you push down the peaks (bugs), across the application is not constant, some issues are harder to fix than others and persist. This way, a self-relative understanding of where problem area of code exist poignantly reveal themselves as architectural flaws and appropriate steps can be taken to drive the business case that will support a rewrite.

Whew, that’s a mouthful. Needless to say, we’re working to create the best platform around for software sovereignty.

A widely held notion among computer scientists is that 80% of a programmer’s time is occupied maintaining code while the other 20% is spent actually writing the software. This inefficient allocation of effort was the subject of a master’s thesis at the Lund Institute of Technology called “Formalizing Use Cases with Message Sequence Charts.” According to a 2002 NIST study entitled “The Economic Impacts of Inadequate Infrastructure for Software Testing“, the annual cost of testing and fixing buggy software in the U.S. is estimated to be between $22.2 and $59.5 billion. What are the root causes of this costly inefficiency?

Unfortunately, corporate culture is naturally a contributing factor for this problem. Companies that produce commercial software are in business to make a profit first and foremost. Release schedules are expedited so the program can be released to market quickly and copies are sold sooner rather than later–making code work as expected for baseline use cases takes priority over regression testing. Any aspect of the software development process that does not appear to be fully in-line with company interests is considered a waste. Usually, far too much emphasis is put on project progress. The overall progress is only perceived progress because unforeseen problems will inevitably pop-up later on. In the long run, bugs end up costing much more to fix down the road and the entire business apparatus pays the cost of maintenance. Some secondary losses are customer support costs, internal communications and a negative impact on the company’s public image all of which can be preempted by proper preliminary work.

Since there’s so much emphasis on speedy release code writing starts as soon as possible, often with disregard to planning ahead beforehand and ensuring quality afterwards. Furthermore, programmers tend to implement items that they are most familiar with first because it seems like the easy way to do things. In most cases, the most difficult parts of a task are best handled first, not last. Handling the difficult items first allows more time and attention to the important stuff; it also allows the developer to recognize how the simpler pieces will fit into the grand scheme of things.

Planning ahead is an essential during the inception phase of a software project. Appropriately analyzing the problem and carefully designing the solutions will minimize the accumulation of technical hardships in the future. In fact, by taking advantage of the popular Unified Process for software development and diagramming specifications in UML the need for writing code almost disappears. UML CASE tools such as IBM’s Rational Rose will translate UML diagrams into program source code (typically an object-oriented language such as C++ or Java.) Of course creating detailed requirements and specifications is still extremely helpful even if UML is not practical for the task at hand. Writing code early on gives the illusion that progress is being made but in reality it is a recipe for disaster. No code should be written until all implementation issues have been resolved.

Threat modeling and secure design principles need to be key focal points during the initial phases of a software project. After the code has been written security issues will also comprise a large chunk of ongoing maintenance work. When software developers handle security fixes they have to stop what they’re doing, modify or maybe even rewrite the offending code, test the new code, report their progress, etc. Since developers are rarely security specialists, they tend to write fixes in such a way that the security hole is not closed completely. As a result, the vulnerability persists and leads to more code rewriting. This cycle of stopping, rewriting, and continuing severely detracts from productivity in programming. The majority of a developer’s time should be spent doing what they do best–adding new features to software.

Removing developers from the patch creation process significantly increases their utilization. Dedicated security experts are most fit to create patches and conduct regression testing. A dynamic program analysis tool accelerates the regression testing process. Building security in by default from the ground-up will minimize software bugs along with subsequent patching and testing. In conclusion, proper planning, resource allocation, and testing procedures can greatly reduce the costs associated with software regression.

I’ve been studying combinatoric methods of generating test cases for quite some time now. Most publicly available fuzz testing packages implement fairly crude techniques for passing input values to applications–although recent research is becoming more creative in attacking the issue because of insufficient path coverage metrics by orthodox methods. Generating input sets combinatorially is a much more holistic approach to the black-box software testing paradigm.

In this article, I’ll be providing a brief overview of how set operations taken from the field of discrete mathematics can be applied to fuzz testing. Explicit definitions of set operations can be found elsewhere and links to Wikipedia are provided where appropriate. Brief explanations on set theory will be given here but I will mainly be focusing on how it relates to software testing.

Let’s start off with permutations; just about any computer science bachelor is familiar with these. They’re the possible orderings of a sequence. A “sequence” may consist of members that are non-unique (which is in contrast to a “set” whose members are unordered and unique.) For example, the permutations of sequence {1,2,3} are:

{{1,2,3},{1,3,2}, {2,1,3},{2,3,1},{3,1,2},{3,2,1}}

Easy enough. Permutations can be used when testing protocols where the order of commands is significant. For example, if testing the FTP protocol with a sequence of {”STAT .”,”CWD ..”,”MKD foo”} - depending on the order in which the commands are executed, the client could be retrieving the status for and/or making the “foo” directory in the parent/child directories.

Sets of subsets (also known as combinations) are also quite useful and are expressed using what’s called “n-choose-r” notation because r elements are being chosen from a set that has n elements in total (the set is said to have cardinality n.) Combinations can be utilized to enumerate command-line argument possibilities since the order of argv values is usually irrelevant. Say an executable has the command line flags “-n”, “-i”, “-q”, and “-v”. We want to generate all subsets of cardinality 2 (4-choose-2.) The answer is:

{{”-n”,”-i”},{”-n”,”-q”},{”-n”,”-v”},{”-i”,”-q”},

{”-i”,”-v”},{”-q”,”-v”}}

r-permutations are similar to subsets in that a given amount of objects are chosen from the list but since permutations are represented as sequences the order of the elements matters. Using the same baseline sequence as the previously described n-permutations, the 2-permutations of {1,2,3} are as follows:

{{1,2},{2,1},{1,3},{3,1},{2,3},{3,2}}

Again, observe how these permutations would affect the logic of network protocol commands processed by a server daemon..

Moving on, a power set is the set of all subsets including the empty set. Using the example above, the power set of {”-n”,”-i”,”-q”,”-v”} looks like this:

{{},{”-n”},{”-i”},{”-q”},{”-v”},{”-n”,”-i”},{”-n”,”-q”},

{”-n”,”-v”},{”-i”,”-q”}{”-i”,”-v”},{”-q”,”-v”},

{”-n”,”-i”,”-q”},{”-n”,”-q”,”-v”},{”-n”,”-i”,”-v”},

{”-i”,”-q”,”-v”},{”-n”,”-i”,”-q”,”-v”}}

The accuracy of the power set calculation can be checked because power sets have a cardinality of 2**n. In this case, 2**4=16. Other set operations can be checked with similar formulas.

Taking it another step further, consider giving that executable whose command line flags are being generated environment variable input as well. Suppose that the power set for the command line options is:

{{},{”-n”},{”-i”},{”-n”,”-i”}}

and the power set for the environment variable values is:

{{},{”TERM=vt100″},{”TERM=%n%n%n”}},{”LOGIN=root”},

{”LOGIN=%n%n%n”},{”TERM=vt100″,”LOGIN=root”},

{”TERM=%n%n%n”,”LOGIN=root”},

{”TERM=%n%n%n”,”LOGIN=%n%n%n”}}

The environment variable names and values were paired up using a set operation known as the Cartesian product. i.e. the Cartesian product of the sets {{”TERM”}} and {”vt100″,”%n%n%n”} is:

{{”TERM”,”vt100″},{”TERM”,”%n%n%n”}}

Taking further advantage of Cartesian products, all possible pairings of command line flags and environment values are generated. I won’t be typing the whole thing out here as it is excruciatingly long but it would start out something like this:

{{{},{}},{{},”TERM=vt100″},{{},”TERM=%n%n%n”}},

{{},”LOGIN=root”}, … , {{”-n”,”-i”},{”TERM=%n%n%n”,”LOGIN=root”}},

{{”-n”,”-i”},{{”TERM=%n%n%n”,”LOGIN=%n%n%n”}}}

I put the ellipsis in there because, well, you get the idea! This continues on until all possible subsets of command line flags have been paired with all possible subsets of pairings of environment variable names and values. The final Cartesian product for two power sets of equal size can be represented visually by Pascal’s triangle.

The aforementioned set operations can be used to systematically prove the correctness of simple computer programs via deterministic testing. Modern computer programs are so complex that attempting to calculate all possible input scenarios would be infeasible with a silicon-based machine. In the future, I expect that it will be commonplace for quantum molecular systems or perhaps even DNA computers to solve software assurance problems (and many others) in constant time or O(1), but I digress.

Since silicon will be prevalent for the foreseeable future, the input space used for a real-world software test has to be reduced. The goal is to minimize test executions while maximizing path coverage so disparate input sets must be chosen. This is where “pseudo exhaustive”, “n-way”, or more recently “6-way” testing comes into practice. More information about input space reduction and pseudo exhaustive testing is in Rick Kuhn’s research at NIST.

Last month, I attended the U.S. Department of Homeland Security (DHS)/Department of Defense (DoD) Software Assurance (SwA) Forum at the Hilton in McLean, Virginia. One of the presenters, Rick Kuhn of NIST, outlined a technique for maximizing path coverage with dynamic analysis dubbed “6-way interactions”. Naturally, I was skeptical because “fuzzing”, as they sometimes call it in the security industry isn’t well-known for path coverage metrics. After dinner that night I printed and read Rick’s paper, “Pseudo-Exhaustive Testing for Software.” “Pseudo-exhaustive” because the combinatorics involved are concerned with optimizing the size of the input space to make the solution to the software assurance problem feasible using the dynamic analysis approach. The input set size required for the exhaustive dynamic test of a piece of modern software would be so large that the testing process would never complete. Keep in mind that there can be a many-to-one ratio between inputs and execution paths. Rick’s paper extended earlier research on pairwise (or, “2-way”) input set generation algorithms. It was shown that six inputs increases path coverage while still keeping a manageable computational complexity for the dynamic analyzer.

It seems that the the latest research on dynamic analysis is putting it ahead of the static paradigm in terms of “coverage”. Static analysis lacks execution context–it covers code but not runtime execution paths and I feel that path coverage is more assuring than code coverage. Furthermore, static analysis slows the SDL (software/systems/security development lifecycle.)

Static analyzers are often run by trusted insiders since companies are so paranoid about who gets to see their precious source code–Why have an outside group perform a code review when you can have a static analyzer do the legwork on the inside? This may help managers and executives sleep at night with thoughts of source code safety but it’s also helping to perpetuate bad practices. Insiders have a very narrow view of the code they write themselves. I think Dave G put it best in his Merits of Threat Modeling post to Matasano’s Chargen: “My code is perfectly secure until someone reports a vulnerability in it, at which point I will fix it and my code will be secure again.” My other favorite is “We have a policy that we won’t get hacked.” Coders and testers must have conflicting interests. They’re two different mindsets; hackers don’t follow policies.

Productivity is greatly reduced when developers test their own code. They could be writing more code instead of improperly testing code they’ve already written. Over time, there will be a tendency to introduce non-obvious back-doors into the product’s source code since developers are writing code such that it doesn’t cause a static analysis tool to produce warnings.

A few years ago I was making a living as a dedicated employee of a security consultancy whose name I won’t mention. For those of you who know me, I’ll give you three guesses and the last two don’t count. In any case, one day I was working at a (unnamed) client site and I noticed one of my fellow consultants running RATS, an antiquated static analysis tool for auditing source code. RATS stands for Rough Auditing Tool for Security and “rough” is a suitable description of it. Similar to another tool named flawfinder, RATS greps through source code for calls to functions that are considered unsafe. It prints out the source file and line number where the function call that is considered unsafe occurs. The person using RATS still has to review the programming language statements themselves to confirm that the alert displayed by RATS wasn’t a false positive.

So now I wonder.. Why even use such tools at all? Why not do a manual review of the code yourself since you’re going to have to look at the code anyway? I have no doubt that the tool can grep faster than the human eye, but the trained eye can pick up things that the source code scanner can’t. Furthermore, a dynamic analyzer can detect things that both the static analyzer and the human won’t see. I don’t want anyone to think that I’m trying to malign my old co-worker’s noble effort to get his job done–that’s not my intention at all. I am simply looking towards the future and wondering how these tasks will be accomplished five or even ten years from now.

Software assurance suites that take advantage of the dynamic code analysis paradigm have the ability to feature a zero false positive rating. Static analyzers tend to ask the question: “What appears be wrong with this code that I’m analyzing?” whereas dynamic analyzers phrase the question as: “Which input sets will yield unexpected and/or unintended program output?”

As a result of executing software directly (either natively or through emulation), the dynamic analysis approach to assuring software quality is much better poised to discover bugs without presenting a conundrum of false positives. A static analysis tool may appear to detect what is believed to be a critical security vulnerability. However, since the tool is not actually executing the program in question, what appears to be an insecurity can turn out to manifest itself as a safe operation. Conversely, what appears to be a safe operation can in actuality be another vulnerability.

A few weeks ago while I was on vacation in the Outer Banks of North Carolina I was browsing through the media archives for DEF CON 15 since I missed the conference this year (I did make it out to Las Vegas, but not until September for the SANS Institute’s Network Security event.) While I was paging through the PDF-formatted slides for the presentations that I missed, one in particular immediately caught my eye; it was entitled “How I Learned to Stop Fuzzing and Find More Bugs.” Essentially, the presenter (Jacob West of Fortify Software) was playing on the fact that most (if not all) publicly available fuzzing utilities exhibit severely inadequate path coverage benchmarks. Personally, I agree with that assertion. I also believe that Jacob’s claims were somewhat slanted based on his employment at a software company that offers a static analysis product. Although I have not yet seen a practical solution for it, I do believe that it is possible to attain an optimal level of path coverage while utilizing dynamic analysis techniques.

The qualm I have with static analysis is its nature by definition. It doesn’t execute the program being scrutinized. Okay, fine. Static analyzers have their place. Maybe the tester is caught in a situation where he or she doesn’t have permission to execute the program. Regardless, I feel such a predicament is rare and if the tester is capable of executing the program, then why not do so? Why not explore all avenues of possibility? In addition to code execution, dynamic analysis can reap all the benefits of static analysis as well. Static analysis is restricted to read-only access; this is what makes static code analysis an inferior approach to software assurance. Dynamic analyzers can get the best of both worlds.. They have their cake and eat it, too!

What’s in a nutshell? The kernel of course.. but you won’t get inside the kernel if you just stare at the shell..

Not just a cliche–an analogy that sums up the dynamic versus static debate.

Welcome to Security Objectives’ new web log site at WordPress! Here you will find regularly updated musings related to System of Systems Engineering (SoSE), computer programming, software assurance and testing, digital security, philosophy, systems theory, reverse engineering, and discrete mathematics among other technical topics. News and press releases concerning Security Objectives’ itself is of course also fair game. Be sure to check back often for a healthy dose of fascinating technical research.