Bug 259787 – [WPE][GTK] Certain connections to remote sites cannot be intercepted using WebPage::send-request signal

• Status: NEW
• Component: Security

[Albrecht Dreß]

Created attachment 467194 [details]
sample application and HTML test input to reproduce the issue

OS version: Debian Bookworm/x86_64
Webkit GTK package: libwebkit2gtk-4.1 v. 2.40.3-2~deb12u2

Overview:
=========
Even if the request to access a remote site is intercepted in the WebPage::send-request signal handler, a socket connection is opened and –if applicable– the TLS handshake is performed.  If the access is triggered e.g. by malicious HTML content in an e-mail, this will already give the attacker valuable information, so this might (should?) be considered a security bug.

Steps to Reproduce:
===================
See the attached sample code package "sample.tar.gz" (note: tested on Debian Bookworm, should work similarly on other Linux systems):

(1) Unpack the sample
Unpack the package, cd into the folder “sample”, and say “make”

(2) Log network traffic
In an other terminal, start “tcpdump” or a similar tool to listen on ports 80/tcp and 443/tcp, e.g.:

  sudo tcpdump -vvv -K -X \( tcp port 80 or tcp port 443 \)

(3) Run test application
In “sample” run the application to display the included HTML file:

  ./samp-main Test.html

The application prints (time stamps omitted)

--8<-------------------------
webkit_web_extension_initialize: done!
web_page_created_cb: page 10 created for (null)
send_request_cb: uri 'http://ftp.de.debian.org/debian/doc/00-INDEX' caught, redirect to 'about:blank', stop event emission
--8<-------------------------

The HTML contains two “link” containers (preconnect, stylesheet) triggering this event without any further user interaction.  The tcpdump log shows a connect() to the remote site.

(4) Click link
Click on the link in the window.  The application prints

--8<-------------------------
send_request_cb: uri 'https://www.posteo.de/' caught, redirect to 'about:blank', stop event emission
--8<-------------------------

The tcpdump log shows that the connection opened in step (3) is closed, a new connect() to www.posteo.de is opened, and the full (!) TLS handshake is performed.

The sample package contains the tcpdump log in the file tcpdump.log:
* start the test application at 19:06:59
* click the link at 19:07:39

Expected Results:
=================
No connection to the remote site must be opened, and in particular no TLS handshake must occur if the WebPage::send-request signal handler redirects the request to a different location.

Speculation: the connection is established before the WebPage::send-request is emitted, resulting in this behavior.

[Michael Catanzaro]

There is a corresponding Evolution issue report: https://gitlab.gnome.org/GNOME/evolution/-/issues/2727

But I think this bug report contains everything we need to know. send-request is indeed supposed to be emitted, allowing the application to stop the TCP connection before it happens. Evidently something is wrong.

[Michael Catanzaro]

Your test cases uses rel="preconnect" and rel="stylesheet". There are a bunch of other cases that we should test as well:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel

dns-prefetch, icon, modulepreload, pingback, prefetch, preload, prerender

Hopefully these will all be fixable in one place and not require separate fixes.

[Albrecht Dreß]

Hi, great that someone takes care of this rather old bug!

> Your test cases uses rel="preconnect" and rel="stylesheet". There are a bunch of other cases that we should test as well:
I know – my example basically should only demonstrate that an attacker could exploit the bug both without and with any user interaction. There are of course plenty of other options for him to “use” it…

[beanbo]

I already reported this issue as a security issue of Webkit and got no response...

[Michael Catanzaro]

*** Bug 287218 has been marked as a duplicate of this bug. ***

[Radar WebKit Bug Importer]

<rdar://problem/155518218>

Comment on attachment 467194 [details]
sample application and HTML test input to reproduce the issue

[e-mail]

9ok

[Michael Catanzaro]

rel="dns-prefetch" might be tricky, because that is not an HTTP request, so we *can't* emit send-request. In https://gitlab.gnome.org/GNOME/evolution/-/issues/3095 I indicated that we do not need to bring back the enable-dns-prefetching setting, but I think this is wrong. We will need to undeprecate it and implement it. (Currently, there is no way to control it.)

Moreover, in https://gitlab.gnome.org/GNOME/balsa/-/issues/99 and https://gitlab.gnome.org/GNOME/geary/-/issues/1680, Mike discovered that rel="preconnect" only creates a TLS connection, not an HTTP request. So again, relying on send-request won't be sufficient. We'll need yet another setting to control this.

Everything else looks like an HTTP request, and we need to make sure they are all blockable via WebKitWebPage::send-request.

So that's a lot of stuff that needs to be fixed. I think it's fair to say this bug should only be closed if all of the above is resolved.

[Albrecht Dreß]

[sorry for the late reply/comment, I've been on vacation, away from my computer…]

(In reply to Michael Catanzaro from comment #9)
> rel="dns-prefetch" might be tricky, because that is not an HTTP request, so we *can't* emit send-request. In https://gitlab.gnome.org/GNOME/evolution/-/issues/3095 I indicated that we do not need to bring back the enable-dns-prefetching setting, but I think this is wrong. We will need to undeprecate it and implement it. (Currently, there is no way to control it.)

IMHO, the DNS query is *not* a privacy (or even a security) issue, as the application will ask the system's configured DNS server (ideally one from https://www.joindns4.eu/ or similar) for the IP address of the potentially malicious site, but *not* connect the site itself.  Please correct me if you are aware of any criminal or APT actor who actually could nevertheless abuse such lookups.  A wrong DNS configuration (i.e. contacting a DNS server which logs requests and shares the data with a secret service or criminals) is a general problem and beyond the scope of Webkit.  IOW, I don't see a valid reason for blocking these requests.

> Moreover, in https://gitlab.gnome.org/GNOME/balsa/-/issues/99 and https://gitlab.gnome.org/GNOME/geary/-/issues/1680, Mike discovered that rel="preconnect" only creates a TLS connection, not an HTTP request. So again, relying on send-request won't be sufficient. We'll need yet another setting to control this.

Well, this is exactly what happens in my initial example…

IMHO, the key for a solution is to catch the connect() system call for SOCK_STREAM sockets.

Just my € 0.01, though…

[Michael Catanzaro]

> Well, this is exactly what happens in my initial example…
> 
> IMHO, the key for a solution is to catch the connect() system call for
> SOCK_STREAM sockets.

But we have no way for applications to do this.

I think we just need a new setting to completely disable preconnect.

[Real]

Can you please increase the priority and severity of this bug? It is unacceptable that this has been languishing for so long, considering that this is known to affect privacy (and also reported elsewhere and discussed on other SM threads), .

[Michael Catanzaro]

(Sure, but I highly doubt anybody actually looks at the Priority or Severity fields on Bugzilla to decide what to work on....)

[Real]

So like this is gonna stay unfixed for the foreseeable future? The bug was reported 2+ years ago.

I want a clear answer since I'm responsible for IT security policies in my org and many people probably use programs depending on it. If this isn't gonna get fixed, I would like to mark all programs using this as exploited in the company's IT policy.

I don't have the know-how to produce a patch for fixing this so I can't contribute code, and I can't just sit waiting for nobody.

[Real]

(If this has been determined to not be a security issue then please correct me)

[Michael Catanzaro]

This is an open source project. Issues don't fix themselves. Somebody has to volunteer to work on it. If nobody cares enough to work on it, then it will never be fixed.

[Michael Catanzaro]

This is definitely a security bug.

[Albrecht Dreß]

Yes, it is a security bug, and it should be fixed.

However, IMHO its impact is somewhat limited.  As I pointed out in my initial report, an attacker can gain some information about the targeted system, basically (due to the connect() system call) that it exists. As worst case a TLS handshake is performed before the WebPage::send-request callback kicks in, blocking all further transactions.

Whilst this might of course be used for information harvesting (no idea if any attackers actually use this particular technique, though), this bug does not leak any other information, nor is it possible to inject malicious code. I.e. IMHO the confidentiality impact is rather low, integrity and availability of the target system are not affected.

I have no idea how to correctly calculate a CVSS, but maybe it would be helpful to create a CVE entry for this bug with a proper score as to avoid confusion about its criticality.

[Real]

Hmm... something like this?

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

Score 5.3

Used https://www.metaeffekt.com/security/cvss/calculator/