Wednesday, October 19, 2005
2061 Connections mailing for September/October
The September/October 2005 issue of 2061 Connections was sent out Wednesday 19 October, 2005, at 2:51 PM EST to 3863 recipients.
Friday, October 14, 2005
Death of a Server
I've had to rearrange my workload to accommodate one of those things that happens at one time or another to everyone who uses a computer ... a crash. The web server suddenly kicked it the other night with no warning. Near as me and my trusty cohort (DP) can tell something went wrong with the hard drive. The error seemed to be with the controller initially (it kept complaining about the nvram), but placing the drive in a new machine has shown it to have faulty hardware. Unfortunately the drive, while on a raid controller, was not part of an array.
Luckily the web site has plenty of backups between the staging site, the development site, and the daily tape backup. We were able to load the files on a new server within minutes. Unfortunately, though the new server was going to eventually take over as the web server eventually, it hadn't yet been set up. DP and I spent a few hours getting the bare minimum running. I haven't had much time to create documentation for the site set-up so I'm having to do everything by memory. I've been able to remember most of the necessary settings, but I am having to do a bit of trouble-shooting at the same time. I'll need to spend some time writing up some documentation in the near future in case something like this happens again.
Luckily the web site has plenty of backups between the staging site, the development site, and the daily tape backup. We were able to load the files on a new server within minutes. Unfortunately, though the new server was going to eventually take over as the web server eventually, it hadn't yet been set up. DP and I spent a few hours getting the bare minimum running. I haven't had much time to create documentation for the site set-up so I'm having to do everything by memory. I've been able to remember most of the necessary settings, but I am having to do a bit of trouble-shooting at the same time. I'll need to spend some time writing up some documentation in the near future in case something like this happens again.
Wednesday, October 12, 2005
Site hack
Someone from IP 217.218.155.73 attempted to hack our site through some of the forms. Truth be told, I don't think the kiddies were truly attempting to hack the site. Based on evidence in the log files it looks more like they were trying to find code to exploit for the purpose of spamming. Still, without more investigation I can't say whether or not any real hacking attempts were made.
At any rate, the pages that were obviously toyed with were the search redirector (search.asp), the page survey (surveypage.asp), and the one-time notification page (notify.asp).
The search redirector does not really provide much of a vector for exploitation. It's main purpose is to redirect to the AAAS search and so there isn't much available for exploit. Some of the variables can be toyed with to crash the script, but that's about it at this point. I'm not too worried about it because the script won't crash unless the user makes an attempt to cause one.
The one-time notification does provide for a little more opportunity for exploitation since it connects to the MS SQL server. Most of the script is fairly benign, but an SQL INSERT is used. To mitigate any possible hack attempts I'm SQL encoding any user-supplied input. On the plus side, even if some malicious SQL code is run via the script the connection to the database is with a limited access SQL account.
The page survey proved to have a bit of a security oversight in the coding. Luckily the database used for that is MS Access, leaving fewer options for the kiddies. The page does access the database using a simple SELECT statement, however, which left the page open to possible hacks. I modified the statement so that user-supplied input is now SQL encoded.
While SQL encoding user-supplied input is a good start I'm not entirely certain that it prevent the database from being hacked. I'll need to do some research to see if there are any known problems when using the MS SQLEncode() function. Probably an even better strategy would be to plan on dropping direct SQL statement execution and move towards stored procedures or parameterized statements.
I'm going to check for any further hacking from the IP range associated with this probe.
Update 2005-10-13:
Upon further checks I didn't really find any other hack attempts of note. There were more of the same hack attempts from different IPs. We're likely listed in some kiddies search list. On the positive side, it pointed out some possible security lapses on those scripts mentioned.
At any rate, the pages that were obviously toyed with were the search redirector (search.asp), the page survey (surveypage.asp), and the one-time notification page (notify.asp).
The search redirector does not really provide much of a vector for exploitation. It's main purpose is to redirect to the AAAS search and so there isn't much available for exploit. Some of the variables can be toyed with to crash the script, but that's about it at this point. I'm not too worried about it because the script won't crash unless the user makes an attempt to cause one.
The one-time notification does provide for a little more opportunity for exploitation since it connects to the MS SQL server. Most of the script is fairly benign, but an SQL INSERT is used. To mitigate any possible hack attempts I'm SQL encoding any user-supplied input. On the plus side, even if some malicious SQL code is run via the script the connection to the database is with a limited access SQL account.
The page survey proved to have a bit of a security oversight in the coding. Luckily the database used for that is MS Access, leaving fewer options for the kiddies. The page does access the database using a simple SELECT statement, however, which left the page open to possible hacks. I modified the statement so that user-supplied input is now SQL encoded.
While SQL encoding user-supplied input is a good start I'm not entirely certain that it prevent the database from being hacked. I'll need to do some research to see if there are any known problems when using the MS SQLEncode() function. Probably an even better strategy would be to plan on dropping direct SQL statement execution and move towards stored procedures or parameterized statements.
I'm going to check for any further hacking from the IP range associated with this probe.
Update 2005-10-13:
Upon further checks I didn't really find any other hack attempts of note. There were more of the same hack attempts from different IPs. We're likely listed in some kiddies search list. On the positive side, it pointed out some possible security lapses on those scripts mentioned.
Webtrends irregularity
Webtrends crashed while running reports. Without some significant research I don't think I'll be able to determine the cause, so for now I'll just note the cause. The following two lines seem to be the source of the problem.
2005-09-07 19:42:49 202.147.177.70 - W3SVC12 PROJECT2061 198.151.218.130 80 GET /cgi-bin/404.asp 404;http://www.project2061.org/tools/benchol/ch2/ch2.htm 301 0 737 655 16 HTTP/1.0 www.project2061.org Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+{8EDEB5C2-2006-EB20-6F16-6A2EFD0A5822}) - http://www.google.com/search?q=uses+and+application+of+maths+in+every+day+life&hl=en&lr=&ie=UTF-8&start=30&sa=N
2005-09-07 20:14:52 202.147.177.70 - W3SVC12 PROJECT2061 198.151.218.130 80 GET /cgi-bin/404.asp 404;http://www.project2061.org/tools/benchol/ch2/ch2.htm 301 0 595 624 15 HTTP/1.0 www.project2061.org Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+{8EDEB5C2-2006-EB20-6F16-6A2EFD0A5822}) WEBTRENDS_ID=202.147.177.70-1418417440.29733860::8840CACE7014C0BFF54DA08DCA0E1F1B -
Update 2005-10-13:
Found some more lines causing a Webrends crash. More of the same, I suspect the cause may be the user agent string having the curly brackets {}. I didn't see it before because I was running on just the web content, so not all those lines were being loaded. I'm not going to bother noting the lines below; they're on the same IP and thus easy enough to find in the log.
2005-09-07 19:42:49 202.147.177.70 - W3SVC12 PROJECT2061 198.151.218.130 80 GET /cgi-bin/404.asp 404;http://www.project2061.org/tools/benchol/ch2/ch2.htm 301 0 737 655 16 HTTP/1.0 www.project2061.org Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+{8EDEB5C2-2006-EB20-6F16-6A2EFD0A5822}) - http://www.google.com/search?q=uses+and+application+of+maths+in+every+day+life&hl=en&lr=&ie=UTF-8&start=30&sa=N
2005-09-07 20:14:52 202.147.177.70 - W3SVC12 PROJECT2061 198.151.218.130 80 GET /cgi-bin/404.asp 404;http://www.project2061.org/tools/benchol/ch2/ch2.htm 301 0 595 624 15 HTTP/1.0 www.project2061.org Mozilla/4.0+(compatible;+MSIE+5.0;+Windows+98;+{8EDEB5C2-2006-EB20-6F16-6A2EFD0A5822}) WEBTRENDS_ID=202.147.177.70-1418417440.29733860::8840CACE7014C0BFF54DA08DCA0E1F1B -
Update 2005-10-13:
Found some more lines causing a Webrends crash. More of the same, I suspect the cause may be the user agent string having the curly brackets {}. I didn't see it before because I was running on just the web content, so not all those lines were being loaded. I'm not going to bother noting the lines below; they're on the same IP and thus easy enough to find in the log.
Thursday, October 06, 2005
IERI: Firefox update breaks movie playback
The new version of Firefox (currently 1.5 beta 2) has new security restrictions which prevent plugins from accessing files on the local system if the originating web page is on the Internet. This will be a big problem with IERI because the current setup requires that the movie file be local. I was able to confirm the problem by trying to view and control a movie through the utility then saving the page with the embedded movie locally and trying again.
Note: this is an existing problem with Safari. Considering the current trend in browser security I expect the other browsers will likely follow suite in the near future.
There are a couple of solutions we could consider:
This is probably the easiest solution to implement, but requires one of two things: a lot of money or a lot of time. Money if we were to purchase a certificate from one of the recognized authorities (such as VeriSign). A code signing certificate is expensive, even at the cheapest of providers, and has to renewed regularly. It is possible to obtain a free certificate from a provider such as CAcert, but it requires a more intense verification process whereby you actually meet with people to confirm your identity.
I know for certain that the problem can be addressed in Firefox by using signed code to modify a user setting when the movie plugin page is accessed:
References confirming access restrictions for local files:
This method, while probably not any less expensive than code signing, seems to be the best of the options. The main reason I say this is because it will require minimal rewriting of the utility and a minor investement in hardware infrustructure (for movie storage ... namely some large hard drives). If we really want to put some work into it we could also build a media management system on top of the storage system (something like the DAMS system at UMich).
EK seems to like this idea, so perhaps we'll investigate it a bit more.
The other two options presented are really viable. While it would provide a significant amount of flexibility in interface development, modifying mozilla to suite the needs of the utility seems a daunting prospect. And creating some kind of downloadable HTML core would likely cause more problems than is solves (mainly due to cross-site security restrictions).
No matter the solution we choose, this problem also present complications for the rewrite of the utility. The whole timecoding mechanism will need to be reworked so that this problem can be mitigated (I doubt we can avoid it completely). The rewrite may be the best time to implement one of the above options.
Note: this is an existing problem with Safari. Considering the current trend in browser security I expect the other browsers will likely follow suite in the near future.
There are a couple of solutions we could consider:
- Code signing
- Creating a custom application for the IERI utility
- Creating an IERI "application" that consists of local html files for the shell
- hosting the movie files on our servers and streaming them
This is probably the easiest solution to implement, but requires one of two things: a lot of money or a lot of time. Money if we were to purchase a certificate from one of the recognized authorities (such as VeriSign). A code signing certificate is expensive, even at the cheapest of providers, and has to renewed regularly. It is possible to obtain a free certificate from a provider such as CAcert, but it requires a more intense verification process whereby you actually meet with people to confirm your identity.
I know for certain that the problem can be addressed in Firefox by using signed code to modify a user setting when the movie plugin page is accessed:
try {
netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesWrite");
navigator.preference('security.checkloaduri', false);
navigator.preference('security.checkloaduri', true);
} catch (err) {
document.write("Sorry, you can not enjoy this site because of " +err+ ".");
}References confirming access restrictions for local files:
- [esqsoft.com] JavaScript Help: WINDOW Object
- [extensionsmirror.nl] pagePlaylist v0.7.1 for FX 1.5 Beta 1, Extension is broken.
- [jclement.ca] Firefox Weirdness
- [mozilla.org] Signed Scripts in Mozilla
- [mozilla.org] JavaScript Security in Mozilla
- [docs.sun.com] Netscape Certificate Management System Administrator's Guide: Appendix F Netscape Signing Tool
- [groups.google.com] script signing 2
- [devguru.com] JavaScript METHOD: navigator::preference
This method, while probably not any less expensive than code signing, seems to be the best of the options. The main reason I say this is because it will require minimal rewriting of the utility and a minor investement in hardware infrustructure (for movie storage ... namely some large hard drives). If we really want to put some work into it we could also build a media management system on top of the storage system (something like the DAMS system at UMich).
EK seems to like this idea, so perhaps we'll investigate it a bit more.
The other two options presented are really viable. While it would provide a significant amount of flexibility in interface development, modifying mozilla to suite the needs of the utility seems a daunting prospect. And creating some kind of downloadable HTML core would likely cause more problems than is solves (mainly due to cross-site security restrictions).
No matter the solution we choose, this problem also present complications for the rewrite of the utility. The whole timecoding mechanism will need to be reworked so that this problem can be mitigated (I doubt we can avoid it completely). The rewrite may be the best time to implement one of the above options.
Monday, October 03, 2005
JS Library: Active Menu & Multi-Column List
I've completed two more scripts for our code library.
Active Menu
Multi-Column List
Active Menu
Multi-Column List
Subscribe to:
Posts (Atom)