Issue metadata
Sign in to add a comment
|
Security: kCanarySRTDownloadURL and kMainSRTDownloadURL are should be HTTPS
Reported by
jackwill...@gmail.com,
Apr 14 2016
|
||||||||||||||||||||||||
Issue description
kCanarySRTDownloadURL and kMainSRTDownloadURL are should be HTTPS
// The download links of the Software Removal Tool.
const char kMainSRTDownloadURL[] =
"http://dl.google.com/dl"
"/softwareremovaltool/win/chrome_cleanup_tool.exe?chrome-prompt=1";
const char kCanarySRTDownloadURL[] =
"http://dl.google.com/dl"
"/softwareremovaltool/win/c/chrome_cleanup_tool.exe?chrome-prompt=1";
from:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/safe_browsing/srt_field_trial_win.cc
,
Apr 14 2016
This may be on purpose — it may be that the EXEs are signed with Authenticode, and that we most care about availability of the SRT moreso than confidentiality in downloading it. (Since authentication would be covered by the Authenticode signature, at least in principle.) + Protector folks and Windows folks
,
Apr 18 2016
,
Apr 18 2016
Windows doesn't by default do Authenticode checks on binaries, it will only do them if the file has the "mark of the web" and is launched from the shell, or enterprise group policy is enforcing authenticode. I couldn't find any integrity checks in the SRT fetcher code. mad@ can you confirm behavior here?
,
Apr 19 2016
Setting severity and impact as though this is an unintended issue.
,
Apr 19 2016
,
Apr 19 2016
Can you please Cc Khalil Zhani "chromium.khalil@gmail.com" he is my partner in this bug.
,
Apr 19 2016
,
Apr 20 2016
I was under the impression that dl.google.com would always fallback to https, but I could write a quick patch to use https directly and avoid the confusion.
,
Apr 20 2016
mad@ - Unfortunately, that presumes that the client will ever actually be able to connect to dl.google.com. The problem here is that a MitM will prevent that from happening, and instead just return a malware binary without the user ever knowing the difference.
,
Apr 20 2016
,
Apr 21 2016
I thought the fact that dl.google.com is on the HSTS preload list would make this always be HTTPS from the start, no?
,
Apr 21 2016
Apparently it is, which is great (and justifies lowering the severity): https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json&l=263 However, the MitM can still block the connection, in which case the user might try to download via another browser (where our hard-coded HSTS list is not present). And in that case, the initial connection would be over a vulnerable transport, which the MitM could exploit to serve a malware payload. To the larger point, HSTS is intended as a safety net, and not as a substitute for using HTTPS URLs. So, best practice is to use HTTPS everywhere as the default.
,
Apr 21 2016
OK, good point. The fix has landed yesterday, so could be merged up tomorrow.
,
Apr 26 2016
So is this worth merging to stable branch? A merge has been done to beta branch yesterday...
,
Jul 28 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tsepez@chromium.org
, Apr 14 2016Status: Assigned (was: Unconfirmed)