Created attachment 453599 [details] Test kit for Epiphany "cross-certificate scripting" Description of problem: Epiphany is willing to connect to an SSL server regardless of the certificate, though it only shows the unbroken lock if the main HTML page was received under a good certificate. Whether this kind of policy is advisable at all is controversial in the Fedora community (see https://lists.fedoraproject.org/pipermail/devel/2010-April/135269.html). But apart from that, the Epiphany implementation suffers from behaviors I think we can objectively consider to be security holes. Here's one. In my testing, after Epiphany connects to a server and downloads an HTML page with multiple embedded items, it opens one or more additional connections to the server and downloads the embedded items in parallel across all the connections. But the lock icon is only based on the connection over which the HTML page was received. A MITM attacker can intercept the other connections and respond with malicious data, and the unbroken lock remains visible. Version-Release number of selected component (if applicable): epiphany-2.30.2-1.fc13.x86_64 How reproducible: Always in my testing. Steps to Reproduce: 1. Download and extract the attached test kit. 2. Set "127.0.0.1 mattmccutchen.net" in /etc/hosts . 3. Run ./frontend (as root to bind to port 443) and ./self-signed-backend in separate terminals. 4. Start Epiphany and go to https://mattmccutchen.net/private/security-tests/include-script.html . This test page embeds an image and an external script. Epiphany will make one connection to request the page, which the kit proxies to my real web site, and a second connection to request the script, to which the kit responds with a self-signed certificate and "alert('xss')". The legitimate script on my web site does not contain such an alert. Actual results: A dialog box saying "xss" appears, while the lock icon remains unbroken. Expected results: No dialog box.
Page with <img> on some https site with untrusted certificate should be sufficient for testing. Problem affects other webkitgtk browsers too.
AIUI, bug 636933 / CVE-2010-3312 is specifically about Epiphany's failure to check certificates against a CA file at all. This issue should be a separate CVE. (In reply to comment #1) > Page with <img> on some https site with untrusted certificate should be > sufficient for testing. Yes, that's probably enough. I was trying to come up with a case that was as blatantly and uncontroversially wrong as possible. > Problem affects other webkitgtk browsers too. Not exactly. What determines the problem is using libsoup and setting the "ssl-strict" option to FALSE. I got a rough list of the libsoup-based browsers in Fedora by running "repoquery -i --whatrequires libsoup" and searching the descriptions case-insensitively for "brows". I found Epiphany, Kazehakase, Midori, surf, and Uzbl. It happens that all of these use webkitgtk. Epiphany and Midori set "ssl-strict" = FALSE and are affected (I filed bug 643229 for Midori). Kazehakase, surf, and Uzbl don't, but they take libsoup's insecure default of no CA file, which means all certificates are accepted (bug 569677). However, if my libsoup patch is used and a CA file is specified via environment variable, these three browsers function securely.
Which libsoup patch? If you set 'ssl-strict' true in midori it means you can't load any self signed cert sites at all. Not sure if thats also the case with epiphany.
(In reply to comment #3) > Which libsoup patch? https://bugzilla.gnome.org/attachment.cgi?id=124547&action=edit > If you set 'ssl-strict' true in midori it means you can't load any self signed > cert sites at all. > Not sure if thats also the case with epiphany. Right, but at least you can talk securely to sites with good certificates. The alternative is to make all sites insecure, which from my perspective is totally useless. A self-signed cert can be added to the CA file and it will be accepted, though adding a cert with the basic constraint "CA: true" (like "openssl req -new -x509" generates by default) may be a bad idea. However, Epiphany and Midori are hard-wired to use /etc/pki/tls/certs/ca-bundle.crt, so unless the user is willing and able to modify that file, she has to patch Epiphany/Midori or resort to some ridiculous LD_PRELOAD hack. Unfortunately, writing a secure and usable SSL client is not a trivial task. I think the best solution would be to adopt Mozilla PSM, as I wrote at https://fedoraproject.org/wiki/FedoraCryptoConsolidation .
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
epiphany-2.30.6-1.fc14 webkitgtk-1.3.10-1.fc14
Peter works on epiphany now.
Can you clarify what nextrelease means and how this is being addressed? TY!