The blog continues at suszter.com/ReversingOnWindows

September 9, 2012

Using Windbg as Hex Editor

This blog post discusses the idea to use Windbg as hex editor. It consists of the followings: the advantage of using this approach, and the initial steps to getting started. Possible risks are discussed at the end of the post.

I often use hex editor to examine binaries. Even though some of them have rich feature set built-in sometimes there is a need to use special functionality that goes beyond the capability of any hex editor. Some hex editors have plugin interface so for them it's possible to write special functionality that accounts people needs. Although this is true, I have some plugin commands already written for Windbg, and there should not be a reason to code them again to work with some hex-editor, too. That would mean I should maintain both code base in the future which is not what I want.

In the recent days, I was thinking about what if I give it a try to tentatively use Windbg as a static hex editor. I was thinking about that I could use my plugin commands, and many built-in Windbg commands. It sounds very good because those commands are powerful. My second thought was if there was anything that I can achieve in hex editor but cannot in Windbg. I can't name anything so far. Beyond that, I don't even miss the graphical interface.

To use Windbg as hex editor the first things that needs to be done is to open an application (say notepad.exe) to get Windbg prompt. In the further steps, there is nothing to do with the application. Once the prompt is given it waits for command to execute. .dvalloc command is used to allocate memory. .readmem command is to copy the the content of the file to the allocated memory area. There is a script called LoadFile.wds [SkyDrive] that does the job so it's enough to execute this with the correct parameters. Below is the script.
$$ Load file to memory.
$$ 
$$ It reads binary data from the specified file and copies the data to the pre-allocated memory area.
$$
$$ Example Usage: $$>a< e:/LoadFile.wds e:/test.exe 1000
$$
$$ Created: 8/September/2012

.if ( ${/d:$arg1} & ${/d:$arg2} )
{
  $$ Get the 5th token of .dvalloc (i.e Address)
  .foreach /pS 5 (Address {.dvalloc ${$arg2}})
  {
    .readmem ${$arg1} Address L?${$arg2}
    db Address L180
  }
}
.else
{
  .echo "Usage     : LoadFile.wds <file> <size>";
  .echo "Parameters: <file> - File to be loaded"
  .echo "            <size> - Size of the file"
  .echo "Example   : $$>a< e:/LoadFile.wds e:/test.exe 1000";
}
The following demonstrates when a file being loaded using LoadFile.wds script.
0:000> $$>a< c:/work/LoadFile.wds c:/work/test.exe 1800
Reading 1800 bytes...
007e0000  4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00  MZ..............
007e0010  b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00  ........@.......
007e0020  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
007e0030  00 00 00 00 00 00 00 00-00 00 00 00 f0 00 00 00  ................
007e0040  0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68  ........!..L.!Th
007e0050  69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f  is program canno
007e0060  74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20  t be run in DOS 
007e0070  6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00  mode....$.......
007e0080  f1 3e 51 d1 b5 5f 3f 82-b5 5f 3f 82 b5 5f 3f 82  .>Q.._?.._?.._?.
007e0090  ae c2 a3 82 b6 5f 3f 82-ae c2 a1 82 b4 5f 3f 82  ....._?......_?.
007e00a0  ae c2 95 82 a6 5f 3f 82-ae c2 94 82 b7 5f 3f 82  ....._?......_?.
007e00b0  bc 27 ac 82 b7 5f 3f 82-b5 5f 3e 82 9c 5f 3f 82  .'..._?.._>.._?.
007e00c0  ae c2 90 82 b7 5f 3f 82-ae c2 a2 82 b4 5f 3f 82  ....._?......_?.
007e00d0  52 69 63 68 b5 5f 3f 82-00 00 00 00 00 00 00 00  Rich._?.........
007e00e0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
007e00f0  50 45 00 00 4c 01 04 00-6f c2 38 50 00 00 00 00  PE..L...o.8P....
007e0100  00 00 00 00 e0 00 03 01-0b 01 0a 00 00 0a 00 00  ................
007e0110  00 0a 00 00 00 00 00 00-df 12 00 00 00 10 00 00  ................
007e0120  00 20 00 00 00 00 40 00-00 10 00 00 00 02 00 00  . ....@.........
007e0130  05 00 01 00 00 00 00 00-05 00 01 00 00 00 00 00  ................
007e0140  00 50 00 00 00 04 00 00-03 74 00 00 03 00 00 81  .P.......t......
007e0150  00 00 10 00 00 10 00 00-00 00 10 00 00 10 00 00  ................
007e0160  00 00 00 00 10 00 00 00-00 00 00 00 00 00 00 00  ................
007e0170  24 22 00 00 3c 00 00 00-00 40 00 00 b4 01 00 00  $"..<....@......
Important safety note is that the script uses .dvalloc command to allocate the memory for the data. As a consequence, the memory area has the protection flag of PAGE_EXECUTE_READWRITE. Therefore code execution from the memory page is possible even though it requires series of mistakes to make.

September 2, 2012

Timeline for Fix of an Arbitrary Address Write Bug

In today's post I'm writing about an arbitrary address write bug in Flash Player in Firefox (CVE-2012-4171) that is now fixed.

The issue was reported to Mozilla, but the fix made by Adobe as it turned out it was a bug in the Flash Player. The bug was tracked in Mozilla's bug tracking system (BugZilla) here [still restricted at the time of writing].

To trigger this vulnerability there is no requirement to use malformed data in any way. All the constructs can be legitimate. The PoC demonstrates when the security dialog box is shown it is possible to navigate to an other page that pops up another security dialog while the first dialog is still visible. When the second dialog is OK'd Flash Player crashes.

Below code snippet demonstrates the vulnerable code path.
mov     ecx,dword ptr [esi+4]           *(1)
<STRIPPED>
mov     esi,ecx
add     dword ptr [esi+1B8h],0FFFFFFFFh *(2)
At line (1) [ESI+4] is an address in a valid heap region. The heap can be arranged to contain user controlled data. Therefore, at line (2) an attacker can write arbitrary address using add instruction. Due to depending on add instruction the attacker has limited control what data to write.

Below is the timeline for the fix.
Days Date Channel Action
0 days 25-Jan-2010 E-mailReport sent to Mozilla.
0 days 25-Jan-2010 E-mailMozilla confirms the behavior described in the report. A case opened in the bug tracking database (BugZilla).
731 days 26-Jan-2012 BugZillaA Mozilla engineer says he can reproduce the issue with Firefox 9 on Windows 7 but cannot reproduce with nightly build.
731 days 26-Jan-2012 BugZilla An Adobe engineer says they will triage this issue ASAP.
749 days 13-Feb-2012 BugZilla A Mozilla engineer asks for status update from Adobe.
749 days 13-Feb-2012 BugZilla An Adobe engineer confirms he cannot reproduce the crash.
749 days 13-Feb-2012 BugZilla An Adobe engineer confirms he can reproduce the crash by experimenting with waiting times before clicking "OK" on the prompt.
749 days 13-Feb-2012 BugZilla Reporter recommends to switch off plugin-container introduced since the report to get consistent crash state.
779 days 14-March-2012 E-mailReporter asks for status update, and points out the existing testcase reliably crashes Firefox when plugin-container disabled.
779 days 14-March-2012 E-mailMozilla confirm there is no other update on the case, than seen in BugZilla. Mozilla asks to put additional information about crashes.
780 days 15-March-2012 BugZilla Reporter adds additional information about crashes.
780 days 15-March-2012 E-mailReporter asks for an estimation of the date of the fix.
780 days 15-March-2012 E-mailMozilla confirm they don't have an estimation. They say to have to see what the developers can do with it in the short term.
780 days 15-March-2012 E-mailIn response to an earlier email Mozilla say "flash bugs are often slow to be fixed".
805 days 9-Apr-2012 E-mailReporter decided to share crash information with CERT, and asked if they can help motivating the vendor to issue a patch.
805 days 9-Apr-2012 E-mailCERT confirm they have spoken with the vendor.
806 days 10-Apr-2012 BugZilla Mozilla say they effectively mitigated this issue with out of process plugins and they require a testcase which crashes Firefox in an exploitable manner.
806 days 10-Apr-2012 BugZilla Reporter responses that existing testcase crashes Firefox in 1/10 ratio on reporter side. With plugin-container disabled it crashes Firefox in 10/10 ratio.
807 days 11-Apr-2012 BugZilla An Adobe engineer confirms they cannot reproduce the issue.
808 days 12-Apr-2012 BugZilla Reporter recommends to disable plugin-container to get a consistent crash state. Reporter also highlights plugin container is just a mitigation that could be bypassed.
808 days 12-Apr-2012 BugZilla A Mozilla Security Researcher asks how the plugin-container could be bypassed.
808 days 12-Apr-2012 BugZilla Reporter highlights attack surfaces but he also states discussing how to bypass mitigation is out of the scope of this bug.
814 days 18-Apr-2012 BugZilla Adobe say they have a good set of test cases for this issue now, and this will be fixed in the following release.
861 days 4-June-2012 BugZilla Adobe confirm it is fixed in 11.4.400.128. [This seems to be an internal build]
939 days 21-Aug-2012 WebFix released in 11.4.402.265. To see Adobe's Security Bulletin click here.
N/A 27-Aug-2012 BugZilla Adobe confirm 11.4.402.265 is released on 21st of August and mark the bug as fixed.
N/A 29-Aug-2012 E-mailReporter checks Adobe's Security Bulletin and realizes this bug is not mentioned in it. Asks Adobe regarding CVE number.
N/A 30-Aug-2012 E-mailAdobe confirm the Security Bulletin has been updated with the CVE number.
This timeline contains the technically important communications. If you are aware of that I missed something that you think is important to mention, please let me know and I'll update this page.

Thanks for those who involved from Mozilla, Adobe and CERT.
  This blog is written and maintained by Attila Suszter. Read in Feed Reader.