| Summary: | FalseCONNECT: HTTPS MITM via Proxy Authentication headers | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Doran Moppert <dmoppert> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | chorn, cperry, danw, gecko-bugs-nobody, jhorak, kevin, mcatanzaro+wrong-account-do-not-cc, pjasicek, rob.townley, stransky, tcallawa |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
A flaw in the implementation of HTTP proxy authentication in WebKit made it possible for attackers on the local segment who can execute man-in-the-middle attacks between the browser and the proxy server to inject malicious Javascript that will be executed as though it came from an HTTPS site the user is visiting.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-30 00:31:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1348264 | ||
|
Description
Doran Moppert
2016-08-22 02:02:48 UTC
Hi, this is the first we (WebKitGTK+ upstream) have heard of the issue; it doesn't yet appear on any Apple security advisories and we haven't been contacted separately about it. Can you provide a link to details on the vulnerability? If there is a private bug report on bugzilla.webkit.org, please CC me on the bug. Reporter's site that should have been linked here. External References: http://falseconnect.com/ The implementation vulnerability reported here is fixed in CFNetwork (in Core Foundation), not in WebKit, so only Apple products are affected. However, I have not checked to ensure that our stack does not have the same implementation flaw. (Agree that from what I can see, this probably doesn't actually affect WebKitGTK.) I think these are references to the same vulnerability: https://www.kb.cert.org/vuls/id/905344 http://jvn.jp/vu/JVNVU90754453/index.html (Japanese) (In reply to Michael Catanzaro from comment #3) > The implementation vulnerability reported here is fixed in CFNetwork (in > Core Foundation), not in WebKit, so only Apple products are affected. > However, I have not checked to ensure that our stack does not have the same > implementation flaw. This appears to be correct: the report identified "WebKit" as the vulnerable component, but the vulnerable behaviour is not reproducible on any webkit browsers we have tested (eg midori, epiphany). The issue seems to be limited to Apple products. To summarise this issues impact for Red Hat customers: - FalseCONNECT was reported as a flaw in Apple WebKit products (browsers and other software which acts as HTTP client) which could be exploited by malicious proxy servers or man-in-the-middle attackers in front of the proxy server - No Red Hat products are known to be affected by this flaw. Specifically, Firefox and Chromium are unaffected; Midori and Epiphany are unaffected; webkitgtk/qtwebkit/kdewebkit do not exhibit the same flaw. Proxy servers were not vulnerable to FalseCONNECT: the vulnerability lay in browsers (and browser-like components) incorrectly handling malformed responses from the proxy server. As far as response/mitigation: - Apple released updates for their platforms prior to this issue going public (see http://www.falseconnect.com/ for details) - No non-Apple products are known to be affected - Affected systems that can not receive security updates from Apple *may* be able to be protected by disabling proxy support altogether, including automatic proxy discovery from the network OK great, thanks for testing it. (We could have made the same mistake!) |