Bugzilla – Bug 1227486
VUL-0: kmozillahelper: helper might circumvent Firefox security settings
Last modified: 2024-07-14 10:43:11 UTC
kmozillahelper seems to look up hosts on its own. I noticed this when clicking URLs where often they won't even reach firefox because kmozillahelper already looked them up. I think this is in some environments a significant security problem, since the user expectation is 1. the URL will be handled by their browser and nothing else, 2. firefox supports DNS over TLS so the user may expect their ISP doesn't see what URLs they're clicking, 3. unless kmozillahelper perfectly replicates firefox's entire network stack including reading its settings, that means it may be effectively bypassing all these security settings without user consent and leaking the URLs to the ISP and other parties without a warning. My apologies if I just missed something, but if these observations are correct then I think kmozillahelper as it conceptually seems to work right now is a security hole. It shouldn't touch the internet whatsoever about the URLs, and just hand them off to firefox.
This seems to be an openSUSE specific tool. Assigning to the package maintainer, who also has worked on this most of the time upstream. First of all this project is missing any proper documentation what it is actually supposed to do and in what context it will run. Therefore I cannot fully judge currently if the expressed concerns are valid.
kmozillahelper provides dialogs for open+save file selection and some other miscellaneous integration. It is legacy and meant to be dropped as soon as possible, it's just waiting for Firefox: https://bugzilla.suse.com/show_bug.cgi?id=1226112 > I noticed this when clicking URLs where often they won't even reach firefox because kmozillahelper already looked them up. I cannot follow there - kmozillahelper does nothing on its own, it's started and managed by firefox and only does whatever FF tells it to. I'm not aware of any command that causes kmozillahelper to receive an URL and "look it up".
> I'm not aware of any command that causes kmozillahelper to receive an URL and "look it up". That happens when I click e.g. an URL mail in Thunderbird. Instead of opening a tab in firefox, where the URL is then resolved using DNS over TLS inside firefox, it seems to be resolved by kmozillahelper which I'm worried isn't using DNS over TLS and then instead prompts some desktop notification that the host can't be found with the tab never being opened. Is this sort of handling a firefox bug then?
I still can't explain the behaviour you're observing. > That happens when I click e.g. an URL mail in Thunderbird. Can you clarify what you mean by "URL mail"? Do you mean clicking a link in a mail that should open in firefox? In that case kmozillahelper should only check which application to open the URL with but let TB handle the actual open action.
Created attachment 875942 [details] video showing how kmozillahelper shows error before URL reaches firefox My apologies for being unclear, I attached a video that shows what I'm seeing. The URL never seems to reach Firefox in this case, and it doesn't look like Firefox is handling the DNS resolution safely as intended.
Ok, so it's probably the "OPEN" handler. Does the same behavior occur if you use xdg-open with that URL?
Created attachment 875944 [details] Video showing xdg-open on the same URL copied from Thunderbird
It seems like xdg-open does the right thing, and instead of resolving it outside of Firefox simply passes it on directly. I'm using a KDE Wayland session, and Firefox's "about:support" shows "Window Protocol" as "Wayland", but I'm not sure if Thunderbird might be using XWayland still. I'm using the Firefox Developer Edition build directly from Mozilla, and the Thunderbird 115.12.0 build from openSUSE Slowroll.
I can't reproduce the issue locally, it's passed straight to the browser. Please try kioclient exec https://bugzilla.suse.com/show_bug.cgi?id=1227486 echo -e "OPEN\nhttps://bugzilla.suse.com/show_bug.cgi?id=1227486\n\\\E\n" | QT_LOGGING_RULES=*.debug=true /usr/lib/mozilla/kmozillahelper
It works fine when using kioclient exec, it opens up a tab in firefox that fails to open the page (rather than some message box at an earlier point). This is the output after repeating these two commands multiple times: $ kioclient exec https://bugzilla.suse.com/show_bug.cgi?id=1227486 $ echo -e "OPEN\nhttps://bugzilla.suse.com/show_bug.cgi?id=1227486\n\\\E\n" | QT_LOGGING_RULES=*.debug=true /usr/lib/mozilla/kmozillahelper qt.xkb.compose: using xkb compose input context qt.qpa.wayland: using input method: QComposeInputContext kf.iconthemes: Icon theme "" not found. qt.qpa.wayland: using input method: QtWaylandClient::QWaylandInputContext qt.qpa.wayland: Available client buffer integrations: ("wayland-egl", "xcomposite-egl", "xcomposite-glx") qt.qpa.wayland: Using Wayland-EGL qt.qpa.wayland: Initializing client buffer integration "wayland-egl" kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Mozilla Firefox" msgid_plural: "" msgctxt: "" \1 Unknown command for KDE helper: \0 kf.coreaddons: Checking for plugins in ("/usr/lib/mozilla/kf5/kio", "/usr/lib64/qt5/plugins/kf5/kio") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/activities.so" supports protocols ("activities") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/afc.so" supports protocols ("afc") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/archive.so" supports protocols ("ar", "sevenz", "tar", "zip") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/baloosearch.so" supports protocols ("baloosearch") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/filter.so" supports protocols ("bzip", "bzip2", "gzip", "lzma", "xz", "zstd") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/fish.so" supports protocols ("fish") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/info.so" supports protocols ("info") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_file.so" supports protocols ("file") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_filenamesearch.so" supports protocols ("filenamesearch") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_ftp.so" supports protocols ("ftp") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_ghelp.so" supports protocols ("ghelp") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_help.so" supports protocols ("help") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_http.so" supports protocols ("http", "https", "webdav", "webdavs") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_iso.so" supports protocols ("iso") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_remote.so" supports protocols ("remote") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kio_trash.so" supports protocols ("trash") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/man.so" supports protocols ("man") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/metainfo.so" supports protocols ("metainfo") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/mtp.so" supports protocols ("mtp") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/recentdocuments.so" supports protocols ("recentdocuments") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/recentlyused.so" supports protocols ("recentlyused") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/sftp.so" supports protocols ("sftp") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/smb.so" supports protocols ("cifs", "smb") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/tags.so" supports protocols ("tags") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/thumbnail.so" supports protocols ("thumbnail") kf.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/timeline.so" supports protocols ("timeline") kf.service.sycoca: Opening ksycoca from "/home/ellie/.cache/ksycoca5_en_MdJ1QYHyMvTZ2mu2C07RdmFmjx8=" kf.kio.core: killing worker process pid 31108 ( "https://bugzilla.suse.com" ) A KUiServerV2JobTracker instance contains 1 stalled jobs
I just noticed the error message shows "Mozilla Thunderbird", this can be seen in the video I attached as well. Is it possible that this is supposed to be some misguided Thunderbird feature instead, where it looks up links before just opening them in the browser? That would explain why you can't see anything in kmozillahelper. Previous notifications seemed to suggest to me like kmozillahelper was involved in this error, since there are definitely notifications popping up with that name as well, but maybe I just mixed it up in regards to this pre-lookup problem. Sorry if that was the reason for this entire confusion.
Did the manual kmozillahelper invocation trigger the error as well? (In reply to ell1e from comment #11) > I just noticed the error message shows "Mozilla Thunderbird", this can be > seen in the video I attached as well. That's normal, kmozillahelper tries to fit in there and calls itself either Mozilla Firefox or Mozilla Thunderbird. > Is it possible that this is supposed to be some misguided Thunderbird > feature instead, where it looks up links before just opening them in the > browser? Theoretically possible, but the error message is definitely from KIO.
Let me know what else to try if there's anything, I'd be happy to help investigate more if that is feasible.
I'd like to know: (In reply to Fabian Vogt from comment #12) > Did the manual kmozillahelper invocation trigger the error as well? and also the output of xdg-mime query default x-scheme-handler/http xdg-mime query default x-scheme-handler/https kreadconfig6 --group General --key BrowserApplication
"kioclient exec https://bugzilla.suse.com/show_bug.cgi?id=1227486" doesn't trigger the error. If I should try something different to invoke it directly, let me know! xdg-open doesn't either, so far it seems to be limited to clicking links in Thunderbird. Here are the requested settings: $ xdg-mime query default x-scheme-handler/http userapp-Firefox Developer Edition-YJDMA0.desktop $ xdg-mime query default x-scheme-handler/https userapp-Firefox Developer Edition-YJDMA0.desktop $ kreadconfig6 --group General --key BrowserApplication firefox I'm using the Mozilla Developer Edition as my default browser, not the firefox version by openSUSE, if that explains some of the output.
I'm mostly out of ideas. The only way this can happen AFAICT is if KIO thinks there is no browser available so it tries to download the file from that URL to figure out which application to use. The xdg-mime and kreadconfig6 calls show that the browser is correctly configured though. At this point I'd treat this more like a normal bug report than a security issue, but I still can't tell for sure whether this is a bug just on your system or whether it may happen generally. Some more invasive debugging might be needed. You could attach to the running kmozillahelper used by TB and set a breakpoint on "KIO::get". If that triggers, the backtrace might be helpful