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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Jul 2020 23:40:48 +0200 From: "Stefan Kanthak" <stefan.kanthak@...go.de> To: <fulldisclosure@...lists.org> Cc: bugtraq@...urityfocus.com Subject: [FD] Defense in depth -- the Microsoft way (part 70): CVE-2014-0315 alias MS14-019 revisited Hi @ll, This multi-part post can be read even without a MIME-compliant program! Back in 2014, I reported a vulnerability in CreateProcess()'s handling of *.cmd and *.bat files that Microsoft fixed with MS14-019 alias MSKB 2922229 and assigned CVE-2014-0315: command lines with a batch script as first token led to the execution of a (rogue) cmd.exe from the CWD (or the search path). <https://blogs.technet.microsoft.com/srd/2014/04/08/ms14-019-fixing-a-binary-hijacking-via-cmd-or-bat-file/> provides some details about the vulnerabilities attack vector. With that in mind, read the documentation of the command processors START builtin command <https://msdn.microsoft.com/en-us/library/cc770297.aspx> or <https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/start> | * When you run a command that contains the string "CMD" as the first token | without an extension or path qualifier, "CMD" is replaced with the value | of the COMSPEC variable. This prevents users from picking up cmd from | the current directory. This statement is but WRONG: START CMD ... picks a rogue cmd.exe from the CWD! Demonstration/Proof of concept #1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On a default installation of Windows XP or any newer version, start the command processor CMD.EXE and run the following commands: CHDIR /D "%TMP%" COPY "%SystemRoot%\Write.exe" Cmd.exe SET COMSPEC= SET PATH= START CMD /C PAUSE This weakness is well-known and well-documented: see <https://cwe.mitre.org/data/definitions/73.html>, <https://cwe.mitre.org/data/definitions/426.html> and <https://cwe.mitre.org/data/definitions/427.html> For some of the well-known attacks see <https://capec.mitre.org/data/definitions/13.html> and <https://capec.mitre.org/data/definitions/471.html> Now continue with the documentation of the command processors FOR builtin command <https://msdn.microsoft.com/en-us/library/cc754900.aspx> or <https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/for> | * Parsing output: | You can use the for /f command to parse the output of a command by placing | a back-quoted <command> between the parentheses. Back-quoted is only correct with FOR /F "UseBackQ" %<var> IN (´<command>´) DO ... Without "UseBackQ" the command needs to be placed in single quotes! | It is treated as a command line, which is passed to a child Cmd.exe. That too is wrong: if COMSPEC is set, its value is used as file/pathname of the child process; Cmd.exe is used only if COMSPEC is not set! Demonstration/Proof of concept #2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On a default installation of Windows XP or any newer version, start the command processor CMD.EXE and run the following commands: SET COMSPEC=%SystemRoot%\System32\Reg.exe FOR /F %? IN ('SET') DO @ECHO %? Evaluating COMSPEC inside the command processor or executing the hard-coded file Cmd.exe is both clumsy and unsafe! The command processor can and should determine its own module name instead. For a third bug and vulnerability see the following undocumented and outright BRAINDEAD behaviour. Demonstration/Proof of concept #3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On a default installation of Windows XP or any newer version, start the command processor CMD.EXE and run the following commands: SET COMSPEC=%SystemRoot%\System32\Reg.exe ASSOC | CALL ECHO | FTYPE SET | More.com ... Why does the command processor execute the EXTERNAL command specified in the environment variable COMSPEC to run its builtin INTERNAL commands? stay tuned, and far away from such blunders Stefan Kanthak PS: for more quirks see <https://skanthak.homepage.t-online.de/quirks.html> _______________________________________________ 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