Assuming that the user clicks no links and opens no attachments in the email or anything of that sort — just opens it.
|
|
I'll give you a really simple example. A common spammer trick way back before clients were updated to counter this was to embed a 1px square GIF in an HTML email. You'd get a message like this:
Needless to say, that
This trick was used to confirm email addresses as active spam targets, to move them onto active address lists, which spammers then sell. The problem, and solution, lies in step 2 - automatically trusting the incoming content. Bugs in the email client that only require the email to be read require a bug in the client reader that can be used to trigger the exploit. For example, a HTML rendering engine might load the flash player. It's unlikely, but there could be exploits in the client's string processing code. And so on. Now, this also applies to web clients too - who will be supplying html to the browser to render, thus opening up all attached browser vulnerabilities. I wasn't going to read the article, but I now have:
The article is a little light on details, but I'd like to take time to provide some more calm advice:
|
|||
|
|
|
In that case the email must exploit a bug in your email client. That's relatively hard for plain text emails, but easier for html emails. Html parsers and renderers are complex, and often contain bugs that allow code execution(for example a buffer overflow). Viewing an evil email is pretty similar to viewing an evil website from a security point of view. |
|||
|
|