Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading content…
Transcript

If symbols are available, the name of the function. If the symbol contains source-code information, this is in the report with a link to online source code if available (Chrome/Firefox*)

With symbols bug id-s are unique to applications, without them they are unique to specific builds of the application. I have to delay Windows updates because MS doesn't release symbols for a couple weeks after patch Tuesday.

From crash to Bug Type

Access violation reading memory at address X

X is near* the special value 0

*Near means within 0x1000 bytes (configurable)

Special values include 0xBAADF00D, 0xCCCCCCCC, 0xFEEEFEEE, etc...

=> AVR:NULL+X <=

MemGC made a huge difference

90% of my vulns were MSIE/Edge DOM use-after-free.

MemGC made these practically unexploitable.

AFAIK none of the Pwn2Own Edge UAFs were DOM related

Not all code benefits from MemGC: I am still finding use-after-free vulns in Edge.

Not all vulns are use-after-free: I am still finding type-confusions, out-of-bounds reads/writes, etc.

However, don't focus too much on one cash cow: when the cow dies, you need to scramble to find alternatives.

What You Get

(besides the bug id of course)

The potential security impact of the bug

----Terms and conditions may apply!

Caveats:

* it is not aware to what degree you can control the crash

* it cannot tell you if a bug is exploitable IRL

* it will only report if this type of crash can potentially be exploited under the right circumstances

The location of the code in which the bug was detected, of course

A "human readable" description of the crash and type of bug

Labeling Bug Types

Sounds simple...

The debugger reports an exception (e.g. access violation)

BugId gathers information about the exception (e.g. exception address and page heap info for that address)

BugId attempts to determine the cause of the exception.

Access violation reading memory at address X

Values from poisoned memory, such as 0xBAADF00D, 0xCCCCCCCC, 0xFEEEFEEE, etc.:

=>⇒ AVR:Poison+X

=>⇒ AVR:PoisonUninitialized+X

=> AVR:PoisonFree+X

=> AVR:PoisonOOB+X

(You can add your own application specific values.)

Page heap says allocation near address X was freed.

AFAICT Page heap provides no information on allocation start address and size.

offset from end of page (N) = end of page - X

UAFR:[]~-N

Access violation reading memory at address X

Page heap says there is an allocation from address Y to Z

List of access violation bug types:

* NULL pointers (AV?:NULL)

* Poisoned pointers (AV?:PoisonXXX)

* Heap use-after-free (UAF)

* Heap out-of-bounds access (OOB)

* Heap out-of-bounds use-after-free (OOBUAF)

* Stack out-of-bounds access (AV?[Stack])

* Unknown (AV?:Unallocated/Invalid/Reserved/Arbitrary)

* Out-of-memory (OOM): Chrome uses AVs to signal OOM

Since X > Z, this is an out-of-bounds access, at N bytes beyond the memory block.

What bug type is this?

int3 breakpoint

Examine the stack to identify application specific issues:

  • Out-of-memory
  • Assertion failure

Application Verifier can trigger these to signal it detected heap corruption. BugId examines the page heap data structures to find out more than we can using the default commands.

=>⇒ OOBR[size]+N <=

(Where size = Z - Y, and N = X - Z)

(Control flow guard does not handle NULL pointers gracefully

when attempting to use the function pointer in the lookup table.)

My Browser Fuzzer Farm

9 Servers running ~100 VMs, fuzzing MSIE, Edge, Chrome and Firefox

Onward to cBugID

Mostly DOM & Javascript API Fuzzing (continuous interactive fuzzing)

~2500 crashes a day

about one vuln a month

Internals

How does it work?

Goals

A brief history of development

I plan to move it to the cloud but I had trouble handling the volume of output

Python is used for legacy reasons (Ex-GOOG)

BugId can be used to run a test manually or through batch scripting.

cBugId can be integrated into any project, for instance in automated testing frameworks

Detect, analyze and id application bugs

There's a bunch of not that technical people who use BugID to detect crashes from their fuzzers and use the output to write reports they send to bug bountry programs...

Automatically perform common analysis steps

Detect either 1st or 2nd chance exceptions

( AV, int3, div 0, etc.)

Analyze the exception to determine the type of bug responsible.

Do everything you would manually do automatically

cBugId callbacks

First goal: run tests unattended

Second goal: de-duplicate crashes (aka: Don't waste time on known issues)

Third goal: filter bugs by type and/or security impact (aka: Don't waste time on non-issues)

Fourth goal: generate report automatically (aka: Don't waste time reporting them for Bug Bounties :)

BugId uses cdb.exe from the Windows Debugging Tools.

cdb uses the same commands as WinDbg

You can understand what BugId does by looking at the commands it sends to cdb and the output it receives.

You can add extra analysis steps by having BugId execute additional commands and process their output.

It actually does what "!exploitable" was intended to do, but with much more useful output.

Easy to extend (i.e. detect assertion failure from target application specific AV/int3)

  • errors
  • application running
  • suspended
  • resumed
  • terminated
  • and/or bug detected

cBugId debugging

Runs the application using cdb.exe, sends commands through stdin and parses stdout

You can also ask cBugId to create a crash dump for offline

debugging.

Reporting Example

For a sample of what bugs I find, check out #DailyBug on twitter and my blog.

Would this process scale up linearly?

Ultimately no: bug collisions would get more and more frequent, reducing the number of unique bugs you find.

Some form of coordination between VMs might help, as might focusing different VMs on different features (but there are unlikely to be as many features as you have fuzz bots).

Amazing and clear reporting

Generate a *unique* bug id

World+dog has been shaking this tree for over a decade: there are almost no low hanging fruit left.

Dumb fuzzing is unlikely to yield useful results, even on thousands of VMs

My fuzzers are based on 10+ years of experience finding vulns. They know the DOM and JavaScript APIs very well. They work together to try to find vulns that require complex interactions.

The report also contains the stack, registers, memory dumps of relevant regions, disassembly of relevant code, binary version info and (optionally) a log of all cdb commands send to cdb and their output.

....? Profit?

AV:

  • Is address close to NULL ?
  • Is address special value ? (Poison)
  • Does PAGE HEAP know about it ? (UAF, OOB)
  • Is there a virtual allocation? (Reserved)

Breakpoint:

  • Check stack and stdout for Application Verifier error report. (UAF, OOBW)
  • Check stack for known special cases (OOM, Assertion failed)

BugId = stack hash (where)

+ bug type (What)

Exception => bug type description

  • Access violation => NULL pointer, use-after-free, out-of-bounds access, poison value used, assertion failed.
  • int 3 => OOM, assertion failed, heap corruption

Optionally attempt to make AV address platform independent (NULL+0x20 => NULL+4*N) for cross-platform BugIds

Analysis of issues is fully automated

Anything I would do manually in WinDbg is done automatically.

BugId

"Detect, analyze and id application bugs"

Bugs vs crashes

Vulns vs bugs

Did I find one thousand bugs,

or one bug a thousand times?

Exploitability at Scale

Based on available data and educated guessing:

  • False positive rate depends on control over the crash.
  • False negative rate very low (1/100+ confirmed)

Use-after-free bugs are commonly exploitable, but not guaranteed to be so.

NULL pointers are normally not exploitable (but underlying

issue may allow you to do other things than trigger a NULL pointer crash).

Story: MS Edge NULL pointer that turned out to be a bad cast.

Conclusions!

  • Used effectively in real life by more and less technical people.
  • Easy to get started quickly
  • No source or special build of target required
  • Open source: If you know WinDbg and Python, you can add or change features as you see fit.
  • Free for non-commercial use

BugID - Automated Bug Analysis

Berend Jan Wever - SkyLined - Independent Security Researcher

Learn more about creating dynamic, engaging presentations with Prezi