Didier Stevens

Tuesday 18 January 2011

Quickpost: Checking ASLR

Filed under: Quickpost,Uncategorized,Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 11:13

Some people asked me for a simple way to check shell extensions for their ASLR support. You can do this with Process Explorer.

Start Process Explorer, and set the lower pane to display DLLs. Select process explorer.exe, and add column ASLR to the lower pane view. Then sort on column ASLR.

You will see this:

Notice that on a default Windows 7 32-bits install all DLLs (with code) support ASLR. The n/a is for resource DLLs, they don’t contain code, and ASLR doesn’t apply to them.

Now open an explorer window and right-click a file, like this:

This action will load the context menu shell extensions.

Take a look at Process Explorer:

Now you see the shell extensions without ASLR support.


Quickpost info


Wednesday 1 December 2010

Runasil

Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 9:56

Because I didn’t find a program to start an application with a given integrity level from “Image File Execution Options”, I wrote runasil.

The following command launches notepad.exe with a low integrity level, instructing notepad to open test.txt:

runasil.exe notepad.exe test.txt

To automatically launch notepad via runasil.exe, using “Image File Execution Options”, create this registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe and create a value debugger equal to “runasil.exe -d” (don’t forget option -d).

You can also specify the integrity level via an option:

  • -l for low
  • -m for medium
  • -h for high
  • -s for system

By default, runasil launches the application with a low integrity level.

Don’t forget you need at least Windows Vista to use integrity levels, and that a process can’t create a new process with a higher integrity level than itself.

Download:

runasil_V0_0_0_1.zip (https)

MD5: 5B8CE64715903DD7EEF4AF3B89E6E6FD

SHA256: 15841A9D9985E626C5B70B4BC3B2BF2CD68C38102B6BB1D92BA352D19F5C8A65

Monday 8 November 2010

EnforcePermanentDEP

Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 0:45

Like its name reveals, EnforcePermanentDEP is a DLL to switch on permanent DEP in the loading process.

When loaded inside a process, this DLL will call SetProcessDEPPolicy with argument PROCESS_DEP_ENABLE, hereby enabling DEP permanently on the loading process. After this, DEP can’t be disabled anymore for this process.

Once DEP is set, this DLL unloads itself. There is no need for this DLL to remain loaded once it has enabled DEP. This is done via the entry point DllMain function which returns FALSE for DLL_PROCESS_ATTACH, hereby making that the DLL doesn’t remain loaded inside the process.

To load this DLL inside a process, you can add it to the import table of the target process (EnforcePermanentDEP.dll exports function Dummy), use LoadDLLViaAppInit or use your own preferred injection method.

Download:

EnforcePermanentDEP_V0_0_0_1.zip (https)

MD5: B0A89B0CE8DC5BA2472B3D744D40E4A3

SHA256: 525BA6EF82BD2B0ABD30DAD0D676CE085A9FA6E0DE3E3A8A0ADD6DF050F5A635

Sunday 17 October 2010

setdllcharacteristics

Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 20:39

The PE-file format specifies flags to enable DEP and ASLR. You can set these flags with a hex-editor or a PE-file editor.

Because I need to set DEP and ASLR flags in a script, I wrote a C-program to read, set or clear these flags (together with another flag to check AuthentiCode signatures, more about this later).

It’s a standard C program, you can compile it under *nix too.

The option handling is simple, you can’t combine flags into one option string. For example, to set DEP and ASLR, you issue the following command:

setdllcharacteristics +n +d program.exe

This will not work:

setdllcharacteristics +nd program.exe

Don’t forget that by changing these flags on signed executables, the signature is not valid anymore. But that shouldn’t be a problem to run the program.

Later, I’ll post tools to force DEP (and maybe ASLR) without changing the PE file.

And I also updated the PE-file format template for the 010 editor to support these 3 flags.

Download:

setdllcharacteristics_v0_0_0_1.zip (https)

MD5: F96358BF90AA4D8C6B32968B2068BFCB

SHA256: 5A9D3815F317C7C0FF7737F271CE0C60BE2CB0F4168C5EA5AD8CEF84AD718577

Monday 11 October 2010

PDF, DEP, ASLR and Integrity Levels

Filed under: PDF,Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 8:41

Frequently targeted document handling applications should be coded defensively and protect themselves with Windows security features like DEP, ASLR and Integrity Levels, just to name a few.

I tested a couple of PDF rendering applications: Adobe Reader, Foxit Reader and Sumatra PDF. If the application did not use DEP, ASLR or Integrity Levels, I changed some settings to make the application use these features. Setting DEP and ASLR is just setting a flag in the DllCharacteristics member of the Image Optional Header structure. You can do this with a hex editor, a PE-file editor, or a new tool (setdllcharacteristics) I’ll release soon. Using a Low Integrity Level is done by setting the appropriate ACE in the DACL of the application executable, see my post Integrity Levels and DLL Injection for details.

Adobe Reader 9 uses DEP and ASLR. It does not run with a Low Integrity Level by default. Configuring acrord32.exe to run with a Low Integrity Level fails, the application doesn’t run. It is said that the upcoming Adobe Reader 10 with sandboxing technology will run at a Low Integrity Level.

Sumatra PDF 1.1 uses DEP and ASLR. It does not run with a Low Integrity Level by default. Configuring SumatraPDF.exe to run with a Low Integrity Level succeeds, the application runs fine. Some preferences might get lost, but they are not important to me.

With version 4.2 of Foxit Reader released about a week ago, Foxit Software added support for DEP and ASLR. Setting Foxit Reader to use a Low Integrity Level results in a malformed opening dialog box:

Apart from this, Foxit Reader appears to work fine at Low Integrity Level, but don’t be fooled. At Low Integrity Level, Foxit Reader can’t read or set its preferences. For example, you won’t be able to disable JavaScript. Even if you disabled JavaScript with Foxit Reader running at Medium Integrity Level (the default), Foxit Reader running at Low Integrity Level will enable JavaScript. So you’re better off not using a Low Integrity Level for this version. I’ve talked to Foxit Software and they’ll fix this.

If your favorite application isn’t discussed here, you can easily check how it performs with Sysinternals’ Process Explorer. Just add columns DEP, ASLR and Integrity to Process Explorer’s main view and run your application.

Tuesday 7 September 2010

Integrity Levels and DLL Injection

Filed under: bpmtk,Windows 7,Windows Vista — Didier Stevens @ 0:53

Microsoft introduced a new kernel security feature with Windows Vista: Integrity Levels. Each process has an integrity level: Low, Medium, High or System. A process with a lower integrity level can’t write to an object with a higher integrity level.

For processes, this means that a process with low integrity level can’t open a handle with full access to a process with medium integrity level. This is what I’ll show in this post: a process with low integrity level can’t inject a DLL in a process with medium (or higher) integrity level.

Normal, non-elevated processes run with medium integrity level by default. Here I inject a DLL into notepad.exe with my bpmtk utility:

The integrity level of the cmd.exe process is medium, and therefor the integrity level of bpmtk.exe (launched by cmd.exe) is also medium. Because the integrity level of the notepad.exe process is also medium, the DLL injection succeeds.

To help you identify the integrity level of processes on your machine, you can add an integrity level column to process explorer:

Now we’ll do the same DLL injection from a cmd.exe and bpmtk.exe process with low integrity level.

The icacls.exe utility can be used to view and set integrity levels. Because I don’t want to change the integrity level of the original cmd.exe, I’m making a copy of cmd.exe: cmd-low-il.exe. Cmd-low-il.exe has no explicit integrity level:

When we set an explicit integrity level (low) on cmd-low-il.exe with icacls.exe, cmd-low-il.exe will run with low integrity level in stead of medium. And every program started by this cmd-low-il.exe process will also run with low integrity level.

You need admin right to assign a low integrity level to cmd-low-il.exe:

Here you can see the low integrity level setting:

When we start cmd-il-low.exe, it will run with low integrity level. Executing bpmtk.exe from cmd-il-low.exe will force bpmtk.exe to run with low integrity level. bpmtk.exe fails to inject the DLL. When bpmtk.exe tries to open a handle with full access to notepad.exe, the call to OpenProcess fails with access denied. Notepad.exe runs with medium integrity level, and bpmtk.exe running with low integrity level has no right to open a handle to modify the notepad.exe process.

Integrity Levels look like a good security feature to sandbox vulnerable, Internet facing applications. But there are issues I’ll highlight in an upcoming post.

Monday 4 January 2010

New Format for UserAssist Registry Keys

Filed under: Forensics,My Software,Windows 7 — Didier Stevens @ 15:29

With Windows 7 and Windows Server 2008 R2, the binary data format of the values stored in the UserAssist registry keys has changed.

Here’s a partial description of the new format:

  • the counter is 32-bits long, starting at byte 4 (first byte is byte 0)
  • the timestamp (64-bits) starts at byte 60
  • there is a 32-bit value that appears to be the total time an application has focus, expressed in milli-seconds (starts at byte 8 )

For more details, read my article in the new forensic magazine Into The Boxes.

Don’t forget to use the special version of my UserAssist tool on Windows 7 and Windows Server 2008 R2.

Sunday 22 November 2009

Quickpost: SelectMyParent or Playing With the Windows Process Tree

Filed under: Forensics,My Software,Windows 7,Windows Vista — Didier Stevens @ 20:36

I read something very interesting in “Windows via C/C++” today: starting with Windows Vista, CreateProcess can start a program where you specify the parent process! This is something forensic investigators must be aware of when they analyse processes running on a Windows machine.

Normally the parent process of a new process is the process that created the new process (via CreateProcess). But when using STARTUPINFOEX with the right LPPROC_THREAD_ATTRIBUTE_LIST to create a process, you can arbitrarely specify the parent process, provided you have the rights (i.e. it’s your process or you have debug rights).

I developed a small tool to start a program while specifying its parent process: SelectMyParent. Here I use it to start notepad as a child of lsass.exe:

2 remarks about this example:

  1. to make lsass.exe a parent process, you need to use SelectMyParent with admin rights and elevate its rights (Run as administrator)
  2. the notepad process takes over the parent process’ account: NT AUTHORITY\SYSTEM

I don’t know how one can detect that a process’ parent is not the process that created it, because a process has no access to its extended startup info (only to its startup info). And it is the extended startup info that contains the attribute list with the handle to the parent process.

SelectMyParent version 0.0.0.1 is available here.


Quickpost info

 


Wednesday 21 October 2009

A Windows 7 Launch Party Trick!

Filed under: Entertainment,Forensics,My Software,Windows 7 — Didier Stevens @ 17:19

In search of a new trick for that Windows 7 Launch Party you’re invited to? 😉

Here’s one:

20091021-190621

You can download a beta version of my UserAssist tool here. Soon I’ll be posting a final version with details and source code.

Thursday 29 January 2009

Quickpost: Vigenère Is Beta-Only

Filed under: Encryption,Forensics,Quickpost,Windows 7 — Didier Stevens @ 8:41

I asked Steve Riley if he has inside information on the move from ROT13 to Vigenère for the UserAssist keys. It’s part of the beta program, to test upgrades. The final version of Windows 7 and Windows 2008 R2 will use ROT13 for the UserAssist keys, which has been used since Windows 2000.

The binary format of the UserAssist keys has also changed, I’ve decoded most of it.

Here’s Steve’s complete answer, published with permission:

We used ROT-13 to obfuscate UserAssist for its historical Usenet purpose — not to try to secure the data, but to express that the data shouldn’t be tampered with. Sort of like claiming “Don’t peek and definitely don’t modify unless you’re prepared to deal with the consequences. You’ve been warned.” There are times, like this one, where simple obfuscation is technically justified. ROT-13 was never an encryption scheme, everyone fully expects everyone else to recognize ROT-13 on sight, and some people even developed the ability to read it directly. ROT-13 was an easy and inexpensive way to invoke an implicit social contract.

As you know, UserAssist stores the info about your most frequently used applications for display on the Start menu. (Basic principles at http://blogs.msdn.com/oldnewthing/archive/2007/06/11/3215739.aspx.) The data isn’t confidential and doesn’t need to be encrypted — after all, opening the Start menu displays it. However, its stored format is subject to change, and we don’t want applications or people unintentionally changing it. So we ROT-13ed it, in a geeky attempt to convey exactly the same message that ROT-13 signified on Usenet.

In Windows 7 we made some changes to the way the MFU list is maintained and to the data’s storage format in UserAssist. When you upgrade from a previous version of Windows, we clear the MFU list and start anew. We don’t want old data to carry forward into this key. Changing the encoding from ROT-13 to Vigenère makes it easier for us to test that we’re getting the behavior we want — it’s obvious if old data carries over, because ROT-13ed data makes no sense to Vigenère. This is very useful in pre-release builds while we’re shaking the bugs out.

However, there’s no such benefit to using Vigenère in the final release — it doesn’t convey the same message as ROT-13, and since it’s key-based, it’s easy to mistake Vigenère for true encryption. Therefore, in the final release of Windows 7, we’ll revert to using ROT-13 for UserAssist.

Hope this helps clarify the issue. Feel free to post my email on your blog, too. Incidentally, we have plenty of real crypto in Windows 7 — check out the performance improvements to our AES implementation, for example.


Quickpost info


« Previous PageNext Page »

Blog at WordPress.com.