Hacker News Reader

Comment by Danieru | Hacker News Reader

Ohh, that sounds perfect for DOS attacks. A clean reflection attack vector operating on giant assets.

The email server does not need to load all the images at once. If it receives a billion emails, it can retrieve linked images a few per second per domain. Or on demand if the email is opened. The email server does not even need to completely drain the queue and load all the images, just images from enough emails to bollocks up the results is enough. The end result is the same, in that the sender does not know if the email was read by a human or not.

> just images from enough emails to bollocks up the results is enough.

A large enough proportion of opens either does not trigger an image retrieval or triggers one but the user won't read the message anyway, so open rates have always been approximate. The time of day, the news, the weather all distorts the data so much anyway that the only sensible use of the data is trends, so it'd take some effort to distort the data enough for it to be useless.

Your best suggestion I think would be to rate limit it, with the caveat that if you want to immediately deliver messages you'd need to also open on demand, and e-mail opens are extremely spiky so you might struggle to smooth out the opens entirely, but it might be enough to make it useless enough for people to ignore the data.

How? If you send an email with an image to 15k recipients in a mail server the image would be fetched once and the recipients would only get the cached version.

Image URLs often contain identifiers that are unique to each recipient.

So this would only dissuade that practice as it causes a DDOS against those who do because it causes additional requests and prevents caching.

The image url can point at an innocent third party.

Which innocent third party provides thousands of unique image URLs?

https://example.com/img.png?x=1 https://example.com/img.png?x=2 https://example.com/img.png?x=3 https://example.com/img.png?x=... https://example.com/img.png?x=1999 https://example.com/img.png?x=2000

You need but one image, to craft an arbitrary number of unique urls using a querystring.

In theory one could also use all permutations of uppercase/lowercase letters in the path to the image. Most webservers are case insensitive so all will yield the same result but I believe the http standard considers the path to be case sensitive so all those urls would be unique.

As I said in another comment, crop all the parameters from the URL, and the problem solves itself. Path is case sensitive, the domain must be lowercased anyways, so no problem either.

Crop the parameters and you have no reason to assume it points at the same image. Good luck explaining to your customers what happens when someone finds a way to effectively poison your non-unique image cache with something offensive.

> Crop the parameters and you have no reason to assume it points at the same image.

Well, that is going to be a problem for the mailer. I'm totally fine with banning dynamic parameter dependent images.

> Good luck explaining to your customers what happens when someone finds a way to effectively poison your non-unique image cache with something offensive.

I would say it is the email marketer fault for using unsupported parameterized images. I cannot image a legit use for that, and many evil spammy ones.

> I would say it is the email marketer fault for using unsupported parameterized images.

The problem is this would not just happen to e-mail from email marketers, but also between regular users, and it would take just one particularly nasty exploit of cache poisoning of urls to some site with user-generated content before you suddenly have the press asking you why some innocent picture sent by someone underage to someone else underage was replaced by your site by hardcore porn - or worse.

I've run a webmail provider. I've seen the amount of abusive bullshit spammers and scammers do whether for profit or for fun or to get back at someone. It used to be my job to find these kind of issues before bad guys did, and one thing we learned very quickly was that every little thing like this would instantly have people probing it for ways to abuse it to cause grief for someone else. Or for us.

If you were going to ban images parameterized by URL parameters (and that would not ban parameterized images, just reduce the number of sites that could be attacked), the only viable choice is not load them at all. Just stripping the parameters would be an absolute disaster and wildly irresponsible.

So your solution is basically to throw various standards overboard so that spammers cannot generate more urls than there are images on a specific domain. Isn't this cure worse than the (at this point mostly hypothetical) disease?

Crop all the parameters from the URL. Problem solved.

> Just stripping the parameters would be an absolute disaster and wildly irresponsible.

It's not worse than allowing a randomly selected subset of HTML in the emails, and nobody is saying it is an "absolute disaster" or saying that google or Microsoft are "wildly irresponsible". The mailers and people will get used to it. As they always do.

What would be the difference from normal hotlinking in a standard email? The vector in both cases would be being able to send a million emails; a reflection attack with spam emails as a vector would be just the same without provider servers doing anything special. MUA opening images would do the attack.

Actually a provider could cache the hotlinked resource and remove almost completely the reflection.

Using only plain-text emails solves the problem nicely. Who'd even want to ever use HTML mail other than shady or clueless or annoying people? Just use plain-text only and the problem is solved.

Yeah, the typical HN/usenet/ML solution to everything: just use plain text, it's good for everyone and nobody needs anything else. Newspapers and books always looked like an RFC document anyway, right?

Even better DDOS, just spam lists of image links to various email providers and watch your target collapse under all the requests.

Reply on news.ycombinator.com