Rav­ings from Par­adise Island: Part II “High dive of the cavemen”

Just as Part I of the new series unfolded yes­ter­day like some sort of highly charged Preda­tor drone turn­ing a Sub­aru into a huge sink­hole in a dirt road, here’s Part II. See, for what it’s worth, 2011 has been per­haps the strangest year in the field of infor­ma­tion secu­rity ever since GOBBLES stopped mak­ing new comics and TESO dis­banded into some sort of mix­ture of gone-into-the-crowd indi­vid­u­als and Twit­ter secu­rity rock­stars obsessed with ele­va­tor music. But also of highly pub­lic, con­tro­ver­sial and, in more than a few cases, rather shame­ful inci­dents. The land­scape of threats has evolved from a highly dynamic sea of sharks, stingrays, starfishes and bot­tom feed­ers into a jellyfish-infested shore.

Some of the jel­ly­fish react vio­lently to any intru­sions of their “thun­der zone” (as in “don’t steal my thun­der”, whether it means “do not pub­lish any­thing even slightly related to this thing I plan to present in over nine thou­sand con­fer­ences world wide” or “I shot first”). They expel these heinous hypo­der­mic hooks, which inject all sorts of dis­taste­ful karma into unsus­pect­ing hosts. In this sea of jel­ly­fish, for­mer inhab­i­tants of the salt water realm find them­selves hes­i­tant on shar­ing ideas and find­ing poten­tial part­ners for both pro­fes­sional and per­sonal growth. Then you’ve got the other kinds of jel­ly­fish, includ­ing those that pen­e­trate into net­works for the shake of pub­lic­ity, even when they can’t read Russ­ian, Por­tuguese and whichever lan­guage their “loot” was writ­ten in.

Con­tinue read­ing

Rav­ings from Par­adise Island: Part I

Here we are, sup­pos­edly the crack­pots of our time. Raised 10 years ago in the waves of return-to-libc attacks, for­mat string bugs drown­ing in a sea of medi­oc­rity, we drifted ashore along with the tide, and found our­selves sur­rounded by the sheer evil of com­pet­ing secu­rity con­sul­tan­cies eager and lust­ing for Microsoft con­tracts and a slice of the SDL pie. With the breeze of the sea, we sit con­tent and joy­ful read­ing the mus­ings of the true pipe-hitting hus­tlers of our industry.

The group of het­ero­ge­neous indi­vid­u­als gath­ers and decides to unleash series of arti­cles as part of a clever detox strat­egy to indulge in the fine art of caus­tic prose writ­ing. The con­cen­tra­tions of saline byprod­ucts in the air, the humid­ity and the palm beach sooth­ing rhythms stim­u­late regions of the brain thought dor­mant. And so, we grab the key­boards and write, half seri­ously, half humorously.

Pre­vi­ously we brought our stance on the Blue Hat Prize Con­test to the atten­tion of peo­ple who may have con­tributed in 10 years to the state of the art in defen­sive secu­rity more than any smooth talk­ing con­tract hus­tler in the indus­try, pseu­do­ny­mous, altru­is­ti­cally and with­out con­sid­er­ing any ROI. As a com­pany, we can­not afford to be altru­is­tic, but we can afford being caus­tic, with dev­il­ish pro­jec­tions of can­cer­ous sun­burn. Our par­tic­u­lar beach hide­out has a shrine ded­i­cated alone to the PaX Team. A few bushes to the right we have the Spen­gler Som­brero danc­ing to the wind. Since these rav­ings are oper­at­ing the key­board under the per­ni­cious influ­ence of coconut liquor, we can kindly avoid any name call­ing and refer to the arti­cle of Errata Security’s Robert Gra­ham, of “I invented IDS before any of you and I’m still in the indus­try, ha!” fame, not too-creatively titled “Com­ments 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 lab­o­ra­tory wal­laby 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 pos­si­ble. 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…

beach1.jpg


Con­tinue read­ing

The Blue Hat Prize: A late April Fools joke

It’s August 2011. The weather has been get­ting warmer and warmer over the course of the last few weeks. The sun is roast­ing all Vegas sen­tient life against the pave­ment, while swarms of secu­rity pro­fes­sion­als stroll down the side­walks. It’s been a very strange year so far. Keep­ing up with the hype-n’-bake modus operandi of the indus­try in the past decade, Microsoft has announced the Blue Hat Prize Con­test with a “whop­ping” prize (but not a cash prize while at it) for build­ing new “secu­rity mit­i­ga­tion tech­nolo­gies”. Circa 260,000 USD are at stake, includ­ing paid travel and expenses to Black Hat 2012, that is, if the world doesn’t implode with the help of the naive and the peo­ple at Microsoft Outreach.

Dis­re­gard­ing of the fact that the very same peo­ple offer­ing this prize have been con­sis­tently devel­op­ing busi­ness intel­li­gence on the indus­try, gath­er­ing gos­sip and influ­ence from unsus­pect­ing and not-so-unsuspecting pro­fes­sion­als and “sceners”, we have decided, as the inde­pen­dent, enfant ter­ri­ble ensem­ble com­pany we are, to com­pletely vivi­sect this con­test and explain, sum­ming up the length­ier arti­cle in as few words as pos­si­ble, why you should really not sell your­selves so cheap.

Con­tinue read­ing

Pri­vacy vio­la­tions in Blind-Carbon-Copy mail

Barth and Boneh pub­lished in 2005 a great aca­d­e­mic paper on the pri­vacy con­cerns found in BCC mail dis­tri­b­u­tion when deploy­ing cryp­tog­ra­phy solu­tions such as PGP/GPG. The issue boils down to the fact that most of the time pub­lic key mate­r­ial is pub­licly avail­able (such as in web­sites and key servers), thus ren­der­ing the entire pur­pose of BCC use­less, espe­cially when con­tacts being mailed have pub­lic key mate­r­ial from other BCC recip­i­ents in their key rings.

For orga­ni­za­tions dis­trib­ut­ing sen­si­tive infor­ma­tion across mul­ti­ple recip­i­ents with com­plex con­fi­den­tial­ity and pri­vacy inter-relationships, the usual (and extremely cum­ber­some) solu­tion is to cre­ate recipient-specific keys or cer­tifi­cates, and care­fully select­ing these either man­u­ally or through mail aliases. Ulti­mately this approach has sev­eral weak­nesses and is prone to human error.

From their excerpt:

We show that many widely deployed email encryp­tion sys­tems reveal the iden­ti­ties of Blind– Carbon-Copy (BCC) recip­i­ents. For exam­ple, encrypted email sent using Microsoft Out­look com­pletely exposes the iden­tity of every BCC recip­i­ent. Addi­tion­ally, sev­eral imple­men­ta­tions of PGP expose the full name and email address of BCC recip­i­ents. In this paper, we present a num­ber of meth­ods for pro­vid­ing BCC pri­vacy while pre­serv­ing the exist­ing seman­tics of email.
Our con­struc­tions use stan­dard pub­lic key sys­tems such as RSA and ElGa­mal and sug­gest that BCC pri­vacy can be imple­mented effi­ciently with­out chang­ing the under­ly­ing broad­cast seman­tics of the email system.

As of 2011, there’s no widely extended “real solu­tion” for the com­mon play­ers in mail encryp­tion (such as GnuPG or the com­mer­cial PGP soft­ware). As much as Sub­rep­tion would love to address com­mon prob­lems like these, cur­rently we are hell out of time to allo­cate a slice of it in our tightly packed sched­ule. But if you have the fund­ing and/or the time and skillset to roll a prac­ti­cal, easy-to-deploy solu­tion, we would love to hear about it. It’s never too late to solve this (niche) prob­lem and increase pro­duc­tiv­ity in orga­ni­za­tions depend­ing on secure BCC encrypted mail.

Enjoy the read.

Addi­tional inter­est­ing slides:
http://www.cs.utexas.edu/~bwaters/presentations/files/privatebroadcast-fc06.ppt

Mac OS X Lion: Did secu­rity mit­i­ga­tions man­age to squeeze in?

They say a pic­ture is worth a thou­sand words, or so the say­ing goes. There­fore, the out­put from the now clas­sic pax­test tool (which exposed the prac­ti­cal dif­fer­ences of Exec­Shield and PaX, among an array of other inter­est­ing tid­bits) 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 inter­pre­ta­tion of the infor­ma­tion above: Essen­tially noth­ing has changed (at first glance) from Snow Leop­ard. 64-bit setups ben­e­fit from non-executable heap, and all setups ben­e­fit from non-executable stack.There is no image base ran­dom­iza­tion, there­fore the pro­gram text stays at the same place every time. The most com­mon instances of stack-based buffer over­flows will be caught by GCC’s SSP/ProPolice imple­men­ta­tion, save few cor­ner cases. There is no enforce­ment of page per­mis­sion seman­tics. For­merly writable pages can become exe­cutable through mpro­tect & co.

It might be far­fetched to draw con­clu­sions before Lion’s defin­i­tive release, but as of today, and if noth­ing changes dra­mat­i­cally, what’s not to love? Before all the hype begins… the buck stops here.

Of dinosaurs, fos­sils, the old days and glory from times past

It’s 2011 and still, prac­ti­tion­ers of the infor­ma­tion secu­rity trade deal with the often frus­trat­ing fact that so-called leg­ends exer­cise, in vary­ing degrees, influ­ence in the deci­sion mak­ing of secu­rity com­pa­nies. These “leg­ends” are per­haps the most inter­est­ing exam­ple of an inverted gen­er­a­tional con­flict. While in other indus­tries the young have it much eas­ier than the old, in our (mostly minia­ture sized) indus­try, it is the old who had it much easier.

The dawn of the uncon­strained address space, of eas­ily exploitable secu­rity flaws, bug rid­den oper­at­ing sys­tem releases, et cetera, hap­pened some­time in the late 90s. Take the wheel of time a step for­ward into the early 00s, and our present year, and we have mit­i­ga­tion tech­nolo­gies all over the place, far more secu­rity con­scious devel­op­ers, repres­sive crim­i­nal­iza­tion of the trade­craft, multi mil­lion secu­rity bud­gets in the pri­vate indus­try and a bloom­ing media & press drive fuel­ing the desires of flat­u­lent self-promotion. Flaws still hap­pen, but the bar has been raised. Com­puter secu­rity in the 90s was child’s play com­pared to the cur­rent land­scape. What we have now is an ever evolv­ing, highly exposed matrix of cir­cum­stances and fac­tors. Large mem­ory sys­tems, 64-bit archi­tec­tures read­ily avail­able, high band­width con­nec­tions and a boom­ing mar­ket for infor­ma­tion ser­vices. Cur­rent gen­er­a­tions no longer gen­er­ate rev­enue only in those things which can be weighed or val­ued per old guide­lines. They gen­er­ate rev­enue in ways which were unimag­in­able ten years ago. A sequence of bits trav­el­ing across opti­cal wire can be worth more than an ounce of gold.

The require­ments of effort and tech­ni­cal bril­liance nec­es­sary to achieve pro­fes­sional suc­cess nowa­days, are, in all senses, much supe­rior than those of the pre­vi­ous gen­er­a­tions of secu­rity pro­fes­sion­als. It is not a mat­ter of becom­ing obso­lete or fear­ful of the next waves of younger pro­fes­sion­als whom enjoyed a higher expo­sure to infor­ma­tion and learn­ing mate­ri­als, but also the fact that in present time, the aware­ness and hind­sight nec­es­sary to make con­sis­tent deci­sions, is often out of reach for the older pro­fes­sion­als hold­ing exec­u­tive or man­age­r­ial posi­tions. Just as bio­log­i­cal aging is inevitable, their nerve and wits aren’t in par with the aggres­sive state of the art of today. Oft forced to resort to the mem­o­ries of past times, deep within, they are aware of the fact that sooner or later, their influ­ence will come to an end. Call it pro­fes­sional extinc­tion. It’s hap­pen­ing, and there’s noth­ing that could be done to pre­vent it. It’s nat­ural, and it only serves progress.

If you are a young secu­rity pro­fes­sional, and feel frus­trated about your inter­ac­tions with older col­leagues in meet­ings, stop wor­ry­ing. We, old and not-so old farts, won’t be around for­ever. Our wits will wither off, just like our influ­ence, and we won’t be able to live off past glory in a busi­ness as com­pet­i­tive and unfor­giv­ing as this one. Take a look out of the win­dow, feel the fresh air, caress the hair of your lady and toast a cup of fos­sil fuel, for you will be kick­ing ass while these old farts run like cat­tle to col­lect their tiny pen­sions. And after that, enjoy the ride in a five fig­ure mus­cle car, know­ing they are in your tank, flow­ing to the com­bus­tion engine at full gas!

Le Roi est mort, vive le Roi.

Vir­tual machine series: Light­weight embed­d­a­ble languages

Soon we will be pub­lish­ing sev­eral arti­cles about open source embed­d­a­ble vir­tual machines avail­able today. Among them we will be talk­ing on LUA, Forth, Pawn (orig­i­nally Small), Squir­rel, spe­cialty imple­men­ta­tions of Python such as PyMite, Io, NekoVM, Fal­con and Par­rot. Depend­ing on time avail­abil­ity it might take some time until all of these lan­guages are cov­ered. Mileage will also vary regard­ing detail and depth of evaluation.

The ratio­nale behind these arti­cles is the lack of sum­ma­rized, objec­tive infor­ma­tion about the imple­men­ta­tions of embed­ded lan­guages, the dif­fer­ences between them at imple­men­ta­tion level, lim­i­ta­tions and fea­tures, et cetera. If you are look­ing for such infor­ma­tion to make a deci­sion about which VM or lan­guage suits you best, these arti­cles might be of help to have a rea­son­ably solid base for your eval­u­a­tion process.


Con­tinue read­ing

Why Linux secu­rity has failed (for the past 10 years)

Appar­ently there’s been an increased inter­est on bring­ing Linux ker­nel secu­rity issues to atten­tion, for the past few months. It is a nat­ural reac­tion to a pol­icy which has been long time tac­itly agreed upon by mostly all peo­ple involved in Linux ker­nel devel­op­ment (and more so, those with security-relevant roles, par­tic­u­larly a spe­cific ven­dor). That is, a pol­icy of silence. It is no sur­prise that Linux secu­rity cur­rently looks much bet­ter on paper and mar­ket­ing pro­pa­ganda than it does in reality.

It takes decent amounts of will and ded­i­ca­tion to sum­ma­rize, cat­e­go­rize and review every poten­tial secu­rity vul­ner­a­bil­ity for such a huge project, requir­ing col­lab­o­ra­tion between dif­fer­ent ven­dors, who might or might not have agen­das of their own, con­flict­ing the inter­ests of the users, or the rest of ven­dors them­selves. It takes approx­i­mately ten min­utes for an aver­age com­puter user to write a sum­mary of why SELinux can help your orga­ni­za­tion cut down secu­rity risks.

What you don’t now is that you will have to go through the learn­ing curve of writ­ing poli­cies, review­ing all soft­ware being used (includ­ing com­mer­cial appli­ca­tions which might not con­flict with any ‘learn­ing’ mode at ker­nel level, but con­sis­tently pre­vent tar­geted reverse engi­neer­ing or make it even more tire­some), test­ing the setup and adapt­ing its archi­tec­ture to the real needs of your orga­ni­za­tion. MLS is rarely used out of cer­tain circles.

Con­tinue read­ing

KERNHEAP for the Linux ker­nel 2.6 released

Few months after the pub­li­ca­tion of the orig­i­nal “Linux Ker­nel Heap Tam­per­ing Detec­tion” paper in  Phrack Mag­a­zine 66, we are proud to announce the avail­abil­ity of KERNHEAP. The imple­men­ta­tion has built on sev­eral of the ideas described in detail in the paper. There are sev­eral improve­ments and changes not cov­ered by the arti­cle, which are sig­nif­i­cant enough to be explained in a more or less detailed man­ner in this announcement.

With­out fur­ther ado, KERNHEAP is avail­able at http://www.subreption.com/kernheap as patches applic­a­ble to the lat­est sta­ble 2.6 Linux ker­nel revision.

What’s new?

The page san­i­ti­za­tion func­tion­al­ity has been removed, in favor of using KERNHEAP along PaX, which pro­vides a (uncon­di­tional) mem­ory san­i­ti­za­tion fea­ture. In the near future, a SLAB flag might be added to sup­port allocation-level sanitization.

The vmal­loc vmap struc­tures are now stored in an iso­lated cache, instead of a generic kmal­loc cache. This helps to avoid cer­tain cases in which a SLAB buffer over­flow sce­nario could cor­rupt a neigh­bor­ing vmap area struc­ture, lead­ing to poten­tially exploitable con­di­tions dur­ing list walk­ing in the vmap rou­tines, where checks have been imple­mented to val­i­date pointer correctness.

Full sup­port against dou­ble frees and other types of heap cor­rup­tion has been imple­mented for SLAB, SLUB and SLOB (the lat­ter cur­rently with lim­ited func­tion­al­ity, users of SLOB would be bet­ter off mov­ing to SLAB). Cache and slab meta-data is pro­tected as well.

Cur­rently only x86 and UML have been tested (you can pro­tect User-Mode Linux ker­nels with KERNHEAP seamlessly).

Poi­son­ing and the “pit” area

This change affects archi­tec­tures with a fixmap, cur­rently x86 and User-Mode Linux (UML) have been tested (the lat­ter lacks a fixmap imple­men­ta­tion). Poi­son­ing alone is architecture-independent.

Every cache con­tains two unsigned long val­ues, for poi­son­ing unini­tial­ized and free objects. If the archi­tec­ture sup­ports a fixmap, these val­ues are ran­dom­ized within a range, point­ing to a reserved top mem­ory loca­tion (a “map­ping” within the fixmap). The page fault han­dler is mod­i­fied to include a spe­cial case to han­dle accesses to this region. This allows us to reli­ably detect use of unini­tial­ized or already released objects, as well as poi­son­ing other pointer val­ues (such as list nodes after unlinking).

This region is referred to (in KERNHEAP source code and doc­u­men­ta­tion) as “the pit”.

Archi­tec­tures with­out fixmap sup­port are unsup­ported, and will require edit­ing the patch to avoid using fixmap-based poi­son address val­ues. This would be done in the same way UML sup­port is writ­ten, it is a sim­ple change.

SAFELIST

KERNHEAP now pro­vides more than mere safe unlink­ing. List nodes have their point­ers poi­soned after unlink­ing and the cor­rect­ness of the nodes is ver­i­fied dur­ing cer­tain core oper­a­tions. This pro­vides robust pro­tec­tion against most forms of cor­rup­tion in all linked lists. In the near future, pro­tec­tion for other sim­i­lar inter­faces might be implemented.

KERNHEAP and PaX or grsecurity


We rec­om­mend using PaX and KERNHEAP together, since PaX fea­tures can ben­e­fit from the meta-data cor­rup­tion pro­tec­tions (among other things, for exam­ple for USERCOPY) and KERNHEAP itself can ben­e­fit from KERNEXEC and other pro­tec­tions to deter ker­nel exploita­tion. The patches shouldn’t con­flict with each other, but any poten­tial con­flict can be eas­ily solved, either man­u­ally or through a “pax-compat” patch avail­able in the dis­tri­b­u­tion site.

Sup­port and sponsoring

At the moment, KERNHEAP is devel­oped by Sub­rep­tion LLC. We do not offer sup­port to orga­ni­za­tions and indi­vid­u­als, apart of bug fixes, main­tain­ing up to date patches and devel­op­ing new fea­tures as we see fit. If you are inter­ested on cus­tom solu­tions or sup­port for your orga­ni­za­tion related with KERNHEAP, or you are inter­ested on spon­sor­ing its devel­op­ment, con­tact us.

Run­time binary load­ing via the dynamic loader on Apple Mac OS X

An arti­cle writ­ten by Dan Goodin from The Reg­is­ter was recently pub­lished, it
men­tions a forth­com­ing pre­sen­ta­tion by Vin­cenzo Iozzo, which presents a method
to load a binary on run­time, directly from mem­ory, in Mac OS X systems.

Here we like to stick to the tech­ni­cal side of things… so let’s get started
on explain­ing how this can be done, in case you aren’t plan­ning to attend Black Hat or
just feel par­tic­u­larly curi­ous on the topic!

The Mach-o Dynamic Loader: Dyld and run­time binary loading

When you exe­cute a pro­gram, the oper­at­ing sys­tem processes its main binary
(“the exe­cutable”) and resolves its depen­den­cies before exe­cu­tion begins. Mod­ern
oper­at­ing sys­tems allow pro­grams to depend on other soft­ware dynam­i­cally. Instead
of com­pil­ing all the fea­tures sta­t­i­cally (that is, built-in in the main exe­cutable),
it lets you select such depen­den­cies dynam­i­cally. When the exe­cutable is loaded,
a piece of soft­ware takes care of find­ing such depen­den­cies, plac­ing them in
mem­ory, and updat­ing the loca­tions where our pro­gram will find the nec­es­sary
func­tions, et cetera. This pro­vides an effi­cient way to save space and pro­duce
less bulky bina­ries, as well as eas­ing updates, since a library can be upgraded
while retain­ing back­wards compatibility.

The good fel­lows at Apple designed an even more effi­cient pro­ce­dure for load­ing
com­mon libraries, and some of them stay on mem­ory after the sys­tem boots, pro­vid­ing
faster load­ing times and bet­ter exe­cu­tion speed, while low­er­ing the stress on the disk
caused by repeat­edly load­ing libraries when exe­cut­ing a new process. The place
where such com­mon libraries are loaded is the shared region. It’s been used to
pro­duce 100% reli­able local priv­i­lege esca­la­tion exploits, too.

In Mac OS X, the dynamic linker
is known as dyld. Leop­ard imple­ments
a rudi­men­tary form of ASLR, con­sis­tent enough to deter the most sim­ple threats and
inef­fi­cient against some other issues (heap over­flows, mem­ory leaks and so forth).
The dyld hap­pens to be loaded on a sta­tic address in every Leop­ard instal­la­tion,
inde­pen­dently of lan­guage, dis­tri­b­u­tion (that means Server) or platform.

Given a cou­ple thou­sand dif­fer­ent Intel-based 32-bit Leop­ard instal­la­tions, dyld
will live at 0x8fe00000, for all of them.

Con­tinue read­ing