Hacker News Reader

Comment by n_plus_1_acc | Hacker News Reader

That's not a new problem tho. .TS and .CS are TLDs and Heck even .COM is also a file extension, should we block that too? What changed suddendly?

View on HN

The type of user who has email conversations about .COM files is the same type of user who will realize that the link was automatically created by someone's email client and have a laugh about it.

I don't know if you can say the same about zip files, an average user they might encounter someone mentioning a zip filename a handful of times in a year and they might click on the link expecting to get that zip file.

The thing is '.com' is relatively unknown. When was the last time you had a genuine .com file you needed to use?

And you're someone who's tech-savvy.

Most people are going to see ".com" and think "Website" not "Program". So if suddenly a .com file is downloaded there's at least a chance they might stop and wonder what's going on.

I run into this issue all the time - We get Bug bounty reports constantly because $SecurityResearcher put "example.com" into the "Company Name" field, and we sent them an email saying "Thanks for signing up. We hope you find $OurProduct useful at $CompanyName. "

When the email turns up in their Gmail inbox, Gmail "helpfully" turns the plain text "example.com" into a link to https://example.com - so $SecurityResearcher reports it to us as a vulnerability in our platform because "we" are linking to example.com - except we never did, and we have no way to tell Gmail, or Outlook, or any other platform to stop doing that.

Services we pay for, directly, also do this - Notion and Slack are two I can think of immediately. I have to fight them to stop turning my mention of some file into a link to a random domain. (e: Maybe Slack has stopped doing this, perhaps - in testing it didn't do automatic linkifying for messages to myself)

This was bad enough with .cs, .ts, .js., .json and so forth - but having a .zip link appear in the middle of documentation on how to do something with a zip file is a recipe for disaster.

I've had a document saying "please download package.zip from the build artifacts site" - which was then auto linked to https://package.zip - and anyone not paying attention might expect that it was a link to the build artifacts site.

Good point. I wonder what happens if i rename a malicious file into google.com and push it into ever AD user's desktop at a large corporation. Might not even make a difference that MS hides extensions by default.

The COM file exploit worked because it is relatively unknown. I remember a worm going around when I was in grad school where you'd get an e-mail with a link to https://giftcard.customerservice.savemoneyonanew.tv/amazon.c.... Users who had been through the phishing training would see the HTTPS at the beginning and the amazon.com at the end and know that this was a legitimate Amazon email. The e-mail instructed them to click the link and "open the PDF file". Users would click the link, down load the COM file, and the open the file, installing malware all over the machine and forwarding the worm to all their contacts.

I don't get it, why is it a "vulnerability" if you send people emails that contain a link to example.com? What exploit is possible?

Unsanitized web form mailers are a common source of spam mails, in particular if that form allows specifying an arbitrary email address to send the mail to. Essentially what the website owner meant to do was sending an innocent email (maybe for leaving feedback, or for a signup link), and the email text then gets mangled by the spammer in a way that you are seeing a link to product they want you to buy. It is not a vulnerability in the sense that it leads to malicious code being executed, but it allows spammers to send their spam links through "reputable" email sources, increasing the likelihood that it will make it through spam filters.

You're missing the point: he did not send an email with a link, he sent an email in plain text, no hyperlink, containing the ASCII characters "example.com", and the recipient's email client silently changed it into a hyperlink. And of course that doesn't just happen with "example.com"; it happens with any piece of plain text that the email client decides might be a URL, which includes many file names since many common file extensions are also TLDs. That is the security issue.

Because some unsuspecting user may think we are linking them to some random site, even if we are not.

If that domain is "important-banking-info.zip" then people are less likely to be suspicious if their browser happens to download a file of the same name.

COM files have been used maliciously due to confusion with urls [0]. I think I've heard of antivirus software preventing COM files from being run because of this.

[0] https://en.wikipedia.org/wiki/COM_file#Malicious_usage_of_th...

Can .COM files even run on modern 64-bit Windows systems? Surely they can't - hasn't the 16-bit subsystem been removed?

Windows will run a regular MZ exe even if its name ends in .com.

MZ exe, what do you mean?

https://en.wikipedia.org/wiki/DOS_MZ_executable

MZ is the magic number at the start of the file.

Although gp probably meant a PE executable [0] which (typically) start with a stub MZ executable telling DOS users to run it under Windows. Because of this they still have a MZ magic number.

[0] https://en.wikipedia.org/wiki/Portable_Executable

OK, thanks I thought I screwed up.

I have recently been working on a command line tool and the windows version is called mz.exe. On Linux it is just 'mz', just a coincidence. I was concerned this name collision might cause problems, but that is fine.

It's not a new problem, but think about how many average computer users expect to be sent a ZIP file, vs how many of them expect to receive a TS, CS or COM file in their inbox.

COM files are a good point I hadn't considered.

Reply on news.ycombinator.com