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

• Component: Security
• Status: NEW

[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.

[Orsespach]

Thanks for sharing such helpful instructions, really appreciate your help.

[Orsespach]

Thanks for sharing such helpful instructions, really appreciate your help.
https://ncedcloud.cyou/