the import function of Windows Mail executes a rogue program C:\Program.exe
with the credentials of another account, resulting in a privilege escalation!
1. Fetch <http://home.arcor.de/
C:\Program.exe
2. Start Windows Mail (part of Windows Vista and Windows Server 2008)
3. On the File menu, click Identities
4. On the entry page of the wizard click [ Continue > ]
5. Select "(*) Import identities of other Windows account" and click [ Continue > ]
6. Enter account name and password of any Windows account
7. See the message from C:\Program.exe when Windows Mail runs the UNQUOTED
command line C:\Program Files\Windows Mail\WinMail.Exe /identcatalog
From <http://msdn.microsoft.com/
or <http://msdn.microsoft.com/
| Note: If any element of the command string contains or might contain
| spaces, it must be enclosed in quotation marks. Otherwise, if the
| element contains a space, it will not parse correctly. For instance,
| "My Program.exe" starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument.
From <http://msdn.microsoft.com/en-
| Security Remarks
|
| The lpApplicationName parameter can be NULL, and the executable name
| must be the first white space-delimited string in lpCommandLine.
| If the executable or path name has a space in it, there is a risk that
| a different executable could be run because of the way the function
| parses spaces. Avoid the following example, because the function
| attempts to run "Program.exe", if it exists, instead of "MyApp.exe".
...
| If a malicious user were to create an application called "Program.exe"
| on a system, any program that incorrectly calls CreateProcess using
| the Program Files directory will run this application instead of the
| intended application.
|
| To avoid this problem, do not pass NULL for lpApplicationName.
| If you do pass NULL for lpApplicationName, use quotation marks around
| the executable path in lpCommandLine, as shown in the example below.
"Long" filenames were introduced 20 years ago, but M$FTs developers still
can't handle them properly, and their QA is unable to detect such silly
and trivial to spot bugs!
regards
Stefan Kanthak
PS: yes, it needs administrative privileges to write C:\Program.exe.
BUT: all the user account(s) created during Windows setup have
administrative privileges.
PPS: NO, the user account control is NO security boundary!
<http://support.microsoft.com/
| Same-desktop Elevation in UAC is not a security boundary and can be hijacked
| by unprivileged software that runs on the same desktop. Same-desktop
| Elevation should be considered a convenience feature, and from a security
| perspective, "Protected Administrator" should be considered the equivalent
| of "Administrator."
Komentarų nėra:
Rašyti komentarą