Message-ID: <BAY404-EAS150C14D28DE79756439F605F2410@phx.gbl>
Date: Wed, 30 Apr 2014 19:18:40 -0400
From: Mike Cramer <mike.cramer@...look.com>
To: "'Brandon Perry'" <bperry.volatile@...il.com>,
	"'Alton Blom'" <altonius@...il.com>
Cc: fulldisclosure@...lists.org, 'Stefan Kanthak' <stefan.kanthak@...go.de>
Subject: Re: [FD] Beginners error: iTunes for Windows runs rogue program
	C:\Program.exe when opening associated files

Brandon,

I find little difference between 'Administrator' and 'SYSTEM' privilege,
although there is one. Administrators can create system-privileged services
and applications with relative ease.

To quote from MITRE's argument on this issue,
http://cwe.mitre.org/data/definitions/428.html

"This weakness could apply to any OS that supports spaces in filenames,
especially any OS that make it easy for a user to insert spaces into
filenames or folders, such as Windows. While spaces are technically
supported in Unix, the practice is generally avoided."

The practice of creating persistent services from temp directories is
"generally avoided". I see what you're saying, but the use case which you
mentioned is an extremely long shot scenario. While possible, it's not
likely going to happen.

Even crappy application developers are more likely to dump their executable
in C:\Windows than they are to run a service from C:\Windows\Temp\My
Application\myservice.exe", which would allow you to use "My.exe" to elevate
privilege.

-Mike

-----Original Message-----
From: Brandon Perry [mailto:bperry.volatile@...il.com] 
Sent: Wednesday, April 30, 2014 19:12
To: Alton Blom; Mike Cramer
Cc: fulldisclosure@...lists.org; Stefan Kanthak
Subject: Re: [FD] Beginners error: iTunes for Windows runs rogue program
C:\Program.exe when opening associated files

Also, keep in mind that it isn't just C:\Program.exe

What if a privileged application used an insecure temp directory with a
space that allowed an attacker on the system to escalate to system?

Full blown exploits can take advantage of multiple vulnerabilities that are
relatively harmless in and of themselves.

Is it a vulnerability? Totally. Is it particularly crazy or useful by
itself? Maybe not.


On 04/30/2014 05:17 PM, Alton Blom wrote:
> Hi Mike,
> It's probalby better seen as a way of keeping persistence on a machine 
> than a full-blown exploit.
>
> Alton(ius)
> altonblom.com
> @altonius_au
>
>
> On Thu, May 1, 2014 at 8:05 AM, Mike Cramer <mike.cramer@...look.com>
wrote:
>
>> I would like to know how this is a vulnerability.
>>
>> In order to write to the root of C:\, you need elevated privileges in 
>> Windows. Once someone gains elevated access, what does creating 
>> "C:\program.exe" offer them that they couldn't otherwise obtain?
>>
>> I have never actually seen malware take advantage of this, often 
>> times leveraging Kernel hooks and driver loading.
>>
>> It is unintended behavior, yes; but I'd consider it hardly a
vulnerability.
>>
>> -Mike
>>
>> -----Original Message-----
>> From: Fulldisclosure [mailto:fulldisclosure-bounces@...lists.org] On 
>> Behalf Of Alton Blom
>> Sent: Wednesday, April 30, 2014 17:51
>> To: Stefan Kanthak
>> Cc: fulldisclosure@...lists.org
>> Subject: Re: [FD] Beginners error: iTunes for Windows runs rogue 
>> program C:\Program.exe when opening associated files
>>
>> Hi Stefan,
>>
>> SANS had a good post on this a few years ago (
>>
>> https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabiliti
>> es/1446
>> 4),
>> which led to large number of services on windows machines with 
>> unquoted paths being discovered and fixed.  At that time I discovered 
>> that Windows Defender on Windows 7 had a problem like yours and 
>> reported it to Microsoft.
>> It took quite a while to get them to recognise it as a vulnerability, 
>> but it eventually led to 
>> https://technet.microsoft.com/en-us/library/security/ms13-058.aspx 
>> being released and Windows Defender being updated.
>>
>> At the same time I asked Tenable to create a plugin for Nessus that 
>> detects vulnerable services which they quickly released (plugin 
>> 63155).  This in turn led to a second round of vulnerable services 
>> being detected and patched by vendors.
>>
>> Also it's worth noting that OSVDB track these types of Vulns as 
>> "Authentication Required, Not a Vulnerability"
>>
>> Alton(ius)
>> altonblom.com
>>
>>
>> On Thu, May 1, 2014 at 5:02 AM, Stefan Kanthak
>> <stefan.kanthak@...go.de>wrote:
>>
>>> Hi @ll,
>>>
>>> the current version of iTunes for Windows (and of course older 
>>> versions
>>> too) associates the following vulnerable command lines with some of 
>>> the supported file types/extensions:
>>>
>>> daap=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> itls=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> itms=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> itmss=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> itsradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> iTunes=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> iTunes.AssocProtocol.daap=C:\Program Files (x86)\iTunes\iTunes.exe 
>>> /url "%1"
>>> iTunes.AssocProtocol.itls=C:\Program Files (x86)\iTunes\iTunes.exe 
>>> /url "%1"
>>> iTunes.AssocProtocol.itms=C:\Program Files (x86)\iTunes\iTunes.exe 
>>> /url "%1"
>>> iTunes.AssocProtocol.itmss=C:\Program Files (x86)\iTunes\iTunes.exe 
>>> /url"%1"
>>> iTunes.AssocProtocol.itpc=C:\Program Files (x86)\iTunes\iTunes.exe 
>>> /url "%1"
>>> iTunes.AssocProtocol.pcast=C:\Program Files (x86)\iTunes\iTunes.exe 
>>> /url"%1"
>>> itunesradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>> pcast=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>>>
>>>
>>> The command line registered under
>>>
>>> [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command
>>> ] @="C:\Program Files\iTunes\iTunes.exe"
>>>
>>> shows the same beginners error too: an unquoted pathname allows the 
>>> execution of the rogue programs "C:\Program.exe" or "C:\Program
>> Files.exe"
>>> instead of the intended executable.
>>>
>>>
>>> From <http://msdn.microsoft.com/library/cc144175.aspx>
>>> or <http://msdn.microsoft.com/library/cc144101.aspx>:
>>>
>>> | 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. You should always use quotation marks with arguments 
>>> | such as "%1" that are expanded to strings by the Shell, because 
>>> | you cannot be certain that the string will not contain a space.
>>>
>>>
>>> "Long" filenames containing spaces exist for about 20 years in Windows.
>>> It's REALLY time that every developer and every QA engineer knows 
>>> how to handle them properly.
>>>
>>>
>>> If you detect such silly bugs: report them and get them fixed.
>>> If the vendor does not fix them: trash the trash!
>>>
>>>
>>> JFTR: this bugs only exists since Microsoft "masks" it.
>>>       See <http://msdn.microsoft.com/library/ms682425.aspx> for this
>>>       well-known idiosyncrasy:
>>>
>>> | For example, consider the string "c:\program files\sub dir\program
>> name".
>>> | This string can be interpreted in a number of ways.
>>> | The system tries to interpret the possibilities in the following
order:
>>> | c:\program.exe files\sub dir\program name c:\program files\sub.exe 
>>> | dir\program name c:\program files\sub dir\program.exe name 
>>> | c:\program files\sub dir\program name.exe
>>>
>>>       Without this kludge this beginners error would get caught upon
>>>       the very first use of any of these command lines.
>>>
>>>
>>> Since every user account created during Windows setup has 
>>> administrative rights every user owning such an account can create 
>>> the rogue program, resulting in a privilege escalation.
>>>
>>> JFTR: no, the "user account control" is not a security boundary!
>>>
>>>
>>> regards
>>> Stefan Kanthak
>>>
>>>
>>> PS: for static detection of these silly beginners errors download and
>>>     run <http://home.arcor.de/skanthak/download/SLOPPY.CMD>
>>>
>>>     To catch all instances of this beginners error download
>>>     <http://home.arcor.de/skanthak/download/SENTINEL.CMD>,
>>>     <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and
>>>     <http://home.arcor.de/skanthak/download/SENTINEL.EXE>, then read
>>>     and run SENTINEL.CMD
>>>
>>> _______________________________________________
>>> Sent through the Full Disclosure mailing list 
>>> http://nmap.org/mailman/listinfo/fulldisclosure
>>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>>
>> _______________________________________________
>> Sent through the Full Disclosure mailing list 
>> http://nmap.org/mailman/listinfo/fulldisclosure
>> Web Archives & RSS: http://seclists.org/fulldisclosure/
>>
> _______________________________________________
> Sent through the Full Disclosure mailing list 
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/


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

Powered by blists - more mailing lists