Ah, TCL, the Tool Command Language. Based on the research conducted by myself and my colleagues here at Security Objectives (most notably Shane Macaulay,) we have concluded that Tcl has a multitude of security issues, especially when being used in a network environment; and contemporarily speaking, network usage is almost unavoidable. In essence, we are urging the use of extreme caution in Tcl-based web development–whether it’s being used directly or indirectly. To generalize, we also advise against using Tcl for any network application or protocol (not just HTTP.) Security Objectives has published an in-depth analysis of practical Tcl vulnerabilities. The whitepaper, entitled “Tickling CGI Problems”, outlines the theoretical backbone of the phenomena in the first half and presents cases of real-world exploitation in the second half. However, the background theory along with some general programming and Hyper-Text Transfer Protocol knowledge is recommended in order to gain a firm understanding of the exploits themselves.

This is not to say that Tcl should not be used ever, so as a disclaimer we are not advocating any programming language over another. Our position is that the traditional approach to web security with Tcl has much room for improvement. Like any other programming language it works nicely in certain areas such as academic research, scientific computing, extensions, and software testing. With that being said, one project that comes to mind is regfuzz, a regular expression fuzzer written in Tcl which is quite useful. The distinction here is that regfuzz is not intended to be exposed to a public (or even a private) network. Surely, Safe-Tcl could successfully serve network clients in a hardened production environment given that assessed risks were rated low enough to suffice as acceptable. The problem is, that’s not the type of operations that occur in practice as evidenced by an overwhelming majority of cases.

The vulnerabilities exposed by the whitepaper affect TclHttpd, Lyris List Manager, cgi.tcl (which also uses Expect) as well as the Tcl language itself and interpreters thereof. Some of the attack methodologies and vulnerabilities identified are new to the public. Others are similar to well-known attacks or simply subversions of previous security patches, e.g. CVE-2005-4147. As time unfolds, there will surely be a surge in publicized Tcl weaknesses due to the research which is elaborated on within the whitepaper. If you’re interested in discovering vulnerabilities in Tcl software yourself, then there’s a grand list of references to Tcl-related things at http://www.tcl.tk/resource_dump.html. There is also a USENET newsgroup dedicated to it which is naturally called comp.lang.tcl.

For those of you attending CanSecWest 2011 in Vancouver, we are sponsoring the event. Professionals from Security Objectives will be in attendance to answer your queries regarding Tcl/Tk security or other areas of specialized research (information assurance, software assurance, cloud security, etc.) Of course, our professionals will also be available to field questions regarding Security Objectives’ product and service offerings as well. In addition, CanSecWest 2011 attendees receive special treatment when purchasing licenses for BlockWatch, the complete solution to total cloud security.

..binomial coefficients?! That’s right. I’ve found the web site of a Mr. Bob Jenkins with an entire page dedicated to a pairwise covering array generator named jenny.c. I’m fairly sure that only the most hardcore of the software testing weenies have some notion of what those are so for the sake of being succinct I’ll be providing my own explanation here: A pairwise covering array generator is a program for silicon computing machines that deduces sequences of input value possibilities for the purposes of software testing; and yes, I did say silicon computers–since testing their software is really a question of the great Mr. Turing’s halting problem, the existence of a practical, affordable, and efficient nano/molecular computing device such as a DNA computer, Feynman machine, universal quantum computer, etc. would essentially predicate a swift solution to the problem of testing contemporary computer software in non-deterministic polynomial time. The only problem we would have then is how to test those fantastic, futuristic, (seemingly science fictive) yet wondrous problem-solving inventions as they break through laborious barriers of algorithmic complexities that twentieth century computer scientists could have only dreamed about: PCP, #P, PSPACE-complete, 2-EXPTIME and beyond.. The stuff that dreams are made of.

Now, let’s return to Earth and learn about a few things that make Jenny so special. Computer scientists learned early on in their studies of software testing that pairwise or test cases with two input values were the most likely to uncover erroneous programming or “bugs.” Forget the luxury of automation for a minute, old school programmers typed input pairs manually to test their own software. Code tested in that manner was most likely some sort of special-purpose console mode utility. (Celsius to Fahrenheit, anyone?) As the computing power of the desktop PC increased according to Moore’s law, it became time-effective to write a simple program to generate these input pairs instead of toiling over it yourself–I suppose not testing at all was another option. Today, still some software is released to market after only very minor functional and/or quality assurance testing. Regression, stress, security, and other forms of testing cost money and reduce time to market, but in reality significant return on investment acts as a hedge against any losses incurred. Even ephemeral losses justify the absolute necessity of these expenditures.

A Jenny built in modern times undoubtedly has the power to deductively prove that a software product of the eighties decade is comprised of components (or units) that are fundamentally error-free. However, the paradox remains that improvements in automated software testers share a linear relationship with improvements of software in general. Thus, pairwise has become “n-way” which describes the process of utilizing greater multiples of input values in order to cover acceptable numbers of test cases. The number of covering arrays generated in this fashion grows exponentially and can be calculated as a binomial coefficient (see formula below.)

(n choose r) in factorial terms

According to Paul Black, former SAMATE (Software Assurance Metrics and Tool Evaluation) project leader, researchers at NIST have pegged 6-way as the magic number for optimal fault interaction coverage (notably Rick Kuhn and Dolores Wallace.) This conclusion is based on hard evidence from studies on real-world software scenarios including medical devices and the aerospace industry. However, it would not surprise me to see this approximation rise significantly in the coming decades, just as the paradoxical relationship between general-purpose software and automated software testing programs shifts itself in accordance with Moore’s law. If not by Moore, then by some other axiom of metric progression such as Rogers’ bell curve of technological adoption.

I’ve also got a hunch that the tiny percentage of bugs in that “n is arbitrarily greater than 6” range are some of the most critical, powerfully impacting software vulnerabilities known to man. They lie on an attack surface that’s almost non-existent; this makes them by definition, obscure, non-obvious, shadowy, and hidden. Vulnerabilities in this category are the most important by their very nature. Therefore, detecting vulnerabilities of this type will involve people and tools that are masters of marksmanship and artistic in their innovation. Research in this area is entering a steadfast beginning especially within the realms of dynamic instrumentation or binary steering, active analysis, fault propagation, higher-order preconditions/dependencies, concurrency issues, race conditions, etc. I believe that combining merits inherent in various analysis techniques will lead to perfection in software testing.

The security industry is currently in the process of reluctantly accepting that the current signature-based approach to anti-virus and malware identification is futile. Therefore, our Pass The Hash solution utilizes a whitelist approach in conjunction with a custom hash tree data structure to wholly single out malware variants piece by piece. Moreover, non-disclosure agreements are a besetting factor in digital forensics investigations because the analyst cannot inquire about a malware specimen by sending it out verbatim; our solution solves that problem too.

Here’s how it works: you compute Tiger hashes of files on your system, query our central database, and we tell you what they belong to. If it doesn’t match one of our hashes, you know you’ve got a problem. Once you’ve identified a piece of malware, you can coordinate specifics with our community such as fixes, research, opinions, etc. All of this is in a really sleek WPF GUI because here at Security Objectives, we strive to make hacking look like the movies!

The hash computations that our software performs identify polymorphous variations similar to Context-Triggered Piecewise Hashes and Bloom Filters. There will also be an off-line mode where hashes can be compared against a local client-side database that deals with hash trees similar to our centralized database. Directories, drives, and even processes whose hashes need to be calculated are inserted into a dynamically managed queue; with the click of a button the queue can be re-prioritized, saved, elements can be removed, etc. Meta-data is associated with each hash object that describes attributes such as operating system, platform, user-specified information, etc.

When we first started working on this we were thinking “napster for malware” but it’s turned into so much more. More recently the description was “MRBL” (Malware Real-time Blackhole List,) similar to the MAPS SPAM countermeasure except that it actually utilizes whitelist technology. “malster” sounds cool, but we decided to name it Pass The Hash, indicative of the hash value computation and transmission taking place. This venture is clearly distinguishable from GNU Pth (Portable threads) because our acronym (PTH) is written in all caps. 😉

I can’t provide an exact release date right now–all I can say is very soon. Once it’s released you’ll be able to download it from our products page. The long-term plan is to slap an open source license on the client code, thereby exposing the XML API for the central database and LINQ for the local one. Organizations that require the achievement of total malware sovereignty can deploy a dedicated appliance that acts as a counterpart to the centralized hash database hosted by Security Objectives. So keep your eyes peeled for the upcoming release of Pass The Hash. In the meantime, sneek a peek at a screenshot.

P.S. After a long hiatus, we plan to be hitting the conference circuit once again to present on the specifics of this new reactive malware eradication technology. We’ve been submitting CFP’s left and right, but you’re most likely to catch up with us at CanSecWest. Hope to see you there!