Created attachment 8721201 [details] PoC.txt User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0 Build ID: 20151210084841 Steps to reproduce: Hello, I have found a vulnerability that affects Mozilla ThunderBird, that leads to unexpected behavior, and can be used in performing watering-hole attacks. The issue can be reproduced when a user send a <form> and <input> HTML attributes within the email. ThunderBird fails to render the <input> tag, and causing it to be opened by Firefox or the default browser once the user navigates to the email. This can be used in performing Social Engineering attacks and Watering Hole attacks, as the victim would not expect this behavior. An attacker can point the form to an executable file that will be downloaded once the user opens email. Also, it can be used as a vector in phishing attacks. Proof of Concept:- http://secbot.me/0bin/?09b54e6a0d2ee063#zrcVDQQQxMvqOswz20RRAFtOievmNyFcZDkaWsusY04= Best Regards, Mazin Ahmed Expected results: The <input> and <form> HTML attributes should habe been stripped from rendering. Also, it should to lead the current behavior of opening link automatically.
There's no automatic opening of the form. That requires the user clicking in the form and it is expected that we open the form for filling in the browser instead on such occasions (so the user can have all the usual ways of knowing where he is and where the data would be submitted). I don't think there's much of an issue here. There's always social engineering ways to trick users to follow a link, and your case is not really different from that.
Yes, I understand that, but the difference here that there is way that a normal sender sends an email with <input> and <form> tags. I can't think of any occasion that is needed to have those tags in an email. If someone would the user to act by submitting the form, he would actually share a link to the form, he wouldn't embed it.
Not good practice, no. But you get what you ask for - and if it happens to be something legit I think the current behaviour is a good trade-off. Conversely, if you for some reason want something that look like a button to show up in an html mail you can always achieve that e.g. by embedding an inline image. So disabling rendering of certain elements is pretty moot.
Thank you for your report. I don't see anything that make this inherently more dangerous than a phishing attack, both require user interaction and tricking someone to follow a link. The executable file triggers a dialog box for how to handle it, this unexpected unusual behavior would cause most people to be suspicious, making it less useful to attackers by virtue of likelihood of making a target more cautious. This is also more of a phishing attack than a watering hole attack. Example of watering hole attack: http://krebsonsecurity.com/tag/watering-hole-attack/ All that aside, I agree with the reporter that <input> and <form> tags should not be rendered. There is no reason to render them, and a good reason not to: it makes a phishing attack marginally easier. Most importantly, because the tags aren't necessary, stripping them will immunize us against any other possible issues that are lurking in their handling. So while I'm setting the risk to low, I would urge the Thunderbird project to prioritize this patch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: csectype-other, sec-low
Summary: Unexpected Behaviour in Mozilla ThunderBird That Leads to Watering-Hole Attacks → Unexpected Behaviour in Mozilla ThunderBird That Assists Phishing Attacks
Minusing for a bounty because this is a "low" rated security issue and does not qualify because of that.
You need to log in before you can comment on or make changes to this bug.