次の方法で共有

Signed Binaries in Non-trusted Locations

  • [アーティクル]

When you inadvertently copy the complete cmd.exe to your quick launch bar instead of creating a shortcut, you get some interesting behavior on launching it elevated. Instead of good old trusted elevation prompt, we get the untrusted version.

Interesting. Surely the binary hasn't changed when copying it over? Let's check with sigcheck. Here is the original from system32:

C:\Windows\system32>sigcheck cmd.exe
Sigcheck v1.4
Copyright (C) 2004-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Windows\system32\cmd.exe:

Verified: Signed
Signing date: 4:14 AM 11/2/2006
Publisher: Microsoft Corporation
Description: Windows Command Processor
Product: Microsoft« Windows« Operating System
Version: 6.0.6000.16386
File version: 6.0.6000.16386 (vista_rtm.061101-2205)

And the copied version:

C:\Windows\system32>sigcheck "C:\Users\maartenb\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\cmd.exe"
Sigcheck v1.4
Copyright (C) 2004-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\users\maartenb\appdata\roaming\microsoft\internet explorer\quick launch\cmd.exe:

Verified: Signed
Signing date: 4:14 AM 11/2/2006
Publisher: Microsoft Corporation
Description: Windows Command Processor
Product: Microsoft« Windows« Operating System
Version: 6.0.6000.16386
File version: 6.0.6000.16386 (vista_rtm.061101-2205)

Sure enough. Same version, same file, both signed by Microsoft. So something else must be going on.

It turns out that Vista only shows the trusted consent dialog if the application is launched from a safe location, in this case System32. Due to the changed probing path (a command line application would first look for dlls in the application's directory), it would be trivial to load a rogue dll instead of a trusted version. The dialog doesn't mention this explicitly but the warning is certainly justified.

Comments