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?

Rodrigo de Azevedo
  • 242
  • 2
  • 13
Coderxyz
  • 562
  • 4
  • 9
  • 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 02 '20 at 01:56
  • 36
    While might look like an image, it's actually just a Unicode character that gets seemingly displayed as such. – Num Lock Sep 02 '20 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 04 '20 at 00:32

4 Answers4

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.

Yevhen Stasiv
  • 672
  • 3
  • 8
  • 127
    More fundamentally, _emojis are text_, even if they're weird text. – chrylis -cautiouslyoptimistic- Sep 02 '20 at 01: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 02 '20 at 07: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 02 '20 at 07:40
  • @JohnDvorak Yes, I know. I left it out of my answer for simplicity sake. Even in this case there's still no images in From: header, it is client replacing character with image client-side and thus such replacement have no relation to original message content and author. And in such case "they are loaded from you system locally" is still a bunch of FUD. – Oleg V. Volkov Sep 02 '20 at 13:58
  • 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 03 '20 at 12:14
  • @chrylis it may be less confusing to refer to emoji as (Unicode) "characters" rather than "text". Otherwise this could lead to confusion between emoji and emoticons. – TylerH Sep 03 '20 at 13:06
  • 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 04 '20 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.

Yevhen Stasiv
  • 672
  • 3
  • 8
Oleg V. Volkov
  • 799
  • 5
  • 11
  • I'd say they are quite obviously rendered as images and so images ... even if they are Unicode code points ... – 0xC0000022L Sep 03 '20 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 03 '20 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 03 '20 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 04 '20 at 02:22
  • @HiddenWindshield was this about my last sentence? Well, then you misapprehend me. The fact that we don't know software and website means that this could just as well be SVG-based or other glyphs. So yeah, I still hold that whether those are actual Unicde glyphs treated as such or dynamically handled by some Javascript to yield an image (pixel based graphic) would make a difference. But _if_ this were the case they'd still be unusable for tracking. But discarding that option when it's about security ... well YMMV. – 0xC0000022L Sep 04 '20 at 07:48
  • 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 04 '20 at 15:01
  • @MSalters ... did you even read what I wrote? Of course there is code out there which substitutes certain "well-known" Unicode code points with images in absence of actual font glyphs. And if this happens to be a screenshot from a browser, anything goes. The OP doesn't specify where the screenshot is from. – 0xC0000022L Sep 04 '20 at 20:02
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.

Nzall
  • 7,313
  • 6
  • 29
  • 45
  • 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 02 '20 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 02 '20 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 03 '20 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 03 '20 at 14:32
  • 1
    @reed https://security.stackexchange.com/questions/96121/why-do-phishing-emails-have-spelling-and-grammar-mistakes. The top answer has a link to research done by Microsoft. – James_pic Sep 03 '20 at 17:21
  • Yeah, this has made international domain names quite pointless. The whole point in using those for me was always to have, well non-latin characters. And then I noticed browsers act up. And they aren't even very clever about it. If there was at least something like a logic where if the domain name is comprised exclusively from characters prone to homograph attacks they fall back to showing the raw domain name, it'd be acceptable. But if I can't have a name with Cyrillic which contains characters like Ж which isn't close to any latin character, IDNs are pointless. – 0xC0000022L Sep 03 '20 at 18:38
  • @PeterGreen If you're worried about the color of emoji being confusing, just remove all the color emoji fonts and install a normal black-and-white one. Problem solved. – HiddenWindshield Sep 04 '20 at 02:27
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.

Artelius
  • 588
  • 2
  • 4
  • 4
    unlikely unless it's an iphone, there have been several unicode exploits against IOS eg: https://www.theverge.com/2020/4/24/21234191/apple-iphone-crash-text-bug-ios-13-problem – Jasen Sep 03 '20 at 08: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 03 '20 at 18:40