Subreption Blog

Just as Part I of the new series unfolded yesterday like some sort of highly charged Predator drone turning a Subaru into a huge sinkhole in a dirt road, here's Part II. See, for what it's worth, 2011 has been perhaps the strangest year in the field of information security ever since GOBBLES stopped making new comics and TESO disbanded into some sort of mixture of gone-into-the-crowd individuals and Twitter security rockstars obsessed with elevator music. But also of highly public, controversial and, in more than a few cases, rather shameful incidents. The landscape of threats has evolved from a highly dynamic sea of sharks, stingrays, starfishes and bottom feeders into a jellyfish-infested shore.

Some of the jellyfish react violently to any intrusions of their "thunder zone" (as in "don't steal my thunder", whether it means "do not publish anything even slightly related to this thing I plan to present in over nine thousand conferences world wide" or "I shot first"). They expel these heinous hypodermic hooks, which inject all sorts of distasteful karma into unsuspecting hosts. In this sea of jellyfish, former inhabitants of the salt water realm find themselves hesitant on sharing ideas and finding potential partners for both professional and personal growth. Then you've got the other kinds of jellyfish, including those that penetrate into networks for the shake of publicity, even when they can't read Russian, Portuguese and whichever language their "loot" was written in.

Here we are, supposedly the crackpots of our time. Raised 10 years ago in the waves of return-to-libc attacks, format string bugs drowning in a sea of mediocrity, we drifted ashore along with the tide, and found ourselves surrounded by the sheer evil of competing security consultancies eager and lusting for Microsoft contracts and a slice of the SDL pie. With the breeze of the sea, we sit content and joyful reading the musings of the true pipe-hitting hustlers of our industry.

The group of heterogeneous individuals gathers and decides to unleash series of articles as part of a clever detox strategy to indulge in the fine art of caustic prose writing. The concentrations of saline byproducts in the air, the humidity and the palm beach soothing rhythms stimulate regions of the brain thought dormant. And so, we grab the keyboards and write, half seriously, half humorously.

Previously we brought our stance on the Blue Hat Prize Contest to the attention of people who may have contributed in 10 years to the state of the art in defensive security more than any smooth talking contract hustler in the industry, pseudonymous, altruistically and without considering any ROI. As a company, we cannot afford to be altruistic, but we can afford being caustic, with devilish projections of cancerous sunburn. Our particular beach hideout has a shrine dedicated alone to the PaX Team. A few bushes to the right we have the Spengler Sombrero dancing to the wind. Since these ravings are operating the keyboard under the pernicious influence of coconut liquor, we can kindly avoid any name calling and refer to the article of Errata Security's Robert Graham, of "I invented IDS before any of you and I'm still in the industry, ha!" fame, not too-creatively titled "Comments about the $200,000 Blue Hat prize". We can't blame them, we wish we had invented IDS too so we could live off past glory like the laboratory wallaby from the new Planet of the Apes. Alas, that is not the case, and thus, we've got to earn and hold our grounds, and do so as adamantly as possible. In style, even when it is overkill.

It's time for the Great Shark Hunt. Wrapped up pretty and fresh, from the beach with love...

It's August 2011. The weather has been getting warmer and warmer over the course of the last few weeks. The sun is roasting all Vegas sentient life against the pavement, while swarms of security professionals stroll down the sidewalks. It's been a very strange year so far. Keeping up with the hype-n'-bake modus operandi of the industry in the past decade, Microsoft has announced the Blue Hat Prize Contest with a "whopping" prize (but not a cash prize while at it) for building new "security mitigation technologies". Circa 260,000 USD are at stake, including paid travel and expenses to Black Hat 2012, that is, if the world doesn't implode with the help of the naive and the people at Microsoft Outreach.

Disregarding of the fact that the very same people offering this prize have been consistently developing business intelligence on the industry, gathering gossip and influence from unsuspecting and not-so-unsuspecting professionals and "sceners", we have decided, as the independent, enfant terrible ensemble company we are, to completely vivisect this contest and explain, summing up the lengthier article in as few words as possible, why you should really not sell yourselves so cheap.

Barth and Boneh published in 2005 a great academic paper on the privacy concerns found in BCC mail distribution when deploying cryptography solutions such as PGP/GPG. The issue boils down to the fact that most of the time public key material is publicly available (such as in websites and key servers), thus rendering the entire purpose of BCC useless, especially when contacts being mailed have public key material from other BCC recipients in their key rings.

For organizations distributing sensitive information across multiple recipients with complex confidentiality and privacy inter-relationships, the usual (and extremely cumbersome) solution is to create recipient-specific keys or certificates, and carefully selecting these either manually or through mail aliases. Ultimately this approach has several weaknesses and is prone to human error.

From their excerpt:

We show that many widely deployed email encryption systems reveal the identities of Blind- Carbon-Copy (BCC) recipients. For example, encrypted email sent using Microsoft Outlook completely exposes the identity of every BCC recipient. Additionally, several implementations of PGP expose the full name and email address of BCC recipients. In this paper, we present a number of methods for providing BCC privacy while preserving the existing semantics of email.
Our constructions use standard public key systems such as RSA and ElGamal and suggest that BCC privacy can be implemented efficiently without changing the underlying broadcast semantics of the email system.

As of 2011, there's no widely extended "real solution" for the common players in mail encryption (such as GnuPG or the commercial PGP software). As much as Subreption would love to address common problems like these, currently we are hell out of time to allocate a slice of it in our tightly packed schedule. But if you have the funding and/or the time and skillset to roll a practical, easy-to-deploy solution, we would love to hear about it. It's never too late to solve this (niche) problem and increase productivity in organizations depending on secure BCC encrypted mail.

Enjoy the read.

Additional interesting slides:
http://www.cs.utexas.edu/~bwaters/presentations/files/privatebroadcast-fc06.ppt

They say a picture is worth a thousand words, or so the saying goes. Therefore, the output from the now classic paxtest tool (which exposed the practical differences of ExecShield and PaX, among an array of other interesting tidbits) follows:

PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Darwin foobar.local 11.0.0 Darwin Kernel Version 11.0.0: Fri May  6 22:16:19 PDT 2011; root:xnu-1699.22.53~1/RELEASE_X86_64 x86_64

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)              : Vulnerable
Anonymous mapping randomisation test     : No randomisation
Heap randomisation test (ET_EXEC)        : No randomisation
Main executable randomisation (ET_EXEC)  : No randomisation
Shared library randomisation test        : No randomisation
Stack randomisation test (SEGMEXEC)      : No randomisation
Stack randomisation test (PAGEEXEC)      : No randomisation
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (strcpy, RANDEXEC)    : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Writable text segments                   : Vulnerable

Now a very short interpretation of the information above: Essentially nothing has changed (at first glance) from Snow Leopard. 64-bit setups benefit from non-executable heap, and all setups benefit from non-executable stack.There is no image base randomization, therefore the program text stays at the same place every time. The most common instances of stack-based buffer overflows will be caught by GCC's SSP/ProPolice implementation, save few corner cases. There is no enforcement of page permission semantics. Formerly writable pages can become executable through mprotect & co.

It might be farfetched to draw conclusions before Lion's definitive release, but as of today, and if nothing changes dramatically, what's not to love? Before all the hype begins... the buck stops here.

It's 2011 and still, practitioners of the information security trade deal with the often frustrating fact that so-called legends exercise, in varying degrees, influence in the decision making of security companies. These "legends" are perhaps the most interesting example of an inverted generational conflict. While in other industries the young have it much easier than the old, in our (mostly miniature sized) industry, it is the old who had it much easier.

The dawn of the unconstrained address space, of easily exploitable security flaws, bug ridden operating system releases, et cetera, happened sometime in the late 90s. Take the wheel of time a step forward into the early 00s, and our present year, and we have mitigation technologies all over the place, far more security conscious developers, repressive criminalization of the tradecraft, multi million security budgets in the private industry and a blooming media & press drive fueling the desires of flatulent self-promotion. Flaws still happen, but the bar has been raised. Computer security in the 90s was child's play compared to the current landscape. What we have now is an ever evolving, highly exposed matrix of circumstances and factors. Large memory systems, 64-bit architectures readily available, high bandwidth connections and a booming market for information services. Current generations no longer generate revenue only in those things which can be weighed or valued per old guidelines. They generate revenue in ways which were unimaginable ten years ago. A sequence of bits traveling across optical wire can be worth more than an ounce of gold.

The requirements of effort and technical brilliance necessary to achieve professional success nowadays, are, in all senses, much superior than those of the previous generations of security professionals. It is not a matter of becoming obsolete or fearful of the next waves of younger professionals whom enjoyed a higher exposure to information and learning materials, but also the fact that in present time, the awareness and hindsight necessary to make consistent decisions, is often out of reach for the older professionals holding executive or managerial positions. Just as biological aging is inevitable, their nerve and wits aren't in par with the aggressive state of the art of today. Oft forced to resort to the memories of past times, deep within, they are aware of the fact that sooner or later, their influence will come to an end. Call it professional extinction. It's happening, and there's nothing that could be done to prevent it. It's natural, and it only serves progress.

If you are a young security professional, and feel frustrated about your interactions with older colleagues in meetings, stop worrying. We, old and not-so old farts, won't be around forever. Our wits will wither off, just like our influence, and we won't be able to live off past glory in a business as competitive and unforgiving as this one. Take a look out of the window, feel the fresh air, caress the hair of your lady and toast a cup of fossil fuel, for you will be kicking ass while these old farts run like cattle to collect their tiny pensions. And after that, enjoy the ride in a five figure muscle car, knowing they are in your tank, flowing to the combustion engine at full gas!

Le Roi est mort, vive le Roi.

Soon we will be publishing several articles about open source embeddable virtual machines available today. Among them we will be talking on LUA, Forth, Pawn (originally Small), Squirrel, specialty implementations of Python such as PyMite, Io, NekoVM, Falcon and Parrot. Depending on time availability it might take some time until all of these languages are covered. Mileage will also vary regarding detail and depth of evaluation.

The rationale behind these articles is the lack of summarized, objective information about the implementations of embedded languages, the differences between them at implementation level, limitations and features, et cetera. If you are looking for such information to make a decision about which VM or language suits you best, these articles might be of help to have a reasonably solid base for your evaluation process.

Apparently there's been an increased interest on bringing Linux kernel security issues to attention, for the past few months. It is a natural reaction to a policy which has been long time tacitly agreed upon by mostly all people involved in Linux kernel development (and more so, those with security-relevant roles, particularly a specific vendor). That is, a policy of silence. It is no surprise that Linux security currently looks much better on paper and marketing propaganda than it does in reality.

It takes decent amounts of will and dedication to summarize, categorize and review every potential security vulnerability for such a huge project, requiring collaboration between different vendors, who might or might not have agendas of their own, conflicting the interests of the users, or the rest of vendors themselves. It takes approximately ten minutes for an average computer user to write a summary of why SELinux can help your organization cut down security risks.

What you don't now is that you will have to go through the learning curve of writing policies, reviewing all software being used (including commercial applications which might not conflict with any 'learning' mode at kernel level, but consistently prevent targeted reverse engineering or make it even more tiresome), testing the setup and adapting its architecture to the real needs of your organization. MLS is rarely used out of certain circles.

Few months after the publication of the original "Linux Kernel Heap Tampering Detection" paper in  Phrack Magazine 66, we are proud to announce the availability of KERNHEAP. The implementation has built on several of the ideas described in detail in the paper. There are several improvements and changes not covered by the article, which are significant enough to be explained in a more or less detailed manner in this announcement.

Without further ado, KERNHEAP is available at http://www.subreption.com/kernheap as patches applicable to the latest stable 2.6 Linux kernel revision.

What's new?

The page sanitization functionality has been removed, in favor of using KERNHEAP along PaX, which provides a (unconditional) memory sanitization feature. In the near future, a SLAB flag might be added to support allocation-level sanitization.

The vmalloc vmap structures are now stored in an isolated cache, instead of a generic kmalloc cache. This helps to avoid certain cases in which a SLAB buffer overflow scenario could corrupt a neighboring vmap area structure, leading to potentially exploitable conditions during list walking in the vmap routines, where checks have been implemented to validate pointer correctness.

Full support against double frees and other types of heap corruption has been implemented for SLAB, SLUB and SLOB (the latter currently with limited functionality, users of SLOB would be better off moving to SLAB). Cache and slab meta-data is protected as well.

Currently only x86 and UML have been tested (you can protect User-Mode Linux kernels with KERNHEAP seamlessly).

Poisoning and the "pit" area

This change affects architectures with a fixmap, currently x86 and User-Mode Linux (UML) have been tested (the latter lacks a fixmap implementation). Poisoning alone is architecture-independent.

Every cache contains two unsigned long values, for poisoning uninitialized and free objects. If the architecture supports a fixmap, these values are randomized within a range, pointing to a reserved top memory location (a "mapping" within the fixmap). The page fault handler is modified to include a special case to handle accesses to this region. This allows us to reliably detect use of uninitialized or already released objects, as well as poisoning other pointer values (such as list nodes after unlinking).

This region is referred to (in KERNHEAP source code and documentation) as "the pit".

Architectures without fixmap support are unsupported, and will require editing the patch to avoid using fixmap-based poison address values. This would be done in the same way UML support is written, it is a simple change.

SAFELIST

KERNHEAP now provides more than mere safe unlinking. List nodes have their pointers poisoned after unlinking and the correctness of the nodes is verified during certain core operations. This provides robust protection against most forms of corruption in all linked lists. In the near future, protection for other similar interfaces might be implemented.

KERNHEAP and PaX or grsecurity

We recommend using PaX and KERNHEAP together, since PaX features can benefit from the meta-data corruption protections (among other things, for example for USERCOPY) and KERNHEAP itself can benefit from KERNEXEC and other protections to deter kernel exploitation. The patches shouldn't conflict with each other, but any potential conflict can be easily solved, either manually or through a "pax-compat" patch available in the distribution site.

Support and sponsoring

At the moment, KERNHEAP is developed by Subreption LLC. We do not offer support to organizations and individuals, apart of bug fixes, maintaining up to date patches and developing new features as we see fit. If you are interested on custom solutions or support for your organization related with KERNHEAP, or you are interested on sponsoring its development, contact us.

An article written by Dan Goodin from The Register was recently published, it mentions a forthcoming presentation by Vincenzo Iozzo, which presents a method to load a binary on runtime, directly from memory, in Mac OS X systems.

Here we like to stick to the technical side of things... so let's get started on explaining how this can be done, in case you aren't planning to attend Black Hat or just feel particularly curious on the topic!

The Mach-o Dynamic Loader: Dyld and runtime binary loading

When you execute a program, the operating system processes its main binary ("the executable") and resolves its dependencies before execution begins. Modern operating systems allow programs to depend on other software dynamically. Instead of compiling all the features statically (that is, built-in in the main executable), it lets you select such dependencies dynamically. When the executable is loaded, a piece of software takes care of finding such dependencies, placing them in memory, and updating the locations where our program will find the necessary functions, et cetera. This provides an efficient way to save space and produce less bulky binaries, as well as easing updates, since a library can be upgraded while retaining backwards compatibility.

The good fellows at Apple designed an even more efficient procedure for loading common libraries, and some of them stay on memory after the system boots, providing faster loading times and better execution speed, while lowering the stress on the disk caused by repeatedly loading libraries when executing a new process. The place where such common libraries are loaded is the shared region. It's been used to produce 100% reliable local privilege escalation exploits, too.

In Mac OS X, the dynamic linker is known as dyld. Leopard implements a rudimentary form of ASLR, consistent enough to deter the most simple threats and inefficient against some other issues (heap overflows, memory leaks and so forth). The dyld happens to be loaded on a static address in every Leopard installation, independently of language, distribution (that means Server) or platform.

Given a couple thousand different Intel-based 32-bit Leopard installations, dyld will live at 0x8fe00000, for all of them.