The tip of the 0day iceberg

The tip of the 0day iceberg

Summary: Guest Editorial: The story of modern computer security can never be told -- it's the story of the unknown. Right now, most people treat vulnerabilities as a constant stream of one-offs. In many real ways, the entire CVE database is the tip of an iceberg.

SHARE:
2

Guest Editorial by Dave Aitel

Dave AitelThe story of modern computer security can never be told -- it's the story of the unknown. Right now, most people treat vulnerabilities as a constant stream of one-offs. In many real ways, the entire CVE database is the tip of an iceberg.

In Singapore at the boutique SyScan conference, Immunity had two speakers: Justine Aitel, our CEO, gave the keynote, “The IPO of 0day” (.pdf) and Nicolas Waisman gave a talk on “Understanding and Bypassing Windows Heap Protection” (.pdf).

Yes, that last slide of Justine's talk is Vista recovering from a remote kernel 0day (no exploit is perfect!). This may surprise you, given the recent PR from Microsoft. The reason Windows Vista appears to have such a good security track record is that a vulnerability in Vista is not something you would give up. The iceberg is more under-water than it used to be.

Also in her talk are our internal statistics for how long 0day lasts. These weren't cross-site scripting 0days, in case you're curious. I don't know of another organization ever having gone public with these sorts of numbers, but certainly they won't seem out of place to any even moderately skilled hacker.

But Justine's talk is not all statistics and screenshots. The focus of the talk is on how a CSO can reorganize their business focus to protect against the unknown. The first step is hiring a team of people that can find and write their own 0days. If you don't have a team that can do that, you're floating blind in arctic waters, relying on what security vendors tell you. This is the industry that brought us anti-virus software and network IDS. They like to make up their own definitions for 0day based on whatever technology they're trying to sell so they can say they prevent it.

I half keep expecting to see "0day IDS Protection System" being sold next to Airborn "Designed by a teacher!" cold pills in the hippie grocery store next door.

A few years ago, I was at Gcon in Mexico City, and I saw Nico give a talk on exploiting a heap overflow in GDB by constructing a malicious binary. Anyone who is so good at heap overflows they do them for fun was someone we had to have on the team. Heap overflows are hard and only getting harder.

These days modern heap libraries include protections such as heap cookies designed to make them unexploitable. Nico's SyScan talk is about the tools and techniques you can use to get reliable exploits out of places people assumed would be protected. The strategic process here is that by writing a custom technique per program you are exploiting, you defeat the built-in protections.

You can protect against Nico's heap techniques by making your heap non-deterministic, for example, by randomizing your allocations between two heap areas.

Perhaps Immunity will patent that to preserve the exploitability of Longhorn. Then again, perhaps we don't have to. :>

* Dave Aitel is the CTO of Immunity, Inc., responsible for research and development for the CANVAS exploitation system.

Topics: Windows, CXO, Microsoft, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • Always wondered...

    I am not a programmer, so if this is a stupid question please feel free to ignore it. But I've heard of so many vulnerabilities that go back to heap overflows or buffer overflows...this is a very old class of problem that's been exploited so many times now; it must be pretty well understood. Wouldn't it be possible to create a compiler that would check for such issues and refuse to compile flawed programs until the problem was fixed? Or that patched them on the fly? Or even to create a programming language in which overflows are simply not possible? It just baffles me that somebody hasn't figured out how to kill such a pernicious problem before now.
    Ginevra
    • Language level protections

      [i]Wouldn't it be possible to create a compiler that would check for such issues and refuse to compile flawed programs until the problem was fixed?[/i]

      Once upon a time there were the "language wars."

      Think of them as Pascal vs. C, if you like; the issues revolved around whether a compiler should do the kind of enforcement that you describe or whether the programmer should. In C, for instance, an array is simply a series of addresses and access to it is done by arithmetic on pointers whereas in Pascal the array type contains information about its bounds that can be enforced by the compiler.

      Well, C won. Party because programmers didn't want to pay the overhead of all that checking at run time; after all, they could write the code to guarantee that array accesses were in-bounds.

      Or maybe they sometimes slip up.

      Bottom line is that the most popular languages today don't contain primitives for safe bounds enforcement and the low-level access abstractions have been enshrined in fundamental system library functions [1].

      So, yes, it's possible to have a type-safe language (Java, for instance) but that's not the world we live in.

      [1] [b]gets[/b], for instance: pass a pointer and the I/O system dumps whatever the buffer has into that location, regardless of whether the buffer is large enough.
      Yagotta B. Kidding