Clicking this PoC link on iOS shows that the iOS Mail app suffers the same UI vulnerability. It appears like you are emailing support@paypal.com, when you are not.
I'm shocked this hasn't been resolved in mobile yet. I opened it up on my phone, and heck, with a pretty HTML form emulation in the email you could really have a very effective phishing campaign.
Thanks for clarifying. I should've been able to deduced that it was only fixed in the webapp from the "open on Android using Google Inbox or Gmail" part of your comment. I'm sorry.
Fun fact: the poc doesn’t “work” on iOS if you uninstalled the Mail app and are using a 3rd party client (link triggers App Store prompt “do you want to install mail”) ;)
A different one than the article but also weird/dangerous, it (was? is still?) possible to manipulate someone else's contact identifiers.
This may have been fixed, but I stopped using gmail years ago so I'm not sure..
For example imagine Alice emails Bob and Chad, and in the To: field for Bob she gives Bob a different "Name" like "Brad" <bob@bob.com>. If Chad replies to this email, Bob will now be in his contact list as Brad. The email is still bob@bob.com but you can see how it could be malicious, or at least fodder for fun pranks.
I have a long history of emailing a particular dude, call him Greg. Greg's email address does not have any periods in it. Gmail ignores periods, yes, but many other clients don't, so I want to never type Greg's email with a period. Further, I want to be able to reliably grep and join my own email exports.
Upon buying a new phone I received an email from Frank, who cc'd Greg. Fucking Frank has Greg's email address with a period in it.
From now on, no matter what I do, my phone autocomplete's Greg's email address with a period. At first I manually fixed it every time, but at this point I've given up. Now I'm as bad as Frank. It's like this virus that goes from Frank to Frank polluting the data as it goes.
If my contacts are going to be changeable by other people can they at the very least ask me first? Greg is on Gmail, can Gmail not auto-switch Greg to his canonical email unless I specifically request it not to? If Greg is going to be changed, why on earth is it one way (the right way) in my web inbox and a completely different way in my phone?
I just naturally assumed Gmail only filed things into Sent when it... sent them. I know that it does "pay attention" to what it's sending: if you're accessing Gmail through IMAP/SMTP you don't need to have your client store sent messages on the server; Gmail will populate them there for you when you send through their SMTP server.
My best guess would be that it is caused by the fact that GMail doesn't really have folders per se. It emulates them when it's syncing with your client through IMAP and the web interface shows you folder icons, but these are really labels. In the case of the "sent" label I'd guess it's just a well-optimized search over "From:" headers of all the mails stored in "All Mail". If this is the case, then it appears that this search isn't as accurate as one would wish it was.
I wrote @ronomon/mime, an email parser which enforces RFC 2822 3.6.2 and which also detects a variety of attack vectors before they can reach the email client.
Just through checking everything about an email carefully, @ronomon/mime has detected and brought to light some interesting attack vectors, for example a malformed email which crashes Apple Mail. This was disclosed to Apple's security team although they did not see any actual security implications.
Another interesting attack vector was an email containing millions of empty multiparts, which was able to crash several popular email servers. This was disclosed through Snyk, here are the details: https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...
My understanding is that email headers can be spoofed and should not be relied on. So this is probably too hard to ask from an email client (i.e. a program that reads and writes emails) that only has access to the email headers. Whereas for the email server (the computer that sends/receives emails for this address) this would be trivial, just keep a list of emails that the server has sent.
This reminds me of the issue where spam emails with a calendar invite would not only appear on your Google calendar, but if the event was triggered, would give you a notification. I believe they fixed this one.
First, note that a great many enterprise use cases are total nonsense. But still: people want to be able to put messages into gmail from random other systems and have the "sent" label be applied, so they can treat it as a system of record.
I assume the use case is when email has been sent by the user, but not via Gmail. The external system can send the email to Gmail with the correct From header and have it filed along with other sent messages.
Even if that's the reason why, it's a pretty brain-dead way for them to implement it. If people want emails from a separate address that CC's Gmail on sending to be seen as sent, Gmail should have them show up like the normal emails that they are received but show a little button that asks if you want them to be seen as sent, and if you accept creates the filter to do so from that source (and shows it in filters so it can be removed later).
It's not like Gmail doesn't show "nudges" and other crap all over the place for stuff like this.
But it's implemented now in such a way that anyone can get an email in there by simply crafting the From address carefully. Out of the lesser of two evils, I know which one I would vote for.
Besides, since in the proposed solution the system is creating the filter, it could bypass checks that require the label not be sent. Just because it shows in filters, and it can be removed from filters by the user, doesn't mean it has to be able to be created through the normal filter mechanism. You still have a "system of record", if that's how we want to refer to this feature, it just requires a single initial setup step on the first received email that is intended to be kept as sent. That's entirely in line with how Gmail currently does things, such as allowing alternate From addresses (which requires an authorization step).
I'm on board with this style of thinking. After reviewing the comments with the linked tagging behavior it's clear that Google is ignoring the spirit of RFC 2822 3.6.2-3.6.3 in order to shoe-horn in a feature of some possible utility, at the expense of the average customer's security.
It's a bug that this can be forged by an outside attacker, even if it is a consequence of the implementation of a feature.
(In fact, it's a bug that defeats the central purpose of the “system of record” feature it’s been suggested that the underlying functionality exists to support, as trustworthiness is the essential point of a system of record.)
Vulnerability details: https://eligrey.com/blog/google-inbox-spoofing-vulnerability...
Screenshot: https://go.eligrey.com/t/screenshots/google-inbox-spoofing-o...
PoC demo (open on Android using Google Inbox or Gmail): https://dangerous.link/gmail-and-inbox-spoofing-on-android