Are there any security checks on uploads from users? IE does Discourse do anything to stop people from uploading corrupt images, binaries, .js scripts, etc?
You can only upload allowed file types by extension, that is it. So if you have whitelisted .xls, people can upload .xls files.
Right now we just allow the standard, default extensions (jpg, jpeg, gif, etc).
You can test that on try.discourse.org if you like, e.g. upload corrupted stuff and see what happens.
Okay. But can you answer the question?
Not trying to troll you, just trying to get this question answered as we’re in the process of deciding if we should disable file uploads. I’d rather not since it would limit our users from expressing themselves, so I’m wondering if Discourse does any automatic file checking.
I don’t see what harm it would cause. If an uploaded image is corrupt, for example, it just won’t display as a valid image.
If you want to read more about Unrestricted File Uploads and how they’re exploited, here’s more info: Unrestricted File Upload - OWASP
That page has recommendations for how to make things more secure, go to the Prevention Methods section at the bottom of the page.
I’m still unclear why this is a problem, the actual markup produced of uploading a JS file as an image is
<img src="/uploads/default/398/a23952be96fdb105.jpg" width="null" height="null">
It’s conceptually no different than uploading a bad image file. And when retrieving the file we return
And yet when I look there
And some special recommendations for the developers and webmasters:
- Never accept a filename and its extension directly without having a white-list filter.
That is the first thing I mentioned above, and we have done this for ages. Only extensions on the whitelist are accepted.
Can you provide more details on what the issue is, exactly? Maybe with a repro on try?
I agree, this is a non-issue. Windows runs files by their extension; extensions are whitelisted. On Linux, a downloaded file will never be marked executable by the browser. Sure, you could upload an ELF named as .jpg, but good luck getting people to
chmod +x and run it.
Doesn’t seem to be a problem unless the link is clicked
File has been deleted
.svg is also specifically whitelisted here, and that’s not a default, the default whitelist for file upload is
.jpg .jpeg .png .gif
Connection:Keep-Alive Content-Encoding:gzip Content-Length:261 Content-Type:text/html
Browser are treating it as HTML file
Thanks, Jeff. I’ll work on getting more details and perhaps see if we can do a repro for you. This is a bit out of my depth, so I’m chatting with others to see what can be done to exploit this particular issue.
Hi @codinghorror , our team hasn’t had the time to try to deep dive into things and exploit Discourse on this issue. Though I did see some recent news from Ebay that describes exactly what I was asking about:
Does Discourse do any header checking on images that are uploaded?
Let’s see if we can exploit it first, following those instructions.
- Rename exe to gif
- Get people to click on it and run it
I am on a Windows system so this won’t be much for people who aren’t…
calc.gif. File size 912 KB (933,888 bytes)
Provide link to the file (I guess adding the .exe back on at the end… somehow?) Discourse Meta
In theory this would work for vulnerable PDFs as well, but PDF is a valid upload type, and vulnerable PDF viewers are the problem there, like if the browser’s GIF handling had some kind of buffer overflow.
Ok so I
Download the file. Does seem about the right file size, 911 KB (933,632 bytes)
Rename it to .exe
Run it and get
Windows SmartScreen has prevented an unrecognized app from running. Running this app might put your PC at risk.
Ok so select file properties, Unblock
Run it and get
ImageMagick editing the images strikes again!
@codinghorror I’m not sure what that proves. I was able to upload an HTML file that I renamed to .gif, then download the file locally, rename the file to .html and run the HTML in my browser.
That if you can get someone to go through that amount of work, they deserve to receive the end result.
Well the article you cited says
eBay has fixed a pair of security vulnerabilities in its site that could enable attackers to upload executable files disguised as benign file types, construct full path URLs and then point victims to them through drive-by download attacks.
That clearly would not work here, since I can’t repro it. Can you?
As for HTML pages being uploaded, I still don’t understand what the “exploit”. If you made a HTML page that says
Discourse causes cancer!
And wanted us to serve it, Ok that would be bad. We don’t want discourse.org to serve a web page that tells people Discourse causes cancer.
But that doesn’t work either. You could rename that file and upload it as a gif but it will always be served as a GIF! Never as a HTML file.
At the point where you download the GIF, rename the file on your local computer and click on it… that’s not an exploit.
I agree that it’s not a bad idea to run some additional checks on images to make sure they are images, but there’s no exploit around it here that I can reproduce.
If I can upload an HTML page I can do what’s called a Cross Site Scripting (XSS) attack, as some browsers will render gifs as HTML. Neal Poole from Facebook wrote about a Wordpress vuln like this back in 2011
Again, I’m not a security researcher (though that’s what our community is made up of), so I can’t speak at length about XSS or test this thoroughly. I’m just wondering if you guys do anything to check headers of uploads. If you could answer that question for me, that would be awesome.