| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when checking exploitability rating.
Linux minidumps do not support MD_MEMORY_INFO_LIST_STREAM, meaning the
processor cannot retrieve its memory mappings. However, it has its own
stream, MD_LINUX_MAPS, which contains memory mappings specific to Linux
(it contains the contents of /proc/self/maps). This CL allows the minidump
to gather information from the memory mappings for Linux minidumps.
In addition, exploitability rating for Linux dumps now use memory mappings
instead of checking the ELF headers of binaries. The basis for the change
is that checking the ELF headers requires the minidumps to store the memory
from the ELF headers, while the memory mapping data is already present,
meaning the size of a minidump will be unchanged.
As a result, of removing ELF header analysis, two unit tests have been removed.
Arguably, the cases that those unit tests check do not merit a high
exploitability rating and do not warrant a solid conclusion that was given
earlier.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1251593007
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1476 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the minidump module containing the instruction pointer has memory
containing the ELF header and program header table, when checking the
exploitability rating, the processor will use the ELF header data to determine
if the instruction pointer lies in an executable region of the module, rather
than just checking if it lies in a module.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1233973002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1472 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the exception reponsible for the crash is benign, such as a floating point
exception, we can rule out the possibility that the code is exploitable. This
CL checks for such exceptions and marks the dump as not exploitable if such an
exception is found.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1212383004
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1467 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in valid code for Linux exploitability rating.
This CL adds to the Linux exploitability checker by verifying that the
instruction pointer is in valid code. Verification is done by obtaining a
memory mapping of the crash and checking if the instruction pointer lies in
an executable region. If there is no memory mapping, the instruction pointer
is checked to determine if it lies within a known module.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1210493003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1464 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
| |
https://breakpad.appspot.com/622002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1226 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
errors and use the good data if possible.
More specifically:
- Detect corrupt symbols during minidump processing and provide the list of modules with corrupt symbols in the ProcessState. This will allow listing the corrupt symbol files in the final crash report.
- Skip and recover from symbol data parse errors - don't give up until 100 parse errors are seen.
- In order to recover from '\0' (null terminator) in the middle of a symbol file, a couple of methods have to be updated to require both buffer pointer and length. Previously they required only a buffer pointer (char *) and the size of the buffer was evaluated using strlen which is not reliable when the data is corrupt. Most of the changes are due to these signature updates.
- Added and updated unittests.
Also, updated minidump_stackwalk to show a WARNING for corrupt symbols. Output looks like this:
...
Loaded modules:
0x000da000 - 0x000dafff Google Chrome Canary ??? (main)
0x000e0000 - 0x0417dfff Google Chrome Framework 0.1500.0.3 (WARNING: Corrupt symbols, Google Chrome Framework, 4682A6B4136436C4BFECEB62D498020E0)
0x044a8000 - 0x04571fff IOBluetooth 0.1.0.0
...
Review URL: https://breakpad.appspot.com/613002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1200 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
| |
BUG=505
Review URL: https://breakpad.appspot.com/498002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1159 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
| |
::string class instead of std::string. For more details take a look at common/using_std_string.h
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@974 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
| |
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@721 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
| |
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@711 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
| |
contains all ascii characters.
BUG=NONE
TEST=ExploitabilityTest.TestWindowsEngine
Review URL: http://breakpad.appspot.com/207001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@706 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
development so there
is no reason not to keep it locally. Implemented a basic disassembler which can be used
to scan bytecode for interesting conditions. This should be pretty easy to add to for
things other than exploitability if there is a desire. This also adds several tests to
the windows exploitability ranking code to take advantage of the disassembler for x86
code.
BUG=None
TEST=DisassemblerX86Test.*
Review URL: http://breakpad.appspot.com/203001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@705 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
