aboutsummaryrefslogtreecommitdiff
path: root/src/processor/exploitability_linux.cc
Commit message (Collapse)AuthorAgeFilesLines
* Fix a win32 build error by moving a #include out of an #ifndef _WIN32Ted Mielczarek2016-09-201-1/+2
|
* Updating ExploitabilityLinux to check memory mapping names against a prefixBen Scarlato2016-08-291-8/+13
| | | | | | | | | | | instead of a specific name. This will prevent false positives on systems which use a format such as “[stack:69616]” for stack memory mapping names. Change-Id: I51aeda2fe856c1f37f0d18ac06cce69fec2fffa2 Reviewed-on: https://chromium-review.googlesource.com/377086 Reviewed-by: Mike Frysinger <vapier@chromium.org>
* Fixing a flaky Linux exploitability unittest.Ivan Penkov2016-02-161-14/+30
| | | | | | | BUG=https://code.google.com/p/chromium/issues/detail?id=584174 R=mmandlis@chromium.org Review URL: https://codereview.chromium.org/1697963002 .
* Add check for Linux minidump ending on bad write for exploitability rating.Liu.andrew.x@gmail.com2015-08-211-2/+380
| | | | | | | | | | | | | | | If a crash occurred as a result to a write to unwritable memory, it is reason to suggest exploitability. The processor checks for a bad write by disassembling the command that caused the crash by piping the raw bytes near the instruction pointer through objdump. This allows the processor to see if the instruction that caused the crash is a write to memory and where the target of the address is located. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1273823004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1497 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add check for executable stack/heap when rating Linux exploitability.Liu.andrew.x@gmail.com2015-08-151-1/+20
| | | | | | | | | | | This CL also consequentially adds a public method to get the number of mappings in a Linux minidump. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1291603002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1488 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add check to see if stack pointer is off the stack according to the memoryLiu.andrew.x@gmail.com2015-08-151-1/+25
| | | | | | | | | | mappings when rating Linux exploitability. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1286033002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1487 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add support for Linux memory mapping stream and remove ELF header usageLiu.andrew.x@gmail.com2015-07-281-150/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add ELF header analysis when checking for instruction pointer in code.Liu.andrew.x@gmail.com2015-07-161-10/+143
| | | | | | | | | | | | | | 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
* Set exception whitelist check as earlier check instead of last check.Liu.andrew.x@gmail.com2015-07-071-15/+15
| | | | | | | | | | | | | | | When I first added the exception whitelist, I meant to put the check before checking the location of the instruction pointer. (I didn't notice that it was after the other check until now.) The whitelist check is to quickly rule out minidumps, and if checking the instruction pointer provided any useful information, it would be pretty indicative that the exception causing the dump is interesting. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1211253009 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1469 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Use general instruction/stack pointer convenience method instead of manuallyLiu.andrew.x@gmail.com2015-06-301-21/+4
| | | | | | | | | | | | | | finding the instruction/stack pointer for exploitability rating. There was already a method that found the instruction pointer, so the files for exploitability ratings had repeated code. Also a method for finding the stack pointer is implemented in this CL. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1210943005 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1468 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Checking for benign exceptions that trigger a minidump.Liu.andrew.x@gmail.com2015-06-301-1/+56
| | | | | | | | | | | | | 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
* This CL adds support for ARM and ARM64 architectures when calculatingLiu.andrew.x@gmail.com2015-06-301-1/+8
| | | | | | | | | | | | | | exploitability ratings. The stackwalker will now grab the instruction pointers for ARM and ARM64 architectures, so checking exploitability on ARM and ARM64 will no longer return EXPLOITABILITY_ERR_PROCESSING. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1216063004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1466 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Checking location of the instruction pointer to see if it isLiu.andrew.x@gmail.com2015-06-251-0/+59
| | | | | | | | | | | | | | | | 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
* Add simple exploitability analysis for Linux crashes.mattdr.breakpad@gmail.com2013-10-291-0/+86
https://breakpad.appspot.com/622002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1226 4c0a9323-5329-0410-9bdc-e9ce6186880e