bzchi Posted September 7, 2004 Share Posted September 7, 2004 (edited) Hi Nate, I have only recently come across this mod after a few colleagues asking for a way to fix the scaling issues with osCommerce. I commend you on the work you have done to step around the lack of control over images and I think this mod is a step in the right direction. I have tried to read this thread as thoroughly as possible but it is cluttered heavily with code pasting etc so if this has been covered I apologise. I have installed this patch and it worked as expected, but after reading the code more closely I found a potential point for a DoS attack against this script. I have reviewed the code and tested on 2 of my servers and confirm that the following may cause serious server exhaustion and disruption to services on the box. This ties in very closely to the 'generating on the fly' method that this script uses (please bare with me). Although the generation of thumbnails dynamically (at time of request) will cause extra server load this is not the key concern I have (I have ideas for solutions to problems and I am happy to help). ------ The following includes descriptions of the scripts workings, I appreciate you know how it works but I have detailed these background steps to provide clarity to the problem ------ The code in question resides in the product_thumb.php code that is used to generate the thumbnail on the fly. This code or 'page' is passed 2 critical variables from the main page (from user settings) these 2 variables being 'h' and 'w' (height and width obviously). When this page is called inline the product height and width is passed from the oSCommerce product listing page to the product_thumb.php page to generate the thumbnail. What does not seem to be taken into account is the fact that these variables are made available to the client for manipulation (ie. product_thumb.php does not collect the image settings itself, but assumes the passed information is correct). An example of this can be shown by calling the product_thumb.php generation page directly using. www.yoururl.com/catalog/product_thumb.php?img=images/myimage.jpg&w=100&h=75 This may not seem to be a problem (the thumb should generate as expected if the source image exists) but it becomes a problem when the input variables are manipulated because there is no bounds checking the size of the integer passed in for 'h' and 'w'. Take for example this request where w is replaced with an 'extremely large' number. www.yoururl.com/catalog/product_thumb.php?img=images/myimage.jpg&w=999999&h=75 This process will tie up GD for the maximum execution time specified in the PHP settings on the server. This will not only tie up webserver resources but may cause a DoS to other users accessing the page if your allocation of server resources are met. This was tested on both a dedicated and shared webserver resource with both consuming massive amounts of resources attempting to generate an image of this size (memory and CPU cycles). The solutions: 1. The quick temporary solution is to add bounds checking to the 'h' and 'w' variables to limit their size to a static integer, eg. 2048. An alternative would be to check the height / width passed to the product_thumb.php page, and if these values are larger than the original image exit without processing (this does not fix 'extremely small' numbers or fractions which may cause errors on the server). 2. Use static settings inside the product_thumb.php page so the end user at no point has access to the size of the thumb being generated. These could then be modified by administrators to set the image size once in the file (this may cause concern to administrators not confident to edit code). 3. Have product_thumb.php access the values from the osCommerce configuration directly so the 'small image size' is seamless to the user and the product_thumb.php is protected from this form of attack. 4. (desired) I think the best solution would be to generate the thumb and the 'large image' once off the original when the original is uploaded. This is no doubt more work but would be a better long term solution. This could possible incoporate writing the image directly into a DB for better control over images and less requests to filesysystem functions in scripts (always a good thing). These are my thoughts, I thought I would let you know about these in case they were not brought to your attention. If they have already been brought to your attention I apologise and I hope, if nothing else this message adds some clarity to the problem / concerns. Thanks, keep up the good work! -Sam (bzchi) Edited September 7, 2004 by bzchi Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.