Open Bug 1508030 Opened 6 years ago Updated 5 months ago

Thunderbird accidentally triggers DOS attacks: click links in mails without standard browser configured, starts sending requests more than 10 times per second

Categories

(Thunderbird :: Message Reader UI, defect)

defect

Tracking

(Not tracked)

People

(Reporter: public, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-dos, sec-low)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36 Steps to reproduce: Preconditions: OS: Debian Stretch (Debian GNU/Linux 9) Thunderbird Version: Thunderbird 60.3.0 (64-bit) IMPORTANT: No standard browser configured neither on OS nor within Thunderbird These where my steps to a reliable replication: 1) I sent a mail to myself containing a link to my own server (so that I could monitor incoming requests on my server) 2) within Thunderbird I clicked this link Actual results: thunderbird immediately started sending GET requests with a frequency of > 10 per second: (access.log on my server shows these incoming requests) After closing Thunderbird, a background (zombie?) process kept sending requests, now with a reduced frequency of about 1 per second. I was not able to kill this process and had to shut down my OS. Expected results: thunderbird must NOT start sending requests on OS without standard browser configured at least: after closing thunderbird, sending requests should end within a reasonable time (10-30 seconds or so?)
Additional Info: the entry x-www-browser in /etc/alternatives points to a not existing directory
Second additional Info: even if I point the x-www-browser in /etc/alternatives to an existing browser (i.e. firefox), the behavior keeps unchanged. The Browser will open but some background process keeps sending requests as described above.
Third additional Info: after correctly configuring x-www-browser in /etc/alternatives AND OS restart, thunderbird behaves as expected: in-mail-links are opened with the configured browser.
> 2) within Thunderbird I clicked this link What link? following the above are several blank lines. Or does it matter -- any link?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(public)
Since an attacker can't force you to have an undefined browser this doesn't need to be hidden.
Group: mail-core-security
1) It doe's not matter what link. Any link is possible 2) The attacker does not have to force me setting up by OS in this way. It is sufficient, that he set's up an OS by his own, sends a link to the website he wants to attack and click the link by himself. Is is that easy.
Flags: needinfo?(public)
I mean sends the link to an own account and opens this link from within thunderbir. He does not need to force anyone else to do this.
By the way: Libre Office has the same vulnerabilty.

Looking at old bugs. Magnus, Kai, any need for action here?

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(kaie)

Maybe same as bug 1134635? Benjamin, can you check this case too

Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(kaie)
Flags: needinfo?(benjamin)

Very similar. I'll test this against the fix for bug 1134635 and see if it catches both of them.

My initial tests have not been successful in recreating this issue.

Here is what I've tried so far.

  • removed x-www-browser completely: xdg-settings overrides this so browser still opens
  • purposely changed the .desktop file that xdg-settings is pointing: System goes to the next available browser (I have 4 installed)
  • changed all the .desktop files that relate to browsing: No zombie process or out of control GET requests.

This may still be an issue on some systems and possibly older distributions; However, either because of the bug 1124835 patch or because the system has fail safes in place to combat this issue I was unable to reproduce the issue.

I haven't yet attempted to reproduce the issue using non-patched versions.

Flags: needinfo?(benjamin)
Severity: normal → S3
Blocks: 1898134
You need to log in before you can comment on or make changes to this bug.