Grinder搭建小記與Nduja（這次不待續了）

Grinder是比較有名的瀏覽器FUZZ框架，採用ruby語言編寫，主要是作為測試框架來使用，在《白帽子講瀏覽器安全》一書中作者使用了Nduja生成測試樣本來配合Grinder使用。根據網上的資料，nduja、fileja的自動化部署預設都以Grinder作為支撐環境。

我個人覺得Grinder存在的意義在於能夠快速部署我們想要的Fuzz樣例而無需操心異常捕獲、程式管理這些細節。

Grinder分為

Node：負責實際的FUZZ工作

Server：負責收集結果，主要是為了管理多臺Fuzz機器

我這裡只搭建了Node

1. 安裝ruby2.0環境，在Windows下我使用了RubyInstaller進行一鍵整合化的安裝。
2. 把.\grinder\node\data\x86\grinder_logger.dll放到c:\windows\system32\目錄下
3. 建立一個符號路徑
4. 修改config.rb把上面建立的符號路徑和瀏覽器路徑填進去
5. 在FUZZ目錄下制定測試的例子
6. 執行ruby grinder.rb  --browser=BROWSER

Grinder是動態生成樣本的。對於其它的fuzz來說是先生成待測試的樣本，再由瀏覽器開啟。但是Grinder會直接開啟規則模版，動態生成樣本。這樣一來就需要對每次導致crash的值進行記錄，Grinder透過向瀏覽器注入grinder_logger.dll，hook住Javascript中的parseFloat函式。在呼叫logger.log時，grinder_logger.dll設定的hook回撥函式就可以記錄下來其內容，並儲存為log檔案。因為要Hook javascript函式，也就是說要解析jscript9.dll，所以需要這個模組的符號。這就是我們第3布操作的作用。當成功進行Hook之後，會給出提示。

[+D+] Hooked JavaScript parseFloat() to grinder_logger.dll via proxy @ 0x99B0000

此外記錄下來的log檔案不是直接的樣本，需要使用testcase.py進行解析。

.\grinder\node>ruby testcase.rb [--config=c:\path\to\CONFIG.RB] --log=c:\path\to\XXXXXXXX.XXXXXXXX.log --save=c:\path\to\XXXXXXXX.XXXXXXXX.html

About Nduja

根據上面的內容，我們可以看出Grinder其實只是提供了一些用於變異樣本的語法，關鍵的內容還是要依靠自己來進行編寫從而生成。

在這個基礎上Rosario valotta開發了一套實際的fuzz策略稱為Nduja Fuzzer

根據作者的介紹，得知Nduja的開發背景是在市面上已有DOM level1的fuzzer的情況下，去試圖fuzz DOM level2和level3以獲取更多的成果。

作者原話如下，我標註了一些重點出來：

The usual approach in browser fuzzing leverages on DOM Level 1 interfaces for performing DOM mutations: 

1. a big quantity of random HTML elements are created and randomly added to the HTML document tree 
2. the DOM tree is crawled and element references are collected for later reuse 
3. elements attributes and function calls are tweaked 
4. random DOM nodes are deleted 
5. garbage collection is forced  
6. collected references are crawled and tweaked again

This approach is effective but suffers from some design limitations: 

1. every DOM mutation (e.g. element tweaking, deletion, etc) is performed on a single HTML element, no mass mutations are managed
2. the execution workflow  can only be altered by the cardinality and the type of randomly generated DOM nodes (e.g different tag names, attributes, etc).

The entropy of a browser fuzzer can be taken to a further level introducing some new functionalities defined in DOM Level 2 and Level 3 specifications.

即透過對DOM2和DOM3中的新特性進行Fuzz來增墒。 為此作者舉了幾個例子作以說明。

Working with aggregations of nodes (DOM Level 2)
DOM Level 2 specifications introduces several new interfaces that allow to perform mutations on collections of DOM elements.
For instance interfaces like DocumentFragment, Range, TextRange, SelectionRange allow to create logical nodes aggregations and execute CRUD mutations on them using a rich set of APIS. 
A quick list of these methods: createRange, deleteContents, extractContents, cloneContents, cloneRange, removeRange, createTextRange, pasteHTML, etc
The expectation is that each of the methods provided for the insertion, deletion and copying of contents can be directly mapped to a series of Node editing operations enabled by DOM Core. 
In this sense these operations can be viewed as convenience methods that also enable a browser implementation to optimize common editing patterns.
It turns out that implementation bugs in this methods can lead to serious memory corruption errors when not correctly mapped to atomic-safe node operations.

Using document traversal data structures (DOM Level 2)
In the classic fuzzer approach, crawling the DOM tree is performed walking the physical tree from the top level node (DOCTYPE or HTML) to the leaves using DOM Level 1 methods (.children, .parentNode, .nextSiebling, etc).
In DOM Level 2 several data structures are available to create logical view of a Document subtree (eg. NodeList, TreeWalker, NodeIterator); we refer to these as the logical views to distinguish them from the physical view, which corresponds to the document subtree per se. 
These logical views are dynamic, in the sense that they modify their structure to reflect changes made to the underlying document.
That's why some memory corruption scenarios arise when DOM mutations performed on the physical tree are not correctly managed on the logical counterpart.

Introducing events (DOM Level 3)
In order to add more entropy to the fuzzer workflow, events firing and propagation can be used. DOM Level 3 specification defines a standard way to create events, fire them and manage event listeners for every DOM node. On top of that, specification defines a standard for event propagation model.
From the spec page (http://www.w3.org/TR/DOM-Level-3-Events/#dom-event-architecture):
"Event objects are dispatched to an event target. At the beginning of the dispatch, implementations must first determine the event object's propagation path."
The propagation path of an event include 3 steps:

1. capture phase: the event propagates through the target's ancestors from the document root to the target's parent. Event listeners registered for this phase handle the event before it reaches its target.
2. target phase: the event arrives at the final target element. Event listeners registered for this phase  handle the event once it has reached its target.
3. bubble phase: the event  propagates through the target's ancestors in reverse order, starting with the target's parent and ending with the document root element. Event listeners registered for this phase must handle the event after it has reached its target.

From the spec page: "The propagation path must be an ordered list of current event targets through which the event object must pass. For DOM implementations, the propagation path must reflect the hierarchical tree structure of the document. The last item in the list must be the event target; the preceding items in the list are referred to as the target's ancestors, and the immediately preceding item as the target's parent. Once determined, the propagation path must not be changed; for DOM implementations, this applies even if an element in the propagation path is moved within the DOM. or removed from the DOM. Additionally, exceptions inside event listeners must not stop the propagation of the event or affect the propagation path."

So the idea here is to let an event fire and alter the DOM tree structure after the propagation path has already been defined. This can be easily obtained attaching random eventListeners to every DOM element, setting the "capturable" flag to true. Whenever an event targeting a node is intercepted by a node's anchestor, some random operations on DOM tree are performed, removing o inserting whole sets of elements. Then the propagation of the event goes on.
Note: this technique proved to be  dramatically effective in crashing IE9/10, probably because IE9 is the first IE version to support standard W3C event model and is not still "bullet-proof".

Once determined, the propagation path must not be changed, even if an element in the propagation path is moved/removed within the DOM 

作者給出了Nduja的操作流程概述

• Initialization

• create a given number of random HTML elements
• for each element tweak random attributes/functions/styles
• for each element add a given number of event listeners
• append the elements in a random position in the document tree
• create logical views of a random DOM subtree (nodeIterator, treeWalker)

• Crawling
• Crawl DOM tree
• Create random Range (or similar DOM Level 2 structure) and apply random mutatios on it (delete, insert,surround, etc)
• Crawl DOM logical views

• Event management: events are managed accordingly to the dispatching phase 
• if the event is in the capture/bubble phase:
• remove some random event listeners from the current target
• create random Range (or similar DOM Level 2 structure) and apply random mutatios on it (delete, insert,surround, etc)
• crawl physical tree and logical views
• if the event is in the target phase
• add some other event listeners to the event target node

參考資料：

node
  -browser
     chrome.rb
     firefox.rb
     internetexplorer.rb
     safari.rb
  -core
    debug
      debugger.rb
      debuggerexception.rb
      heaphook.rb
      hookedprocess.rb
      logger.rb
      processsymbols.rb
    configuration.rb
    crypt.rb
    debugger.rb
    logging.rb
    server.rb
    webstats.rb
    xmlcrashlog.rb
  -crashes
  -data
  -fuzzer
    *.html
  -lib
    metasm
  -source
    --部分dll的原始碼
  config.rb
  crypto.rb
  grinder.rb
  reduction.rb
  testcase.rb
server
  --主要用於分散式節點的漏洞結果彙總，這裡不再詳述

http://www.freebuf.com/sectool/93130.html

http://blog.nsfocus.net/web-browser-fuzzing/