Bugzilla – Bug 580
browsing a shortcut goes to root directory
Last modified: 2008-12-18 11:51:49 UTC
This could be a big security problem. If there is a shortcut in teh folders, browsing music folder will descend to the root folder instead of the shortcut. It seems Utils::Misc::urlFromWinShortcut is returning the absolute path, instead of a URL. Here's a bit of the log: 2004-09-23 14:16:32.9062 file:///D:/mp3/test/Shortcut%20to%20test.lnk 2004-09-23 14:16:32.9062 file:///D:/mp3/test/testsong.mp3 2004-09-23 14:19:16.0781 pathFromFileURL: D:\mp3\test isn't a file URL... 2004-09-23 14:19:16.0781 Backtrace: frame 0: Slim::Utils::Misc::pathFromFileURL (D:/slim/server/Slim/Utils/Misc.pm line 464) frame 1: Slim::Utils::Misc::virtualToAbsolute (D:/slim/server/Slim/Web/Pages.pm line 131) frame 2: Slim::Web::Pages::browser (D:/slim/server/Slim/Web/HTTP.pm line 662) frame 3: Slim::Web::HTTP::generateHTTPResponse (D:/slim/server/Slim/Web/HTTP.pm line 579) frame 4: Slim::Web::HTTP::processURL (D:/slim/server/Slim/Web/HTTP.pm line 455) frame 5: Slim::Web::HTTP::processHTTP (D:/slim/server/Slim/Networking/Select.pm line 116) frame 6: Slim::Networking::Select::select (D:\slim\server\slimserver.pl line 440) frame 7: main::idle (D:\slim\server\slimserver.pl line 383) frame 8: main::main (D:\slim\server\slimserver.pl line 847) Use of uninitialized value in pattern match (m//) at D:/slim/server/Slim/Music/Info.pm line 2695. Use of uninitialized value in pattern match (m//) at D:/slim/server/Slim/Music/Info.pm line 2695. 2004-09-23 14:19:16.0937 pathFromFileURL: D:\mp3\test isn't a file URL... 2004-09-23 14:19:16.0937 Backtrace: frame 0: Slim::Utils::Misc::pathFromFileURL (D:/slim/server/Slim/Utils/Misc.pm line 464) frame 1: Slim::Utils::Misc::virtualToAbsolute (D:/slim/server/Slim/Web/Pages.pm line 269) frame 2: Slim::Web::Pages::browser (D:/slim/server/Slim/Web/HTTP.pm line 662) frame 3: Slim::Web::HTTP::generateHTTPResponse (D:/slim/server/Slim/Web/HTTP.pm line 579) frame 4: Slim::Web::HTTP::processURL (D:/slim/server/Slim/Web/HTTP.pm line 455) frame 5: Slim::Web::HTTP::processHTTP (D:/slim/server/Slim/Networking/Select.pm line 116) frame 6: Slim::Networking::Select::select (D:\slim\server\slimserver.pl line 440) frame 7: main::idle (D:\slim\server\slimserver.pl line 383) frame 8: main::main (D:\slim\server\slimserver.pl line 847) Use of uninitialized value in pattern match (m//) at D:/slim/server/Slim/Music/Info.pm line 2695. Use of uninitialized value in pattern match (m//) at D:/slim/server/Slim/Music/Info.pm line 2695. 2004-09-23 14:19:16.0937 Scan::addToList: file:/// It looks as if urlFromWinShortcut is expected to return a path in some cases where it has been used. simply chaging it to pathFromWinShortcut and expecting a path to be returned avoids having file:/// returned to the browser.
Created attachment 143 [details] rename pathFromWinShortcut fixes a debug typo renames urlFromWinShortcut to pathFromWinShortcut becuase the routine returns a path, not a fileURL remove a pathFromFileURL call in virtualToAbsolute because we already have a path. avoids an insecure FileURL being returned.
Well - I think the bug is only partially solved - because a bad link returns still a bad value and slimserver goes to the root dir in this case... The fll fix would be to detect a bad value from pathFromWinShortcut and just move to the current directory in this case. A patch could look like the following (SlimServer Nightly 2004-10-05 - misc.pm - line 464 in the else of the if clause): if(pathFromWinShortcut(Slim::Utils::Misc::fileURLFromPath($curdir)) =~ /^file:/) { $curdir = pathFromWinShortcut(Slim::Utils::Misc::fileURLFromPath($curdir)); } else { $curdir =~ /^.*(?=[\/\\])/; $curdir=$&; } Hope my first if clause is correct as shown above - it should check if there is a "file:" at the beginning of the return value - if so everything is correct - if not the return value is a bad link and curdir should be the directory with the shortcut in it. Roland
pathFromWinShortcut returns a path, not a fileURL so you would never match /^file:/. why not just use fileURLFromPath without pathFromWinShortcut?
do you have an example of a bad link that could cause this? I suspect the proper way would be to test that a path exists and perhaps return undef if its not valid. Then we'll make sure to test that the path returned is defined before we act on it.
downgrading to normal severity since there seems to be no real-world case of this actually happening to anyone.
This doesn't seem to be a real problem.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.