Memory Corruption and Hacker Folklore

A while back i thought it would be nice if we had an authoritative source of memory corruption attacks (and mitigations) in a single document.

I resisted mainly because:
  • It seemed like a lot of drudgery for something we have been able to do well without,
  • It steers towards the word "taxonomy" [1]
  • I was a little lazy.
[1] Dave Aitel has posited that "people who thing (sic) of things as "Taxonomies" are always
headed in the opposite direction from correct"

Late last year i ran some scripts (and waded) through OSVDB's database, to see if we could pull through some numbers on memory corruption bugs (through the ages) and their disclosure rate compared to other bugs. (theres actually a wealth of fiddling in these numbers too, that ill get around to at some point).

I figured it would be nice to see a timeline of memory corruption exploitation techniques along with the mitigation steps introduced plotted along-side the bug counts (but still lacked the real motivation).

Late last year, HalVar tweeted
"Walking down memory lane, reading old exploits from '99 -- can someone write a history of code exec '95-2009 ?"

@benhawkes did a fine job of presenting this at kiwikon, and over the years a few people have written papers / done presentations which covered some of this ground [A brief history of Exploitation Techniques and Mitigations on Windows][Generic Anti-Exploitation Technology for Windows][A Comparison of Buffer Overflow Prevention Implementations and Their Weaknesses].

The recent "Return Oriented Programming" / advanced ret-2-libc discussions revived these chats.

The incomparable @silviocesare said:
"A text file on google is transient, not officially archived, and generally academically untrustworthy." and "..Citing a URL which will be offline in 10 years time is not good."

This is true, but tragic if it means that techniques discovered in the 90's are not credited when re-introduced into academia today..

or as Halvar said
"The ROP discussion is amusing in the sense that our folklore gets republished, and then we are asked "what papers have you published" ? :)"

Being a closet academic (or at least trying to look like one), it seems the natural thing to do then is to actually see if we can get a good handle on our "folklore". Im hoping that if we can add a reasonable amount of rigor, it can also pass as academically submittable ensuring that its read into the rolls..

Tim Kornau over at Zynamics waded through some of the history in his
post on return-oriented programming and prefaced his post with the following disclaimer: "I will also take some of the recent discussions on Twitter into account which showed that even though I thought I did my history research pretty well, there were still some mailing list post missing from my time-line."

It's clear that doing this alone will miss huge chunks of data (and no doubt offend some people terribly). The simple answer is to experiment with a buzz-word, and try to "crowd-source" it.
I have put up a simple google-doc spreadsheet, which ties back to the eye candy visualizations you can see here: [index] and here: [combo]
(The combo page uses a Google visualization that needs flash, so you can skip it)

The important bit however is this.. Use the form to add events that you think need adding.. If you have it with a good link and/or reference, thats perfect, but even if you dont, add it anyway.. Our budding group of eager researchers (me), will chase it down and make sure its slotted in the right place.

Comments

  1. Security Pelle8 June 2010 at 21:36

    https://www.ee.oulu.fi/research/ouspg/PROTOS_EICAR2000-overflow-survey

    Takanen, A., Laakso, M., Eronen, J. and Röning, J. (2000) Running Malicious Code By Exploiting Buffer Overflows: A Survey Of Publicly Available Exploits, EICAR 2000 Best Paper Proceedings, pp.158-180.

    ReplyDelete

Post a Comment

Popular posts from this blog

Simple Graphs with Arbor.js

Image
We recently released a tool at http://cc.thinkst.com to capture and collect infosec conference details. We commented on it [ here ]. One of the cooler components of it, is the ability to view the relationships between speakers/researchers who have collaborated. This post is a quick introduction to the library we used to build our graphs, with enough info to get you up and running in minutes. As I mentioned, we use ArborJS library which is a a graph visualization library using web workers and the popular jQuery . The API is really well documented [ here ] but like most people, I learn best by example (and there are precious few of these). Hopefully this post will fill that niche, and by the end of it you should have a basic understanding of how to use arbor.js in your project. Our Aim: We will be building a simple contrived example as seen in the image above. Project setup : Create a new html page and include script references to the following libraries (Download them from the links...
Read more

Small things done well¹

Image
Bad design is bad  In 2015 Moxie Marlinspike pointed out that the manual page for GPG is (now) 50% of the novel Fahrenheit 451. Any software whose man page approaches 20 thousand words better have a good excuse, and GPG can only gesture vaguely at decades of questionable design. GPG gets a bad rap but it isn’t really much of an outlier. Security software has a long history of crumby, unintuitive interfaces and terrible design choices. A deep dive into the factors behind awfully designed security software isn’t the purpose of today’s blogpost, but suffice it to say there is seldom pressure from the end users. Security software mandated by a security team is often rammed down users’ throats, so it doesn’t bother being pleasant. It’ll sell anyway. We’ve worked hard to buck this trend from our first version. It’s one reason why we are one of the few pieces of security software that customers actually talk about in terms of love: https://canary.tools/love Recently, we released a major...
Read more

Using the Linux Audit System to detect badness

Image
Security vendors have a mediocre track record in keeping their own applications and infrastructure safe. As a security product company, we need to make sure that we don’t get compromised. But we also need to plan for the horrible event that a customer console is compromised, at which point the goal is to quickly detect the breach. This post talks about how we use Linux's Audit System (LAS) along with ELK (Elasticsearch, Logstash, and Kibana) to help us achieve this goal. Background Every Canary customer has multiple Canaries on their network (physical, virtual, cloud) that reports in to their console which is hosted in AWS. Consoles are single tenant, hardened instances that live in an AWS region. This architecture choice means that a single customer console being compromised, won’t translate to a compromise of other customer consoles. ( In fact, customers would not trivially even discover other customer consoles, but that's irrelevant for this post. ) Hundreds of consoles runn...
Read more