SUMMARY not sure about component severity: grave for security/privacy/tracking problem STEPS TO REPRODUCE 1. view HTML mail with <style>@font-face { src: url(… 2. enable HTML for this mail, but not external refs OBSERVED RESULT * text shows up with delay * message "… For security/privacy reasons external references are not loaded. …" is shown * external requests are made for the font(s) EXPECTED RESULT * no external requests * system font used instead SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION The mail in question was from meetup.com, including user-specific links. If needed I can try to craft a more minimal example to provide it here.
Git commit f8557851f5e43f991aaeecd5bcbb9597d65b2005 by Laurent Montel. Committed on 03/02/2021 at 06:36. Pushed by mlaurent into branch 'release/20.12'. Fix Bug 431218 - mail viewer loads external fonts even with external refs disabled FIXED-IN: 5.16.3 M +2 -0 messageviewer/src/viewer/webengine/loadexternalreferencesurlinterceptor/loadexternalreferencesurlinterceptor.cpp https://invent.kde.org/pim/messagelib/commit/f8557851f5e43f991aaeecd5bcbb9597d65b2005
I created a patch but I can't be sure. Could you send me an test case for verifying it please ? thanks
I sent you a test case in private mail. When reading your patch and the surrounding code it looks like only some (images, now also fonts) request types are blacklisted. What about external style sheets or other types that might grow in HTML-land? Are there any external requests you think should be allowed? Regarding URL schemes: why is file:// allowed? I could think of some social engineering attacks that might work by including files from the victims computer. I would read "external request" as external to the e-mail in question. To me the function could be as simple as: ----8<----8<---- bool LoadExternalReferencesUrlInterceptor::interceptRequest(QWebEngineUrlRequestInfo &info) { if (mAllowLoadExternalReference) { return false; } const QString scheme = info.requestUrl().scheme(); if (scheme == QLatin1String("data") || scheme == QLatin1String("cid")) { return false; } return true; } ----8<----8<----
(In reply to Timo Weingärtner from comment #3) > I sent you a test case in private mail. Yep thanks. I will look at it. > When reading your patch and the surrounding code it looks like only some > (images, now also fonts) request types are blacklisted. What about external > style sheets or other types that might grow in HTML-land? Are there any > external requests you think should be allowed? see "BlockExternalResourcesUrlInterceptor" too but indeed I need to block "style sheets" too. > > Regarding URL schemes: why is file:// allowed? I could think of some social > engineering attacks that might work by including files from the victims > computer. I would read "external request" as external to the e-mail in > question. Because we use file:// for resources too (as loading html template/ local image etc.) => normal. > > To me the function could be as simple as: > > ----8<----8<---- > bool > LoadExternalReferencesUrlInterceptor:: > interceptRequest(QWebEngineUrlRequestInfo &info) > { > if (mAllowLoadExternalReference) { > return false; > } > > const QString scheme = info.requestUrl().scheme(); > if (scheme == QLatin1String("data") > || scheme == QLatin1String("cid")) { > return false; > } > > return true; > } nope :) as we want to be able to load image from loacl etc :) > ----8<----8<----
Why should an email be able to load images from my home directory? What is the use case for loading images from file:// ?
(In reply to Timo Weingärtner from comment #5) > Why should an email be able to load images from my home directory? > > What is the use case for loading images from file:// ? For example avatar support. We load html template too.