Hi @ll,
since Microsoft won't -- despite (hopefully not only) my constant
nagging and quite some bug reports about unquoted command lines
for more than a dozen years now -- fix the BRAINDEAD behaviour
of Windows' CreateProcess*() functions to play try&error instead
of returning on error to their caller when interpreting their
lpCommandLine argument which lets the BLOODY BEGINNER's error
known as CWE-428 <https://cwe.mitre.org/data/definitions/428.html>
go undetected, I'll show some methods including the preconditions
on how to exploit it, i.e. execute a file of my choice.
JFTR: none of these methods should be new or unknown to any
Windows administrator, developer or QA engineer.-P
JFTR: in Microsoft's own terms these methods don't qualify as
security vulnerabilities due to their precondition(s).
#1. Preconditions:
* a file in %SystemDrive%\ which can be opened with the
access rights GENERIC_WRITE | DELETE and the attribute
FILE_FLAG_BACKUP_SEMANTICS;
* a user account holding the privilege SE_RESTORE_NAME.
<https://msdn.microsoft.com/en-us/library/aa365543.aspx>
Exploit:
handle = CreateFile(L"C:\\...", GENERIC_WRITE | DELETE,
..., NULL, OPEN_EXISTING,
FILE_FLAG_BACKUP_SEMANTICS, NULL);
SetFileShortName(handle, L"PROGRAM.EXE)
#2. Preconditions:
* an empty file in %SystemDrive%\ which can be opened with
the access rights FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES
and the attribute FILE_FLAG_OPEN_REPARSE_POINT;
* a user account holding the privileges SE_RESTORE_NAME and
SE_CREATE_SYMBOLIC_LINK_NAME.
Exploit:
handle = CreateFile(L"C:\\...",
FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES,
..., NULL, OPEN_EXISTING,
FILE_FLAG_OPEN_REPARSE_POINT, NULL);
DeviceIoControl(handle, FSCTL_SET_REPARSE_POINT, ...
Now wait until some program written by a dimwit of a developer
who (and of course his/her supervisors and QA too) never heard
of "long" filenames (which means they must have lived beneath
a rock for more than 20 years) executes your C:\PROGRAM.EXE
20+ years old: <https://support.microsoft.com/kb/102739/en-us>
<https://support.microsoft.com/kb/134425/en-us>
~20 years old: <https://support.microsoft.com/kb/170669/en-us>
10+ years old: <https://support.microsoft.com/kb/812486/en-us>
Primary candidates: Apple iTunes, Microsoft .NET Framework 3.5
SP1 x64 (as preinstalled on Windows 7 x64 and Windows 2008 R2 AD
controllers), WHQL-certified drivers from HP, ALPS[*], Realtek[*],
Samsung, Synaptics, ... (many of those are available per Windows
Update and the Microsoft Update Catalog), MANY games, ...
As Microsoft's Aaron Margosis wrote last November pointing out
this BLOODY BEGINNER's error is unnessarily alarmist:
<http://blogs.msdn.com/b/aaron_margosis/archive/2014/11/14/it-rather-involved-being-on-the-other-side-of-this-airtight-hatchway-unqu
oted-service-paths.aspx>
Of course all non-alarmists know for sure that the above named
preconditions don't exist anywhere.-(
What but REALLY alarmist is: companies like Apple release version
after version of their products/drivers^Wcrapware without the
TRIVIAL fix for this well-known vulnerability, even when notified
over and over again!
"Defense in depth"?
Nope!
"Software engineering"?
Nope!
BRAINDEAD behaviour of Windows CreateProcess*() functions?
Yes, of course, always!
Taking care for the safety and security of their customers systems?
Nope!
stay tuned (and far away from crapware!)
Stefan Kanthak
[*] see <https://support.microsoft.com/library/images/2647325.png>
