> > RFI can't work in MVC Yeah, routing rules should block it, I forgot to mention that. I don't think ASP.NET MVC allows "\" in its route parameters.
But if you have the default route (/ControllerName/ActionName) enabled, your app could still be vulnerable. A user could pass the parameter as a GET or POST parameter (ie. go to /Gallery/FullImage?id=../../../../../../../etc/passwd) and the default model binder will accept this parameter. It's usually safer to always do validation of your parameters instead of relying on the routing engine to do it :) 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 But in some cases you might want to read files below the root directory (eg. some apps use c:\Windows\Temp or /tmp) WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be really > really bad. This should never work as id_rsa should have its mode set to 0700 and Mono shouldn't be running as root. The user Mono runs as should be relatively locked down. I use www-data (the default web server / PHP-FPM user in Debian) for mine. On Mon, Feb 4, 2013 at 12:03 AM, quandary <quandar...@hailmail.net> wrote: > 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 <quandar...@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 <quandar...@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.NEThandler (.ashx) and see if they also don't work. >>> >>> All traffic to that URL [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 <quandar...@hailmail.net>wrote: >>> >>>> I have more details on the bug. >>>> The extra bytes that are at the beginning >>>> >>>> 31 39 36 62 36 38 0D 0A >>>> >>>> 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] (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 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; >>>> 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 <quandar...@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@lists.ximian.com >>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>> >>>> >>>> -- >>>> SirNoSkill >>>> quandar...@hailmail.net >>>> >>>> -- http://www.fastmail.fm - mmm... Fastmail... >>>> >>>> >>> >>> >> >> > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list