[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult
quandary
quandary82 at hailmail.net
Sun Feb 3 13:03:18 UTC 2013
Remote file inclusion fixed, ashx handlers removed, FullImage removed,
website back up.
Filed but 10'001
https://bugzilla.xamarin.com/show_bug.cgi?id=10001
No, I don't mean parameter validation, and RFI can't work in MVC when
you request from a browser on Windows, because
parameters are separated by / and windows translates backslash to
forwardslash.
(at least not until one uses a catchall parameter), I checked.
If you'd use a browser on Linux, I don't know if it would change
backslashes into slashes,
which would be a potentially dangerous thing for a windows server.
But I have a Linux server, so who cares about that.
It can only work for parameters passed via QueryString/HttpPost, such as
in the two ashx handlers I added.
(or if a confidential file is in the same directory, but that would be
really stupid).
What I mean is file path validation in
Response.TransmitFile
Response.WriteFile
Server.MapPath
System.IO.Path.GetFiles
etc.
To check whether the requested file is not below the root directory of
the web application
(so that it would throw an AccessDeniedException on TransmitFile).
Or in other words,
if( !strFileName.StartsWith(AppDomain.CurrentDomain.BaseDirectory,
StringComparer.OrdinalIgnoreCase)
throw new AccessDeniedException("no access to files below
application root directory");
of course, the above is not sufficient, because relative paths in
absolute paths are possible and supported by .NET/Windows/Linux.
Because if that path validation isn't done, one can request (for example
in my previous handler)
wget
http://www.daniel-steiger.ch/WriteFile.ashx?myfile=../../../../../../../etc/passwd
which makes RFI interesting in the first place.
I checked an it worked, I got /etc/passwd back...
Now /etc/passwd wouldn't be that bad,
since it only contains MD5 hashes (though MD5 is rainbow-table
vulnerable) and because I configured ssh to not allow password logins,
but WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be
really really bad.
I think I remember stumbling over such an exception somehow in IIS
(perhaps SecurityException and not AccessDenied),
but not on the ASP.NET development server.
On 02/03/2013 12:41 PM, Daniel Lo Nigro wrote:
> Better I mention it than risking someone more malicious noticing it,
> since the link was already in a public mailing list. :)
>
> Isn't this a mono-bug, too ?
>
> As far as I'm aware, the .NET Framework only validates for HTML tags
> in parameters. It doesn't validate file paths since it doesn't even
> know the parameter will be used for a file path (things like "..\"
> could be valid GET parameters for your page). I don't think there's
> any built in mechanism to prevent directory traversal.
>
> .NET request validation:
> http://msdn.microsoft.com/en-us/library/hh882339.aspx
>
>
> On Sun, Feb 3, 2013 at 10:34 PM, quandary <quandary82 at hailmail.net
> <mailto:quandary82 at hailmail.net>> wrote:
>
> Oh wonderful, it's called remote file inclusion.
> I suspected that much, but I didn't bother to address it,
> because I didn't publish the sources and internal config files -
> up until today.
>
> So with you having mentioned it for all script kiddies to see -
> site taken down until validation is added.
> Before that, I quickly checked - one can access files below the
> root directory of the web application.
>
> Isn't this a mono-bug, too ?
> Because I think I remember me having done this once on a test or
> production server, and it gave a wonderful YSOD on IIS.
>
>
>
>
>
>
> On 02/03/2013 11:45 AM, Daniel Lo Nigro wrote:
>> That does look like a bug with how Mono handles TransmitFile - I
>> suggest reporting it as a bug in Xamarin Bugzilla (report it
>> under the System.Web component).
>>
>> Also FYI it's probably best if you pull down those pages for now;
>> you're not validating the "myfile" parameter so it's open to a
>> Remote File Inclusion
>> <http://en.wikipedia.org/wiki/Remote_file_inclusion> vulnerability.
>>
>>
>> On Sun, Feb 3, 2013 at 9:38 PM, quandary <quandary82 at hailmail.net
>> <mailto:quandary82 at hailmail.net>> wrote:
>>
>> Yep, indeed that sounds like that.
>> And I just tested.
>> Added WriteFile.ashx and Transmit.ashx
>>
>> and testet with
>> http://www.daniel-steiger.ch/WriteFile.ashx
>> http://www.daniel-steiger.ch/Transmit.ashx
>> and
>> http://www.daniel-steiger.ch/WriteFile.ashx?myfile=avatar100.png
>> http://www.daniel-steiger.ch/Transmit.ashx?myfile=avatar100.png
>>
>>
>> It seems the bug is in Response.TransmitFile for files of any
>> size
>> (also for avatar100.png, which is only 4.3 kb)
>>
>> so to summarize, there is a rather bad-natured bug in
>> Class: System.Web.HttpResponse
>> Method: TransmitFile(string filename)
>>
>>
>> This is the transmit-handler code:
>>
>> using System;
>> using System.Collections.Generic;
>> using System.Linq;
>> using System.Web;
>>
>> namespace Homepage
>> {
>> /// <summary>
>> /// Zusammenfassungsbeschreibung für Transmit
>> /// </summary>
>> public class Transmit : IHttpHandler
>> {
>>
>> public void ProcessRequest(HttpContext context)
>> {
>> string strFile = context.Request.Params["myfile"];
>>
>> if (string.IsNullOrEmpty(strFile))
>> strFile = "001.jpg";
>>
>> string strNetPath =
>> string.Format("~/Content/images/gallery/{0}", strFile);
>> string strFileNameAndPath =
>> context.Server.MapPath(strNetPath);
>>
>> context.Response.Clear();
>> context.Response.ContentType = "image/jpeg";
>> context.Response.TransmitFile(strFileNameAndPath);
>> }
>>
>> public bool IsReusable
>> {
>> get
>> {
>> return false;
>> }
>> }
>> }
>>
>> }
>>
>>
>>
>> Regards
>>
>> Stefan
>>
>>
>>
>>
>>
>> On 02/03/2013 06:14 AM, Daniel Lo Nigro wrote:
>>> That sounds like chunked encoding, Wikipedia says
>>> (http://en.wikipedia.org/wiki/Chunked_transfer_encoding):
>>> /Each chunk starts with the*number of octets of the data it
>>> embeds expressed in hexadecimal* followed by optional
>>> parameters (chunk extension) and a *terminating CRLF
>>> sequence*, followed by the chunk data. The chunk is
>>> terminated by CRLF. If chunk extensions are provided, the
>>> chunk size is terminated by a semicolon followed with the
>>> extension name and an optional equal sign and value./
>>>
>>> Which is exactly what you're saying. I wonder if something
>>> is not being done correctly with files as large as the ones
>>> you're using. Since you said it works for thumbnails, I
>>> assume it's working for smaller files.
>>>
>>> Try Response.WriteFile or Response.TransmitFile in a
>>> standard ASP.NET <http://ASP.NET> handler (.ashx) and see if
>>> they also don't work.
>>>
>>> All traffic to that URL [www.daniel-steiger.ch
>>> <http://www.daniel-steiger.ch/>] (except for the folders
>>> /doc and /images), but including images in /Content, is
>>> directly forwarded to fastcgi by nginx, as per fastcgi
>>> config file for domain.
>>>
>>> I'd still suggest letting Nginx serve your static files.
>>> Just because the site is low-traffic doesn't mean that
>>> little performance tweaks aren't good :). I do something
>>> like this:
>>> location / {
>>> # Pass requests for unknown files to Mono
>>> try_files $uri @mono;
>>> }
>>>
>>> location @mono {
>>> # Put all your Mono config here
>>> }
>>> My full site config is at
>>> https://github.com/Daniel15/Website/blob/master/nginx.conf
>>>
>>>
>>>
>>> On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill
>>> <quandary82 at hailmail.net <mailto:quandary82 at hailmail.net>>
>>> wrote:
>>>
>>> I have more details on the bug.
>>> The extra bytes that are at the beginning
>>>
>>> |3139366236380D0A|
>>>
>>> ||which reads 196b68/r/n in ASCII
>>> 196b68 is the filesize of the original image in hex...
>>> All details + hexdump links added here:
>>> http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
>>> All traffic to that URL [www.daniel-steiger.ch
>>> <http://www.daniel-steiger.ch>] (except for the folders
>>> /doc and /images), but including images in /Content, is
>>> directly forwarded to fastcgi by nginx, as per fastcgi
>>> config file for domain.
>>> server {
>>> listen 80;
>>> server_name www.daniel-steiger.ch
>>> <http://www.daniel-steiger.ch> daniel-steiger.ch
>>> <http://daniel-steiger.ch>;
>>> access_log
>>> /var/log/nginx/daniel-steiger.ch.access.log;
>>> location / {
>>> root /home/danillo/www/HomePage;
>>> #index index.html index.htm
>>> default.aspx Default.aspx;
>>> #fastcgi_index Default.aspx;
>>> fastcgi_pass 127.0.0.1:9000 <http://127.0.0.1:9000>;
>>> include /etc/nginx/fastcgi_params;
>>> }
>>> location /doc {
>>> root /usr/share;
>>> autoindex on;
>>> allow 127.0.0.1;
>>> deny all;
>>> }
>>> location /images {
>>> root /usr/share;
>>> autoindex off;
>>> }
>>> #error_page 404 /404.html;
>>> # redirect server error pages to the static page /50x.html
>>> #
>>> error_page 500 501 503 504 /50x.html;
>>> location = /50x.html {
>>> root /home/danillo/www/HomePage;
>>> }
>>> error_page 502 /502.html;
>>> location = /502.html {
>>> root /home/danillo/www/HomePage;
>>> }
>>> }
>>> It's sufficient to have the file served without FileResult.
>>> Of course it's more efficient if nginx serves it
>>> directly, but this is a very low traffic website, so
>>> performance is really not my problem ;)
>>> And by the way, the problem is not finding a workaround.
>>> I have already fixed it with a workaround about a week ago.
>>> I really just want to know where the bug is, because if
>>> FileResult malfunctions, there's probably more to it,
>>> and I don't want to walk into a subtle not at the first
>>> sight spottable bug later, like a botched binary
>>> upload/download file.
>>> On Sat, Feb 2, 2013, at 06:51 AM, Daniel Lo Nigro wrote:
>>>> Hmm... Maybe try an X-Accel-Redirect header instead.
>>>> This lets Nginx serve the file instead of Mono having
>>>> to serve it, which makes it more efficient. See if that
>>>> makes a difference, or if it has the same issue.
>>>> Why not just link directly to the file, instead of
>>>> serving it through your C# code?
>>>> On Sun, Feb 3, 2013 at 1:43 AM, quandary82
>>>> <quandary82 at hailmail.net
>>>> <mailto:quandary82 at hailmail.net>> wrote:
>>>>
>>>> Corrected the mime, but seems to be a mono-bug (or
>>>> fastcgi) anyway.
>>>> More here:
>>>> http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
>>>> --
>>>> View this message in context:
>>>> http://mono.1490590.n4.nabble.com/Bug-in-mono-3-0-1-MVC3-File-FileResult-tp4658382p4658422.html
>>>> Sent from the Mono - Dev mailing list archive at
>>>> Nabble.com.
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> <mailto:Mono-devel-list at lists.ximian.com>
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>> --
>>> SirNoSkill
>>> quandary82 at hailmail.net <mailto:quandary82 at hailmail.net>
>>>
>>> --
>>> http://www.fastmail.fm - mmm... Fastmail...
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130203/228799bf/attachment-0001.html>
More information about the Mono-devel-list
mailing list