Ironically, SNARE has this very problem. Walt Williams sent from my iPhone Typos likely
> On Apr 30, 2014, at 17:51, Alton Blom <alton...@gmail.com> wrote: > > Hi Stefan, > > SANS had a good post on this a few years ago ( > https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464), > 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.kant...@nexgo.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/
