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