{
	"id": "be4b64f3-1397-4e52-9ac7-187590c455ff",
	"created_at": "2026-04-06T00:16:34.186776Z",
	"updated_at": "2026-04-10T03:21:55.095939Z",
	"deleted_at": null,
	"sha1_hash": "178d7a286e0c4087fb9d1b8deaa18c6b9beb065d",
	"title": "Help eliminate unquoted path vulnerabilities - SANS ISC",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 179850,
	"plain_text": "Help eliminate unquoted path vulnerabilities - SANS ISC\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 17:03:36 UTC\r\nMetasploit’s “Service Trusted Path Privilege Escalation” exploit takes advantage of unquoted service paths\r\nvulnerability outline in CVE-2005-1185, CVE=2005-2938 and CVE-2000-1128.    The vulnerability takes\r\nadvantage of the way Windows parses directory paths to execute code.   Consider the following command line.\r\nC:\\windows\\system32\\notepad \\temp\\file.txt\r\nThis tells windows to launch notepad.exe from the c:\\windows\\system32\\ directory and pass it the argument\r\n\\temp\\file.txt.    The result is notepad.exe will execute and begin editing file.txt from the temp directory.    How\r\ndoes Window’s differentiate between the program and the arguments?  The SPACE is used as a delimiter between\r\nthe program to execute and the arguments.   Now consider this command line.\r\nC:\\program files\\Microsoft Office\\Winword.exe\r\nIf space is used as a delimiter, wouldn’t Windows think you are trying to execute the program \r\nC:\\PROGRAM.EXE and pass it the argument “files\\Microsoft Office\\Winword.exe”?    Or maybe you are trying\r\nto execute “C:\\Program files\\Microsoft.exe” and pass it the argument “Office\\Winword.exe”?  So how does it\r\nknow what you are trying to do?    If the software developer places quotation marks around the path then\r\nWindows knows the spaces are spaces and not delimiters.   If the software developer fails to put the path in quotes\r\nthen Windows just doesn’t know.  If Windows doesn’t know then it tries to execute all the possible programs in\r\nthe path.  First it tries “C:\\Program.exe”,   Then, it tries “C:\\Program files\\Microsoft.exe” and finally the path\r\nwe intended for it to execute.    \r\nThis programming error is very common because when a developer is addressing paths on the file system they are\r\nusually stored in strings.   Because they are in strings the developer has used quotes once already and they often\r\nfail to consider that they need two sets of quotes.  For example, the following line would incorrectly assign the\r\npath variable.\r\npathvariable = “C:\\Program Files\\Common Files\\Java\\Java Update\\jusched.exe”\r\nReally, the developer needs to double quote it because they need the path to contain quotes.  So they should have\r\nassigned their variable by doing something like this:\r\npathvariable = “\\\\”C:\\Program Files\\Common Files\\Java\\Java Update\\jusched.exe\\\\””\r\nIn the first case, an attacker can strategically place a program in the path and his program will be executed instead\r\nof the intended program.   If the process runs under administrative privileges or some account other than the\r\nattacker it can be used to cause code to execute under a different set of privileges.  \r\nhttps://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464\r\nPage 1 of 3\n\nWe have known about these types of vulnerabilities for 12 years now.  So much so, that if you create a file called\r\nc:\\program.exe Windows will generate this pop up when you reboot the machine.\r\nWith such an old vulnerability, surely very few programs suffer from this problem, right?  You might be surprised\r\nat how often this vulnerability occurs.     So let’s start fixing it!    This is an easy problem to identify.    Here are\r\nsome steps you can follow to identify applications that fail to quote their file paths directly.    Then you can help\r\nfix this by contacting the vendor to have them fix these issues.\r\nFirst you need to copy any existing executable and create a program named c:\\program.exe.   For example, take a\r\ncopy of calc.exe and name it c:\\program.exe.   Then make a copy of calc.exe named c:\\program\r\nfiles\\common.exe.  Last, create a copy of calc.exe called c:\\documents.exe.    Then go about your business and use\r\nyour computer as you normally would.    Sometime while you are running normal applications they will\r\naccidently launch the renamed calc.exe.   System reboots, services and scheduled tasks may trigger calculator.   \r\nWhatever the cause, eventually you will likely run a vulnerable program and it will launch the application on your\r\ncomputer.   Several days may transpire between the time you create the files and the time they are executed.  \r\nRemember you did this when you have strange copies of calc.exe spontaneously launching on your computer.  \r\nOnce one your copy of calculator executes, first find out which one of your calc.exe programs launched and who\r\nlaunched it.    Use WMIC to query which copy of your calculator is running like this.\r\nHere you can see this query for “program.exe” returns the command line that was executed when our executable\r\nlaunched.   This program failed to properly quote the system paths and launched your renamed program.    Often\r\nhttps://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464\r\nPage 2 of 3\n\ntimes you may be able to identify the vendor responsible for the software from just the command line that\r\nlaunched your program.     But often times it is also useful to know the parent process that launched the command\r\nline that started your program.   To find out what program launched the unquoted path we use the following\r\ncommands.\r\nThere you go bug hunter.  You found a 0-Day vulnerability!  Now notify the vendor so they can patch it and keep\r\neveryone safe.  While you are at it you can notify us if you would like.\r\nJoin me in San Antonio Texas November 27th for SANS 504 Hacker Techniques, Exploits and Incident\r\nResponse!  Register Today!!\r\nFollow me on Twitter @MarkBaggett\r\nMark Baggett\r\nUpdate: Here are some additional references.  Thanks to altonius for the linksblakhal0 for the post that inspired\r\nthis.\r\nhttp://blakhal0.blogspot.com/2012/08/hiding-files-by-exploiting-spaces-in.html\r\nhttp://xato.net/hardening/the-programexe-problem/\r\nhttp://www.commonexploits.com/?p=658\r\nSource: https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464\r\nhttps://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464"
	],
	"report_names": [
		"14464"
	],
	"threat_actors": [],
	"ts_created_at": 1775434594,
	"ts_updated_at": 1775791315,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/178d7a286e0c4087fb9d1b8deaa18c6b9beb065d.pdf",
		"text": "https://archive.orkl.eu/178d7a286e0c4087fb9d1b8deaa18c6b9beb065d.txt",
		"img": "https://archive.orkl.eu/178d7a286e0c4087fb9d1b8deaa18c6b9beb065d.jpg"
	}
}