34

I know about images posing a risk to security. I don't open suspicious junk emails for this reason. However, occasionally I have to check my junk email folder without clicking on an email just in case anything mistakenly went in there. I am seeing a growing number of junk emails have images in the FROM name before opening an email, such as the below screenshot.

enter image description here

As you can see there is a picture of a present at each side of the FROM name. I don't think these are a setting I can see when sending an email, so how are spammers getting images to show? Could such images contain tracking pixels, drive-by downloads or steganographic code?

Improve this question
3
  • 28
    Note that while they are not a security risk in and of themselves (as answers have pointed out), they're often a sign of a suspicious email. Very few legitimate companies actually use emoji in their 'From' lines, and even fewer people do.
    – Austin Hemmelgarn
    Sep 2, 2020 at 1:56
  • 36
    While 🎁 might look like an image, it's actually just a Unicode character that gets seemingly displayed as such.
    – Num Lock
    Sep 2, 2020 at 11:20
  • I'm sure the loophole's been closed for decades, but I once demonstrated how one could embed control sequences in the file names of a diskette directory, such that doing a dir on the diskette would execute commands on the (MSDOS) PC. Never figured out how to do anything dastardly, though, since the file names were too short.
    – Hot Licks
    Sep 4, 2020 at 0:32

4 Answers 4

Reset to default
82

The pictograms you are seeing in the name portion are Unicode emojis. They can be used anywhere there is an updated version of Unicode. To see a full list of the supported emojis for each version of Unicode, look here. You can copy and paste them just about anywhere, and they will display.

These do not contain tracking, they are loaded from your system locally. However, if they are embedded as an image within the body of the email, that is a different story.

Improve this answer
7
  • 127
    More fundamentally, emojis are text, even if they're weird text.
    – chrylis -cautiouslyoptimistic-
    Sep 2, 2020 at 1:14
  • 5
    Nevertheless, with emojis in the "From" header field, you do not only fool users, but there are some mail servers and mail clients around that still do not properly support Unicode in 2020. So, better to avoid it.
    – rexkogitans
    Sep 2, 2020 at 7:10
  • 7
    @OlegV.Volkov fun fact, there was a brief moment when web designers wanted their fancy fonts, but most of their clients didn't have them installed and no amount of graceful fallback would do. I don't know if any of them resorted to rendering the whole page once and then serving a static image, but I do know there were libraries that would render custom fonts into canvas client-side. It wasn't until five years later that webfonts got widespread support. I wouldn't be surprised if some web designer back then would use newspaper clipping style of font support - even at the severe cost it brings
    – John Dvorak
    Sep 2, 2020 at 7:40
  • 4
    @rexkogitans All SMTP headers are plain ASCII, and characters outside the ASCII range are required to be encoded, so the fact a server might not support it is not really relevant. Though to be honest, as a human, I consider all emails using emojis in the subject, from or to as spam-suspects.
    – Mark Rotteveel
    Sep 3, 2020 at 12:14
  • 2
    @TylerH I still think it can help people understing, there is no fundamental difference for a computer between the characters "Â", "道" or "🎁" they are both a unicode-sequence, which is replaced by a pixel rendering through the font-rendering system - although there is a difference in e.g. Windows, where emojis are usually replaced by a system-wide emoji-font irrespective of the font in which the emoji-sequence appears (since most fonts don't provide there own emoji glyphs)
    – Falco
    Sep 4, 2020 at 10:04
56

Those are not images. Email "From:" headers can contain text and only text. Unless your mail web/app-client has a glaring security hole, there will never be any images in this field.

The wrapped present you see - 🎁 - is an actual text character called "wrapped present". No matter how image-like it looks to you, it is still a character like any letter or number. For example, you can select and copy/paste it anywhere the text goes: in some text-only editors such as Notepad, or right into the middle of a sentence in this answer, as you can see yourself.

Improve this answer
7
  • I'd say they are quite obviously rendered as images and so images ... even if they are Unicode code points ...
    – 0xC0000022L
    Sep 3, 2020 at 18:33
  • 6
    @0xC0000022L you could also say that about any other characters in the Unicode set -- eventually even 'A', 'B', 'C', etc get rendered as a 2D grid of colored pixels on a screen, aka an image. However, in all these cases the software is handling the characters as text, using its standard text-rendering routines, which is the important distinction from a security perspective.
    – Jeremy Friesner
    Sep 3, 2020 at 21:14
  • @JeremyFriesner and that last bit is exactly what I contest! Just like another person mentioned a defect on iOS that was caused by font handling, there have been dozens of such issues in major OSs and software packages that I am aware of. It makes sense once you look closer into what typefaces are these days. This isn't one glyph to the next anymore. They are programmed to be "smart" and adapt to their location within text. This obviously then is a challenge to get right in software. And given the screenshot we don't know for certain the software treats it as text at all ...
    – 0xC0000022L
    Sep 3, 2020 at 23:20
  • 5
    @0xC0000022L By that argument, we don't know that the software treats any text as text. All the concerns you raised are regarding software crashes, which, yes, some unicode text handling routines can crash if presented with certain malformed input. But the original question was about tracking pixels and drive-by downloads, which are not a worry with unicode text.
    – HiddenWindshield
    Sep 4, 2020 at 2:22
  • 1
    @0xC0000022L: They're subject headers from emails. Of course we know it's stored as text, and rendered as text. No mailer is going to pass a header text string to a Javascript engine "just to see what happens".
    – MSalters
    Sep 4, 2020 at 15:01
15

One thing to note is that while these image characters (emojis) aren't generally considered a security risk in terms of vulnerabilities or bugs, they still have indirect security implications.

The biggest implication is that these emojis are not the only feature of Unicode. The goal of Unicode is that it wants to provide support for digitally representing every single writing system in the world. The problem is that some characters can be found in multiple languages, but slightly different. For example, the Latin letter 'a' can also be found in the Russian alphabet as the Cyrillic letter 'а', which looks exactly the same in both upper case and lower case. Phishers like to abuse this by replacing the Latin 'a' with the Cyrillic 'а' in certain words to mislead the more naive word filters, or as part of a domain name for IDN Homograph attacks.

Improve this answer
7
  • 3
    The other worry I have with emoji is that color was often a clue as to what is part of the apps UI and what is part of the (untrusted) text. With the introduction of emoji that distiction is gone.
    – Peter Green
    Sep 2, 2020 at 21:38
  • I always wondered why the phishing emails I get use names intentionally misspelled with look-alike unicode characters in the From field. It must be to fool the spam filters.
    – Seth R
    Sep 2, 2020 at 21:59
  • 1
    @SethR another reason phishing emails are often misspelled is to ensure that only gullible people reply to them. Spear phishing emails (targetted at specific high-value individuals) are typically impeccably formed, since they don't get the luxury of choosing to only target gullible people.
    – James_pic
    Sep 3, 2020 at 11:50
  • @James_pic, really? I didn't know text could be misspelled on purpose to select only the most gullible / less literate targets. That's very interesting. Do you have any proof or reference for that? Or is it just your opinion, something that you guess might happen anyway?
    – reed
    Sep 3, 2020 at 14:32
  • 1
    @reed security.stackexchange.com/questions/96121/…. The top answer has a link to research done by Microsoft.
    – James_pic
    Sep 3, 2020 at 17:21
4

Probably not, but...

Unicode's complexity (the BOM, UCS-2, UTF-16, UTF-8, and UTF-7 are bad enough, but then you've got combining diacritics, zero-width spaces, overlong encodings, right-to-left switching) means that there are going to be far more bugs associated with it than with ASCII.

When it comes to a web browser displaying Unicode text, the risk is very small. You pass Unicode text to a Unicode renderer that was written by people who know Unicode in and out.

It's when Unicode text controls something, like access to a file or the routing of an email, that problems arise. Although decades old, the notorious Microsoft IIS DotDot vulnerability is a great example. This took advantage of an overlong encoding for the / character, allowing attackers to potentially access any file on the server's hard drive.

In your case, the mail gets routed through a couple of mail servers. If there is a vulnerability in their processing of the email address, the mail server might be compromised—but it's the FROM address so it shouldn't do much damage. ... That is, unless you reply to the email (or there is some autoresponder), then it becomes a TO address, which is maybe what the attacker hoped for. 😉

I'm sure such an attack is very rare, and if it happens the emoji would probably look like garbage, but tl;dr Emojis are just Unicode characters and it's extremely unlikely for your device to be compromised by viewing them in a web browser.

Improve this answer
2
  • 4
    unlikely unless it's an iphone, there have been several unicode exploits against IOS eg: theverge.com/2020/4/24/21234191/…
    – Jasen
    Sep 3, 2020 at 8:46
  • 1
    @Jasen basically every major software (including OSs) which deals with parsing and rendering of fonts has been prone to something similar.
    – 0xC0000022L
    Sep 3, 2020 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .