Tag Archives: security

System Administration

Executable blocking on Windows 2003

I was recently attempting to install PHP using an installer (MSI) I downloaded to my local workstation and copied to one of our servers. When I attempted to run the installer I received the following inscrutable warning:

Windows cannot access the specific device, path, or file. You may not have the appropriate permissions to access the item.

Thanks, Windows, that’s helpful. I had no idea what was happening, especially since I was logged in as an administrator with full control of the file.

As usual, the web was my friend in solving the problem. Windows 2003 Server has a security feature where executables copied from remote systems are blocked for execution unless allowed by an administrator. The feature appears to have been present for a while (since SP2?), but I don’t recall running into it before. As mentioned above, the file in my case was copied from my workstation over SMB; I don’t know if other transfer methods are also affected. I don’t have a problem with the feature, but I do have a problem with how it’s implemented. An indication in the pop-up of why the file could not be accessed would have resulted in a resolution of seconds not … er … minutes.

The resolution is simple enough, go into the properties for the file and you’ll see at the bottom a security warning and a button that allows you to unblock the file.

Click the “Unblock” button and you can execute the file as you normally would.

References:

PHP, System Administration

suhosin to [internal web app]: you talk too much

Following up on my earlier post, I’ve had to make some further configuration adjustments to avoid suhosin-related restrictions in one of our custom web applications. This particular application has a function that generates a summary of data from student assessments. The summaries can be generated based on groupings of packets and items. Depending on the filtering parameters selected there can be a fairly large number of packets and items. Not all of the packets necessarily contain the items of interest, but it’s always easier to select all if you want an overall summary of item performance.

I recently noticed the following alert in the system log:

ALERT – configured POST variable limit exceeded – dropped variable ‘included_packet_ids[]’ (attacker USER_IP_ADDRESS, file REPORT_FILTERING_PAGE)

One of the reasons I use POST variables on this page is to avoid the relatively small data size limit of GET. Suhosin adds additional limits, including in the number of times you can reference an individual variable.  Our limit was set at 1000, meaning there were over 1000 packets selected. This points to a need to adjust how the filter “selects all” … but for now I’ve adjusted the suhosin limit upward by modifying the suhosin.post.max_vars setting.

References:

PHP, System Administration, WordPress

suhosin to WordPress: go on a diet

1 Comment

We were seeing a lot of suhosin alerts in the system messages log of the type:

ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker SERVER_IP_ADDRESS, file WP_MAIN_ADMIN_PAGE, line 96)

The source of the issue is WordPress. The application is trying to raise the memory limit and suhosin won’t let it. Apparently WordPress will try to set a 256MB memory limit before executing certain functions. The necessity of adjusting this setting seems questionable to me, but I also understand that it’s often better to play it safe when developing software for public consumption.

I don’t particularly like applications attempting to specify their own resource usage in a web environment. In my mind applications should specify a required/recommended memory limit in the system requirements and stay away from adjusting this setting behind-the-scenes. Tell me during setup if the current setting may result in non-optimal performance or even a halt in script execution. That’s not how it’s done here, but really no harm is done in the long run beyond the annoyance of suhosin throwing errors at the system logs.

There are two easy fixes to the problem:

  1. Set the PHP memory limit to 256MB
  2. Modify the suhosin.memory_limit parameter to 256MB

In our particular situation it’s just as easy to set the PHP memory limit. There’s always a risk of overloading the physical resources, but this site receives little enough traffic that I’m not concerned about the right confluence of request occurring to cause a crash.

References:

ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value
Web Development

Internet Explorer blocks Firefox downloads

When designing the school reports I decided to use a GET request on form submission so that it would be easier to bookmark or share a report. I knew at the time that using GET might cause problems down the road, but the utility/programming trade-off seemed worthwhile.

Long URLs

The main problem with GET is that the total size a URL is allowed to be (and thus the amount of data passed) is fairly limited when compared to POST. The exact limit varies by browser and web server, but a practical limit is the lowest limit across platforms. In this case that is 2083 characters in Internet Explorer.

Since each report has to pass the list of included packets and items, the URL could easily surpass this limit. Recently one user generated a report that went over the IE limit. Figuring this out, though, proved to be somewhat difficult.

Held up at security

The user in question was using Firefox to access the utility. The report in question was generating and displaying just fine. However, when the user tried to download the report an error would result. It seemed odd that the browser would display the report on screen without issue then error out when attempting to download the same report.

I tried many options, but no matter what I did I was unable to download the report in Firefox. Next I tried the same report in IE and the situation started to clarify. IE would not even display the report. So now I was beginning to think that maybe the GET request was causing problems. Still it was difficult to fathom Firefox displaying the report on screen but refusing to download it.

A little web research finally clarified everything. Firefox attempts to honor the Windows Internet security zone settings for downloaded files. In order to apply the security zone settings Windows has to pass the URL to the IE engine for analysis. Firefox allows URLs of significantly larger size than IE, so the same URL that displays correctly on Firefox will thus cause IE to error out. Since Firefox attempts to honors the security settings, when IE coughs up a hairball due to the URL length the download is aborted.

Solving the problem

Initially I thought to just shorten the request by modifying the variable names on the form. This worked well enough for the problem at hand, but I could easily see having to address the problem again in the future. In the end I decided to modify the code behind the page so that the report parameters are submitted by POST instead of GET. It required more work up front, but will prevent this problem from cropping up in the future.

Plus, the utility has an option to save reports, so bookmarking/sharing is not as much of an issue.

References