-1

I am using a messenger app that's similar to WhatsApp.

This app allows me to send any type of files, like Html, Php, SWF etc. via text messages.

Is this a vulnerability?

schroeder
  • 123,438
  • 55
  • 284
  • 319
user183535
  • 57
  • 3
  • 2
    A vulnerability for who? Slack allows me to send whatever file I want. I'm supposed to trust the other person on the other end isn't sending me malicious junk. – Steve Sether Aug 08 '18 at 18:11
  • 2
    Vulnerabilities are somewhat subjective. If the app by design allows users to exchange arbitrary files, it's not a vulnerability. If it's supposed to provide some level of protecting users from other users sending malware, it is. – Steve Sether Aug 08 '18 at 18:20
  • Slack is made for developers. It allows to send html and php files. If you send me html files via slack. It will automatically open by html5 editor – user183535 Aug 08 '18 at 18:21
  • Actually I have read a blog post. A guy got RCE and XSS by uploading a PDF and Swf file on a website. So I was curious to know that we can send files via social-neworking applications. Some applications allow to sending PDF, SWF format files and some app doesn't allow. Some apps only allow to sending photos and videos. Like Facebook and what's app do. That's why I have asked this question. When we upload something on websites that goes to root server. That's why maybe we get RCE vulnerabilities. And mobile applications maybe didn't pass files to root servers. – user183535 Aug 08 '18 at 18:32
  • Yeah, what matters is the context of the file parsing. Any file can carry a dangerous payload, however it's up to the context of whether or not that payload will be executed in a dangerous way. Allowing arbitrary file upload to a website that may in some way parse the file (with execute permissions) can be dangerous for the site. If the site never parses it in a way that can execute the payload, then it's fine. If you send a PHP file to a device that doesn't have PHP parsing, then a PHP file will do nothing, it's just a text file. – Jarrod Christman Aug 08 '18 at 18:37
  • 1
    What you are describing is not "unrestricted file upload". That means you can send files to a server for processing. You are sending arbitrary files over a communication channel. – schroeder Aug 13 '18 at 11:35
  • "text messages" is *very* vague. SMS? IRC? Whatsapp? Slack? – Martin Schröder Aug 14 '18 at 21:04

3 Answers3

2

Not exactly a vulnerability accepting these files. The main problem is your application opening these files and interpreting them which can lead to:

  • Malicious File Upload
  • Malicious File Inclusion "../../../evil.php"
  • Stored Cross Site Scripting "alert("Stack is the best...")"
  • Resource Injection and others.

What normally happens is an enhanced algorithm that detects these certain behaviours and content inside the application, or sandbox it to open within a certain memory which means you cant do anything besides at that point. As an example try write script tags in stacks answers and you will see that it doesnt allow you.

1

It depends.

Just because an application allows for files (of an variety) to be uploaded does not immediately point to there being a vulnerability. It is important to understand how the backend handles these files.

If the backend actually executes the file then you could potentially have a vulnerability, otherwise if the contents are merely displayed back to the user as text, or in a sandbox/preview sort of context, like how browsers display PDF documents, then there should be no issue because the application is helping to protect the user by deweaponizing it. Of course there could be edge cases where the file can be executed but that might indicate a 0day vuln or a not-up-to-date application.

jonroethke
  • 1,006
  • 2
  • 7
  • 21
1

It is entirely up to how you handle the untrusted data. If you render it in a way that it would be executed, then yes.

There are layers you need to approach, is there a file type you don't want, file size you don't want to exceed?

Joe M
  • 2,997
  • 1
  • 6
  • 13