Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

BugId - Automated Bug Analysis

No description
by

a a

on 20 April 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of BugId - Automated Bug Analysis

BugID - Automated Bug Analysis
MemGC made a huge difference
90% of my vulns were MSIE/Edge DOM use-after-free.
Onward to cBugID
What You Get
The location of the code in which the bug was detected, of course

A "human readable" description of the crash and type of bug
My Browser Fuzzer Farm
9 Servers running ~100 VMs, fuzzing MSIE, Edge, Chrome and Firefox
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
Exploitability at Scale
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).


Berend Jan Wever - SkyLined - Independent Security Researcher
"Detect, analyze and id application bugs"

BugId
Bugs vs crashes
Vulns vs bugs
Did I find one thousand bugs,
or one bug a thousand times?
~2500 crashes a day
I plan to move it to the cloud but I had trouble handling the volume of output
Mostly DOM & Javascript API Fuzzing (continuous interactive fuzzing)
about one vuln a month
MemGC made these practically unexploitable.
AFAIK none of the Pwn2Own Edge UAFs were DOM related
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.
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.
Goals
Detect, analyze and id application bugs
Automatically perform common analysis steps
....? Profit?
Amazing and clear reporting
Reporting Example
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
.
How does it work?
Detect either 1st or 2nd chance exceptions
( AV, int3, div 0, etc.)

Analyze the exception to determine the type of bug responsible.
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

Generate a *unique* bug id
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 :)
A brief history of development
You can also ask cBugId to create a crash dump for offline
debugging.

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
Internals
cBugId debugging

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

Analysis of issues is fully automated

Anything
I would do
manually in WinDbg is done automatically.

errors
application running
suspended
resumed
terminated
and/or bug detected
cBugId callbacks
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*)
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
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.
Do everything you would manually do automatically
Easy to extend (i.e. detect assertion failure from target application specific AV/int3)

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.

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 <=

What bug type is this?
Labeling Bug Types
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
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...
=>⇒ OOBR[size]+N <=

(Where size = Z - Y, and N = X - 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
(Control flow guard does not handle NULL pointers gracefully
when attempting to use the function pointer in the lookup table.)

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.
Based on available data and educated guessing:
False positive rate depends on control over the crash.
False negative rate very low (1/100+ confirmed)
Story: MS Edge NULL pointer that turned out to be a bad cast.
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).
Sounds simple...
Optionally attempt to make AV address platform independent (NULL+0x20 => NULL+4*N) for cross-platform BugIds
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.
(besides the bug id of course)
Access violation reading memory at address X
Access violation reading memory at address X
Page heap says there is an allocation from address Y to Z
Since X > Z, this is an out-of-bounds access, at N bytes beyond the memory block.
For a sample of what bugs I find, check out #DailyBug on twitter and my blog.
Full transcript