[okular] [Bug 416656] PDF Launch Action allows to execute Mono executables
https://bugs.kde.org/show_bug.cgi?id=416656 --- Comment #4 from Jens Mueller --- I'm using Kali. Okular (xdg-open) does not allow you to *launch* Linux executables. It does however allow you to *open* files with a default application (e.g., a text like /etc/passwd file is opened with the default text editor; fair enough). Now, if we install mono (a dependency of bless), windows executable files are xdg-opened (via Okular) with mono and thereby can cause harm on Linux. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416653] PDF Deflate bombs may cause crashes or resource exhaustion
https://bugs.kde.org/show_bug.cgi?id=416653 --- Comment #5 from Jens Mueller --- I opened an issue for Poppler: https://gitlab.freedesktop.org/poppler/poppler/issues/878 If it's handled there, things should be fine. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416656] New: PDF Launch Action allows to execute Mono executables
https://bugs.kde.org/show_bug.cgi?id=416656 Bug ID: 416656 Summary: PDF Launch Action allows to execute Mono executables Product: okular Version: 1.3.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- Created attachment 125340 --> https://bugs.kde.org/attachment.cgi?id=125340&action=edit PoC document to launch usr/lib/bless/bless.exe The PDF specification defines the "Launch Action", which allows documents to launch arbitrary applications. The file to be launched can either be specified by a local path, a URL or a file embedded within the PDF document itself. The standard does not provide any security considerations regarding this obviously dangerous feature. Therefore, it is fair to say that PDF offers "command execution by design" – if the standard is straightforwardly implemented. Okular uses xdg-open to handle the file to be launched, thereby delegating the security decision to a third-party application. On my Debian GNU/Linux test system, this results in code execution with minimal user interaction: by referencing an Windows .exe from a Link annotation, the executed with `/usr/bin/mono`, an emulator for .NET executables, if the user clicked somewhere into the document. **Steps to reproduce:** 1. `# apt-get install bless` 1. `$ okular launch-linux-mono.pdf` I'm not sure if this is a bug/misconfiguration in xdg-open. However, it is debatable if security-focused PDF viewers should support the Launch action at all. It is a dangerous feature mostly used to spread malware (primarily in the Windows world). We recently conducted a large-scale study of 294.586 PDF documents downloaded from the Internet, in order to research if there are any legitimate use cases at all. Only 532 files (0.18%) contained a Launch action. It can be concluded that the Launch action is rarely used in the wild and its support should is questionable in security-oriented PDF implementations. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416654] JavaScript in PDF documents can exhaust resources
https://bugs.kde.org/show_bug.cgi?id=416654 --- Comment #2 from Jens Mueller --- Created attachment 125336 --> https://bugs.kde.org/attachment.cgi?id=125336&action=edit Trivial PoC (02) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416654] JavaScript in PDF documents can exhaust resources
https://bugs.kde.org/show_bug.cgi?id=416654 --- Comment #1 from Jens Mueller --- Created attachment 125335 --> https://bugs.kde.org/attachment.cgi?id=125335&action=edit Trivial PoC (01) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416654] New: JavaScript in PDF documents can exhaust resources
https://bugs.kde.org/show_bug.cgi?id=416654 Bug ID: 416654 Summary: JavaScript in PDF documents can exhaust resources Product: okular Version: 1.3.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- A simple endless loop with JavaScript in a PDF document can cause resource exhaustion (cpu or mem). If JavaScript in PDF documents really needs to be supported, its resources should be limited (similar to browsers). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416653] PDF Deflate bombs may cause crashes or resource exhaustion
https://bugs.kde.org/show_bug.cgi?id=416653 --- Comment #2 from Jens Mueller --- Created attachment 125333 --> https://bugs.kde.org/attachment.cgi?id=125333&action=edit Trivial PDF deflate bomb (02) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416653] PDF Deflate bombs may cause crashes or resource exhaustion
https://bugs.kde.org/show_bug.cgi?id=416653 --- Comment #3 from Jens Mueller --- Created attachment 125334 --> https://bugs.kde.org/attachment.cgi?id=125334&action=edit Trivial PDF deflate bomb (03) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416653] PDF Deflate bombs may cause crashes or resource exhaustion
https://bugs.kde.org/show_bug.cgi?id=416653 --- Comment #1 from Jens Mueller --- Created attachment 125332 --> https://bugs.kde.org/attachment.cgi?id=125332&action=edit Trivial PDF deflate bomb (01) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 416653] New: PDF Deflate bombs may cause crashes or resource exhaustion
https://bugs.kde.org/show_bug.cgi?id=416653 Bug ID: 416653 Summary: PDF Deflate bombs may cause crashes or resource exhaustion Product: okular Version: 1.3.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- Streams in PDF files can be compressed, which may result in "deflate bombs" if not handled by the PDF processing application. Find attached three simple PDF compression bombs (10MB on disk to 10GB in memory). Note the compressed stream can be used multiple times in a single PDF document. The PDF files have been gzipped as a precaution mechanism, in order to prevent DoS when accidentally previewing them (gunzip them before the actual testing). Maybe resource limitations should be enforced by Okular / Poppler? -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #15 from Jens Mueller --- @David: This would mean if you attach a non-encrypted image to an encrypted... Absolutely, such an email could not be decrypted anymore if you follow our suggestions (or had to be manually decrypted on the command line). While this may seem a bit harsh, we have not seen any mail client that allows to send such "partially encrypted" emails (e.g., with unencrypted attachments), and I think handling such edge cases can become a security nightmare. Either the whole mail is encrypted or it's not, everything else gives a false sense of security, imho. However, I see the developer's perspective and the and the fear of potentially breaking things, too. I guess a rule like "in case of an encrypted, multipart email, reply only with the first part" *should* be fine too. @Sandro: We originally tested in version 5.2.3 on Debian 9.8 (stretch). This version is probably outdated by now. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 Jens Mueller changed: What|Removed |Added Version|5.10.3 |unspecified -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 404697] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404697 --- Comment #7 from Jens Mueller --- Update: Here's a full (public) report on the issue: https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf For Trojitá, CVE-2019-10734 was assigned for reply-based `decryption oracles`. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #10 from Jens Mueller --- Update: Here's a full (public) report on the issue: https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf For KMail, CVE-2019-10732 was assigned for reply-based `decryption oracles`. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #9 from Jens Mueller --- Imho, there are no legitimate use cases for `partial encryption` in S/MIME and PGP/MIME, but it's hard to measure if such emails do exist in the wild. In case of PGP/Inline, unfortunately, every part is encrypted separately. Note that a captured PGP/MIME message can be `downgraded` to be interpreted in the context of PGP/INLINE. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #7 from Jens Mueller --- Exactly that's the problem. Note that not only one message, but hundreds of captured messages can be wrapped and leaked with one single reply. Traditional message takeover attacks under a new identity (C) are considered as an acceptable risk in email e2e encryption because it is assumed that given the context of the message (e.g.,“Hi A, [...] Yours, B”) B can tell that this message is not originally from C and could easily discover the deception. However, using MIME wrapping, C can make a different content being displayed to B (if B does not carefully scroll down the whole message conversation) and therefore potentially trick B into replying to C. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #4 from Jens Mueller --- Things may have changed in the meantime, but for the version we tested (v5.2.3), there is no need to click on "Decrypt Message". While the plaintext is not shown to the user, if he does not explicitly click "Decrypt Message", the plaintext is still included in replies -- just re-tested for S/MIME and PGP/MIME. Note that KMail was tested in the default settings (the option "Attempt decryption of encrypted messages when viewing" was *not* set). -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #1 from Jens Mueller --- Created attachment 118288 --> https://bugs.kde.org/attachment.cgi?id=118288&action=edit Proof-of-concept PGP -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] New: Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 Bug ID: 404698 Summary: Decryption Oracle based on replying to PGP or S/MIME encrypted emails Product: kmail2 Version: unspecified Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: crypto Assignee: kdepim-b...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- In the scope of academic research in cooperation with Ruhr-Uni Bochum and FH Münster, Germany we discovered a security issue in KMail: An attacker who is in possession of PGP or S/MIME encrypted messages can embed them into a multipart message and re-send them to the intended receiver. When the message is read and decrypted by the receiver, the attacker's content is shown. If the victim replies, the plaintext is leaked to an attacker's email address. The root cause for these vulnerabilities lies in the way KMail (and many other mail clients) handle partially encrypted multipart messages. - *Leaking plaintext through reply/forward* - /Attacker model/: Attacker is in possession of PGP or S/MIME encrypted messages, which she may have obtained as passive man-in-the-middle or by actively hacking into the victim's mail server or gateway /Attacker's goal/: Leak the plaintext by wrapping the ciphertext part within a benign-looking MIME mail sent to and decrypted+replied to by the victim /Attack outline:/ If KMail receives a multipart email, as depicted below, it decrypt the ciphertext part(s), together with the attacker-controlled text (which may be prepended and/or appended). multipart/mixed |--- Attacker's part |--- [encrypted part to leak] +--- [Attacker's encrypted part] A benign-looking attacker's text may lure the victim into replying. Because the decrypted part is also quoted in the reply, the user unintentionally acts as a decryption oracle. To obfuscate the existence of the encrypted part(s), the attacker may add a lot of newlines or hide it within a long conversation history. A user replying to such a ‘mixed content’ conversation thereby leaks the plaintext of encrypted messages wrapped within attacker-controlled text. Please find attached a raw .eml file which depicts the issue. --- Countermeasures --- Do not decrypt emails unless the PGP or S/MIME encrypted part is the root node -- and therefore the only part -- in the MIME tree (exception: multipart/signed for encrypted-then-signed S/MIME messages). Another, potentially less secure, option would be to quote only the very first MIME part in replies. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 404698] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404698 --- Comment #2 from Jens Mueller --- Created attachment 118289 --> https://bugs.kde.org/attachment.cgi?id=118289&action=edit Proof-of-concept S/MIME -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 404697] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404697 --- Comment #2 from Jens Mueller --- Created attachment 118287 --> https://bugs.kde.org/attachment.cgi?id=118287&action=edit Proof-of-concept S/MIME Please find attached a raw .eml file which depicts the issue for S/MIME. -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 404697] New: Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404697 Bug ID: 404697 Summary: Decryption Oracle based on replying to PGP or S/MIME encrypted emails Product: trojita Version: 0.7 Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Cryptography Assignee: trojita-b...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- In the scope of academic research in cooperation with Ruhr-Uni Bochum and FH Münster, Germany we discovered a security issue in Trojitá: An attacker who is in possession of PGP or S/MIME encrypted messages can embed them into a multipart message and re-send them to the intended receiver. When the message is read and decrypted by the receiver, the attacker's content is shown. If the victim replies, the plaintext is leaked to an attacker's email address. The root cause for these vulnerabilities lies in the way Trojitá (and many other mail clients) handle partially encrypted multipart messages. - *Leaking plaintext through reply/forward* - /Attacker model/: Attacker is in possession of PGP or S/MIME encrypted messages, which she may have obtained as passive man-in-the-middle or by actively hacking into the victim's mail server or gateway /Attacker's goal/: Leak the plaintext by wrapping the ciphertext part within a benign-looking MIME mail sent to and decrypted+replied to by the victim /Attack outline:/ If Trojitá receives a multipart email, as depicted below, it decrypt the ciphertext part(s), together with the attacker-controlled text (which may be prepended and/or appended). multipart/mixed |--- Attacker's part |--- [encrypted part] +--- Attacker's part A benign-looking attacker's text may lure the victim into replying. Because the decrypted part is also quoted in the reply, the user unintentionally acts as a decryption oracle. To obfuscate the existence of the encrypted part(s), the attacker may add a lot of newlines or hide it within a long conversation history. A user replying to such a ‘mixed content’ conversation thereby leaks the plaintext of encrypted messages wrapped within attacker-controlled text. --- Countermeasures --- Do not decrypt emails unless the PGP or S/MIME encrypted part is the root node -- and therefore the only part -- in the MIME tree (exception: multipart/signed for encrypted-then-signed S/MIME messages). Another, potentially less secure, option would be to quote only the very first MIME part in replies. -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 404697] Decryption Oracle based on replying to PGP or S/MIME encrypted emails
https://bugs.kde.org/show_bug.cgi?id=404697 --- Comment #1 from Jens Mueller --- Created attachment 118286 --> https://bugs.kde.org/attachment.cgi?id=118286&action=edit Proof-of-concept PGP Please find attached a raw .eml file which depicts the issue for PGP. -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #9 from Jens Mueller --- Hi Jan, > You might see different results from what I see because > different servers parse garbage input in a different way. That's interesting, however I'd not rely on the config of the IMAP server for end-to-end security (which PGP is assumed to provide). > As a side note, I do not think that *that* would be a > security issue because e-mail headers are forgeable Absolutely, but a lot of users assume that PGP can exactly counter the problem of forgeable email headers using digital signatures (even though a binding between the From:/Sender: address and the email address in the matching PGP has never been defined in the OpenPGP standard). > Trojita always unconditionally shows both Sender and > From fields if they are present. Yes, but only the display name, not the actual email address. For me, the testcases look as shown in attachment 115532. > Do you see a security problem in here? Depends on your point of view. I would not say those issues are super-bad. However, if we really want to rely on PGP for critical tasks I'd say there is still room for improvement in the UI of mail clients. Assume you receive a signed email from you employer with testcase #2 which includes a task-to-be-done-immediately (e.g. "The President: >>launch missiles<<") -- you may be stressed and not look into the signature details and just do it... > What we could do is to always show the e-mail address > which was matched. Would that make sense from your > point of view? Yes, I think it's a good practice to explicitly show the email address of the matching key (if available) and therefore answer the signed-by-whom question (or at least deligate it back to the user). Greetings Jens -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #8 from Jens Mueller --- Created attachment 115532 --> https://bugs.kde.org/attachment.cgi?id=115532&action=edit Screenshots of testcases -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399055] Signature spoofing in PGP signed email (GUI layer)
https://bugs.kde.org/show_bug.cgi?id=399055 --- Comment #2 from Jens Mueller --- Hi Jan, I see the problem. You want to accept partly signed messages and require to display which part of the message was signed in the mail body. This is a hard problem of usable security. I have no good solution :/ -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #6 from Jens Mueller --- Hi Jan, Sry, uploaded the key to the keyservers. Greetings Jens -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399055] New: Signature spoofing in PGP signed email (GUI layer)
https://bugs.kde.org/show_bug.cgi?id=399055 Bug ID: 399055 Summary: Signature spoofing in PGP signed email (GUI layer) Product: trojita Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Cryptography Assignee: trojita-b...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- Dear Trojitá devs, In the scope of academic research we discovered a (minor) PGP signature validation issue in Trojitá based on how Trojitá presents the results of signature verification to the user. *** Prerequirements *** It is assumed that the attacker, Eve, can send an email to Bob which -- on the RFC822 layer -- looks like originating from Alice (using the *From:* header). Such email address spoofing should actually be prevented by digital signatures. The attacker's goal is to have a spoofed PGP signature being displayed by the mail client, so that Bob thinks there is cryptographic proof for Alice being the sender. The attack is successful if the fake signature is indistinguishable from a real signed message by Alice on the first level of the UI -- i.e. by just viewing the email without further investigating the signature details or performing a forensic analysis. *** Attack Description *** Trojitá displays the status of the signature within the mail content itself. However, this part of the UI is in control of the attacker. With modern HTML, CSS or inline images a graphic showing `valid signature', appearing like the real results of signature verification, can easily be forged. Note that this attack works for signed-only as well as for signed and encrypted messages because the HTML email content do display the fake signature can simply be encrypted using Bob's public key. *** Countermeasures *** The results of signature verification are not to be shown in attacker-controlled parts of the UI such as in the message content itself which may contain arbitrary graphics. -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #1 from Jens Mueller --- Created attachment 115221 --> https://bugs.kde.org/attachment.cgi?id=115221&action=edit Testcase 'from sender, others: signer' -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #4 from Jens Mueller --- Created attachment 115224 --> https://bugs.kde.org/attachment.cgi?id=115224&action=edit Testcase 'from1: sender, from2: signer' -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #2 from Jens Mueller --- Created attachment 115222 --> https://bugs.kde.org/attachment.cgi?id=115222&action=edit Testcase 'from sender, others: signer' -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 --- Comment #3 from Jens Mueller --- Created attachment 115223 --> https://bugs.kde.org/attachment.cgi?id=115223&action=edit Testcase 'from1: sender, from2: signer' -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 399050] New: Signature spoofing in PGP encrypted email (ID layer)
https://bugs.kde.org/show_bug.cgi?id=399050 Bug ID: 399050 Summary: Signature spoofing in PGP encrypted email (ID layer) Product: trojita Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Cryptography Assignee: trojita-b...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- Created attachment 115220 --> https://bugs.kde.org/attachment.cgi?id=115220&action=edit Testcase 'display name' Dear Trojitá Devs, In the scope of academic research we discovered a (minor) PGP signature validation issue in Trojitá based on how Trojitá matches a signed message to a sender's identity. *** Prerequirements *** This attack requires three parties: Alice, Bob and Eve. Bob trusts Alice and Eve. He has both public keys imported to be able to verify their PGP signed messages. The attacker -- Eve -- is successful if she can send an email signed by herself while Bob's mail client shows the email as signed by Alice on the first level of the UI -- i.e. by just viewing the email without further investigating the signature details or performing a forensic analysis. *** Attack Description *** When dealing with digital signatures, the question of *signed by whom* is an important one. If Bob's mail client simply displayed `valid signature' once a PGP signed message is received, Eve could sign her message and send it to Bob with Alice set as the sender. This is due to a lack of binding between the user ID derived from the PGP signature and the address given in the *From:* header. There are two options to handle this problem: First, a mail client can explicitly display the signer's identity somewhere in the UI and let the user compare it to the sender address. Secondly, a warning can be shown if the signer's identity (email address) does not equal the sender address as shown by the mail client. Trojitá choses the later option which is hard to implement in a secure way. *** Proof of Concept *** Please find attached various proof-of-concept emails which allows an attacker to gain a `valid signature' getting displayed by Trojitá even though the shown sender address does not equal the actual signer address. *** Countermeasures *** It can be considered as a good practice to explicitly show *signed-by-whom* directly in the UI when displaying a PGP signed message. A comparison to the *From:* or *Sender:* header fields may not be sufficient because this approach is error prone. Feel free to contact me for any questions. Greetings, Jens Mueller -- M.Sc. Jens Mueller Research Assistant Chair for Network and Data Security, Ruhr-University Universitaetsstr. 150 Building ID 2/415 D-44780 Bochum Phone: +49 (0) 234 / 32-29177 -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 390452] HTML Backchannel in Trojitá Mail Client: DNS Prefetching
https://bugs.kde.org/show_bug.cgi?id=390452 --- Comment #2 from Jens Mueller --- For the tests we used Debian GNU/Linux 9.3 with the libqt5webkit5:amd64 (version 5.7.1+dfsg-1) package installed. Note easy prefetching of http://tracking-id.attacker.com"; rel="prefetch"> But prefetching can be re-enabled either in the HTTP header (which is hard for email) or in the HTML content itself by the spammer: -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 390452] New: HTML Backchannel in Trojitá Mail Client: DNS Prefetching
https://bugs.kde.org/show_bug.cgi?id=390452 Bug ID: 390452 Summary: HTML Backchannel in Trojitá Mail Client: DNS Prefetching Product: trojita Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Core Assignee: trojita-b...@kde.org Reporter: jens.a.mueller+...@rub.de Target Milestone: --- Created attachment 110652 --> https://bugs.kde.org/attachment.cgi?id=110652&action=edit HTML Backchannel in Trojitá Mail Client: DNS Prefetching Dear Trojitá Devs, In the scope of academic research within the efail project, in cooperation with Ruhr-University Bochum and FH Münster, Germany we systematically analyzed Trojitá for `web bugs' and other backchannels which have an impact on the user's privacy. The results are as follows. *** Introduction *** It is well known that spammers abuse `web bugs' -- 1x1 pixel images in HTML emails -- to track if their mails to a certain address are actually read. To respect the privacy of their customers most email clients, by default, block external content. However, we found a bypass for remote content blocking in Trojitá. *** The Impact *** The issue allows the sender of an email to leak information such as: - if and when the mail has been read - the number of users on a mailing list *** The Bypass *** The following HTML email triggers a DNS request to the DNS server responsible for tracking-id.attacker.com when the email is opened in Trojitá (without any user interaction required): http://tracking-id.attacker.com";> Note that it is easy to set up a DNS server controlled by the spammer responsible for her own domain, attacker.com, and all its subdomains. Greetings, Jens -- You are receiving this mail because: You are watching all bug changes.
