- Google is not hosting ChromeSetup.bat. A requirement for this attack is that a website needs to have an endpoint with a less common Content-Type and preferably a misconfigured Content-Disposition header (namely: no 'filename' attribute). These two headers will cause the browser to download the response as a file, instead of rendering it.
In the URL you provide that endpoint is '/s' which provides autocomplete suggestions as JSON, with a content type of application/json. Older versions of IE will prompt a download just based on the content type, newer versions and Chrome require that incomplete content-disposition header for this attack to work.
Another requirement is that this endpoint must reflect some user input from the querystring ( post or cookie data will obviously work aswell but wouldn't be as effective for the attacker). This will provide the malicious content of the file that is downloaded.
In the URL you provided this will be the value of the querystring parameter.
As no filename is provided for the download, the browsers tries to pick one. Because the Google website allowed loose urls through url parameters (the ;/ChromeSetup.bat; part), the browser picked a cleaned up version of that (namely ChromeSetup.bat) as the filename to present to the user. The webapplication ignores this input, but the browser does use it.
- Any browser on any OS might respond in this way. Chrome will download the response with the forged filename, that will also work on OSX.
An additional weakness exists in Windows that doesn't warn the user properly when "setup" occurs in the filename. Windows will also directly run a .bat file if you click it. Osx and Linux won't run this file as the attacker would most likely be unable to provide a full shellscript with the hashbang notation. Even then, it doesn't have the executable bit set, so it wouldn't be run directly.
- The user still has to activate/accept the download, so just driving by with an won't cause immediate "infection". A client (browser) should provide proper warnings for executable files instead of just running them. The user should know better than to run random .bat files, but that's the strength of this attack: the "file" is served from Google.com, so it should be safe right? The most important party here is the vulnerable website: the website shouldn't allow a user to provide a custom path, should provide proper headers to prevent this and should reconsider reflecting user input.