Defense in depth: Our goal in designing Chrome’s security architecture was to layer defenses, and avoid single points of failure. Chrome’s sandbox architecture represents one of the most effective parts of this strategy, but it’s far from the only piece. We also employ the best available anti-exploit technologies—including ASLR, DEP, JIT hardening, and SafeSEH—along with custom technologies like Safe Browsing, out-of-date plugin blocking, silent auto-update, and verified boot on Chrome OS. And we continue to work towards advancing the state of the art with research into areas like per-origin sandboxing and control flow integrity.

Transparency: We do not downplay security impact or bury vulnerabilities with silent fixes, because doing so serves users poorly. Instead, we provide users and administrators with the information they need to accurately assess risk. We publicly document our security handling process, and we disclose all vulnerabilities fixed in Chrome and its dependencies—whether discovered internally or externally. Whenever possible, we list all fixed security issues in our release notes, and make the underlying details public as soon as other affected projects have an adequate amount of time to respond. When we do not control the disclosure timeline for a security issue and cannot list it at the time of release, we make the details of the issue public as soon as disclosure occurs.

Community engagement: No software is perfect, and security bugs slip through even the best development and review processes. That’s why we’re grateful for the work of the independent security research community in helping us find and fix vulnerabilities. In response, we do our best to acknowledge and reward their contributions by ensuring proper attribution, paying out bounties, and sponsoring security conferences. We leverage the community to even greater extent where we can, by hiring members directly onto our team and contracting with industry leading, independent security consultancies.

White-box fuzzing or smart fuzzing is a systematic methodology that is used to find buffer overruns (remote code execution); unhandled exceptions, read access violations (AVs), and thread hangs (permanent denial-of-service); leaks and memory spikes (temporary denial-of-service); and so forth.

You can perform fuzzing on any code that parses input that is received across a trust boundary. This includes files, network sockets, pipes, remote procedure call (RPC) interfaces, driver IOCTLs, ActiveX objects, and message queues (including Microsoft Windows messages).

This article presents a case study of fuzzing during development of Microsoft Internet Security and Acceleration (ISA) Server 2006, and discusses efforts, bug density, and ROI. During this release, the internal testing team found over 30 bugs that were either Important or Critical—according to Microsoft Security Response Center (MSRC) ranking—in over 500 KLOC parsing code.

A decent intro to the concept of fuzzing, by Microsoft.

I expect them to have this patched before you read this.

In this blog post we will look at some of the differences between a several of the most widely used Debuggers/Disassemblers.  This post is by no means exhaustive.  It is meant as a brief overview to give people new to reversing a “quick start” guide.

My buddy Jason just put up a post on the differences between some dissassemblers and debuggers. You should have a look if you're looking to get into this space.