Opened 6 years ago

Last modified 8 months ago

#12089 new defect

BridgedDB can be forced to email arbitrary email addresses

Reported by: isis Owned by:
Priority: High Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Normal Keywords: bridgedb-email, security, ex-sponsor-19
Cc: isis, sysrqb Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor30-can


See #12086.

From this commit message for this unittest:

BridgeDB will accept an email from an arbitrary gmail/yahoo email address at the SMTP layer, and then send the reply to a *different* arbitrary gmail/yahoo email address taken from the contents of the email headers.

As you can see in the example...

(in the ticket description of #12086)

the SMTP command


combined with a 'From:' in the email headers within the SMTP DATA segment caused the reply to be sent the reply to the later, when it came from the former.

While this was done quick-and-dirty with netcat, it's probably possible to configure msmtp to send a the same SMTP commands/info with embedded email headers still specifying an arbitrary email address, such that Gmail/Yahoo would produce a valid DKIM signature for it and pass it along to BridgeDB. (And thus the issue isn't merely that DKIM verification appears to be broken, but the issue is that we're not checking that source of an incoming email matches the destination of the response.)

In addition, the person reading such a unsolicited response from BridgeDB also has no way to know who originally emailed BridgeDB to cause this email to end up in her inbox in the first place.

I'm not exactly certain if this is a bug or a feature. While it could be used for sending some junk to an arbitrary gmail/yahoo address, it could also be used as a sort of

"Dear BridgeDB, can I have some bridges? Asking for a friend."


I'm guessing that we're likely to see more use of it for the former, more malicious activity than the latter benevolent one, and so we should probably consider this a pretty serious bug.

Side note:

All the bugs found with that unittest were present in older versions of BridgeDB, and possibly have always been present, and they don't appear to be resultant from my recent rewrite of the email servers (as sysrqb noted, my rewrite retained portions of the old codebase). I just wanted to point that out so that I'm not blamed for introducing them. Unfortunately, I didn't catch this while staring at the code for several hours. (But hiphiphooray for unittests! :D )

Child Tickets

Attachments (1)

0001-Tests-12089.patch (6.6 KB) - added by trygve 6 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 6 years ago by isis

Resolution: fixed
Status: newclosed

This is fixed in my fix/12086-rcptto-other-domain branch, which is based on more unittests and bugfixes in my fix/9874-automate-email-tests branch.

comment:2 Changed 6 years ago by isis

Resolution: fixed
Status: closedreopened

Some of the fix for #12089 was disabled by #12627:

commit 422410756a7752d6af5b881776fb107fd5e6335e (tpo-isis/fix/12627-hotfixes, isislovecruft/fix/12627-hotfixes, greyarea/fix/12627-hotfixes, fix/12627-hotfixes)
Author:     Matthew Finkel <>
AuthorDate: Sat Jul 19 03:33:56 2014 +0000
Commit:     Isis Lovecruft <>
CommitDate: Tue Jul 22 22:26:42 2014 +0000

    Revert check for SMTP/email header canonical hostname equivalence.
    Signed-off-by: Isis Lovecruft <>
    For now, we need to revert this check to get the email distributor to
    function. We should look into this issue in order to get BridgeDB in a
    state where instances of it are runnable by other organisations to hand
    out their own bridges. [OTHER_ORG]
    Fixing this is essential for #12089.

diff --git a/lib/bridgedb/email/ b/lib/bridgedb/email/
index 7e5f900..3674702 100644
--- a/lib/bridgedb/email/
+++ b/lib/bridgedb/email/
@@ -631,12 +631,12 @@ class SMTPAutoresponder(smtp.SMTPClient):
         # The canonical domains from the SMTP ``MAIL FROM:`` and the email
         # ``From:`` header should match:
-        if self.incoming.canonicalFromSMTP != self.incoming.canonicalFromEmail:
-            logging.error("SMTP/Email canonical domain mismatch!")
-            logging.debug("Canonical domain mismatch: %s != %s"
-                          % (self.incoming.canonicalFromSMTP,
-                             self.incoming.canonicalFromEmail))
-            return False
+        #if self.incoming.canonicalFromSMTP != self.incoming.canonicalFromEmail:
+        #    logging.error("SMTP/Email canonical domain mismatch!")
+        #    logging.debug("Canonical domain mismatch: %s != %s"
+        #                  % (self.incoming.canonicalFromSMTP,
+        #                     self.incoming.canonicalFromEmail))
+        #    return False
         self.incoming.domainRules = self.incoming.context.domainRules.get(
             self.incoming.canonicalFromEmail, list())

Changed 6 years ago by trygve

Attachment: 0001-Tests-12089.patch added

comment:3 Changed 6 years ago by trygve

Added patch to to reproduce the issue described in this ticket. The test sends an email to bridgedb in which the 'MAIL FROM' address in the SMTP header differs from the 'From' address in the email.

Note: The test assumes that bridgedb should detect this situation and not generate a response. At the time of writing, this test fails because a response is generated.

Note: At the time of writing, test_smtp.has not yet been merged into the bridgedb master branch (currently in isis' repo)

comment:4 Changed 6 years ago by isis

Keywords: isis2015Q1Q2 isisExB isisExC added

comment:5 Changed 5 years ago by isis

Priority: criticalmajor

comment:6 Changed 3 years ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:7 Changed 22 months ago by gaba

Keywords: isis2015Q1Q2 isisExB isisExC removed
Owner: isis deleted
Sponsor: Sponsor19
Status: reopenedassigned

comment:8 Changed 17 months ago by gaba

Keywords: ex-sponsor-19 added

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

comment:9 Changed 17 months ago by phw

Sponsor: Sponsor19Sponsor30-can

Moving from Sponsor 19 to Sponsor 30.

comment:10 Changed 8 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.