Javascript (and other file) corruption

http://kb.blackboard.com/display/KB/Uploaded+files+get+corrupted+by+XSSUtil

Issue

Since installing Service Pack 4 for Blackboard release 8.0 (build 8.0.375.0), Hotfix 1 for release 7.3 Service Pack 2 (build 7.3.230.2), or Blackboard release 9.0, customers experience that files of many types cannot be successfully uploaded by students within courses, or by almost anyone to the Blackboard Content System. They become corrupted during the upload and can then not be successfully downloaded or will not open after download.

Symptoms

For content added within the course (Learning System), the issue generally does not affect files uploaded by instructors or system administrators. It only affects files uploaded by “untrusted” users (mainly students/members). In the Content System or on the portal, only administrative users remain unaffected by this problem. However, when uploading via WebDAV, even system administrators are getting their content filtered. Some non-text file types known to be affected by this issue include (this list is by no means comprehensive, and does not intend to be – many other types may be common at your institution but not in general use on the Internet, and Blackboard cannot be expected to know about all the files you want to use):

• .flv (Flash video)
• .isf (Inspiration schema)
• .pub (Microsoft Publisher)
• .wma (WindowsMedia Audio)
• and generally any filetype for which you previously had to manually add a MIME type to content/WEB-INF/web.xml to make them download ok

Close inspection of the uploaded files and comparison with the original files show that null bytes have been stripped out. Other changes may have been made to the files as well, e.g. by adding “disabled-” prefixes to certain strings. These files are essentially worthless and need to be re-uploaded after correcting the server’s configuration. For text file types, any script tags and other tags allowing external links or action handlers have been prefixed with the “disabled-” prefix, rendering them ineffective. This is particularly an issue in the Content System, as packaged content involving interactive scripting such as SCORM objects or Flash media fails to function when instructors upload it to the Content System (although it can be successfully uploaded by instructors/TAs/builders to the courses in the Learning System).

Cause

The cause of this issue is the newly implemented filtering of uploaded files to protect against cross-site scripting attacks. This is an eminently important new feature that strongly enhances the security of your Blackboard system and its users by preventing the uploading of files containing executable or malicious content in a form that permits direct execution in the browser, which would expose users to session theft, malicious data manipulation or deletion, identity manipulation, and other attacks. This filtering of content created by untrusted users has already been in place for several versions on content typed into Blackboard forms, but in 8.0SP4 filtering of uploaded files was also added. The problem is that to effectively protect the users, the filtering needs to err on the side of caution and thus applies whenever there is any doubt about the safety of the file or the trustworthiness of the user uploading it.

Analysis

XSSUtil is designed to filter uploaded files under the following conditions: the user is untrusted in the current context, and the file’s MIME type is considered dangerous or suspicious.

1. Context
   • Course context: the uploading user is trusted in this context if the user has the privilege to create content in the course (in other words he is not a student or guest, but an instructor, course builder, or teaching assistant).
   • System context (portal, admin panel): users are trusted if their system role has the assignable privilege to create trusted content or if they are the system administrator (who always has all privileges).
   • When uploading to the Content System there is normally no course role in the context, and thus everyone except those with system roles having the privilege to create trusted content is untrusted.
     • Exception: while adding a link into a course to a file stored in the Content Collection, such a file can also be uploaded right there. At this point, you have course context, and the instructor/TA/builder is thus trusted.
2. File type
   • Dangerous: MIME types known to be dangerous, because they will be displayed directly in the browser: text/css, text/html, text/javascript, text/plain. These filetypes are always being filtered, as configured in the internal configuration file. Disabling filtering of these filetypes is not recommended, you may rather want to turn off XSS file filtering completely if you need these file types to pass through unfiltered.
   • Suspicious: if the uploaded file is of an unknown MIME type, browsers (specifically IE) may still treat it as text file and display it. Thus unknown MIME types are filtered by default in 8.0SP4 and 9.0, but since this caused too many issues of files being unintentionally corrupted, in 8.0SP5 and 9.0SP1 they are not filtered by default. What is considered a “known” type is controlled by tomcat’s main configuration file, apps/tomcat/conf/web.xml – any file extension that has a MIME type listed there is “known”.
   • Harmless: file types may be explicitly marked as harmless in the internal configuration file config/internal/bb-file-filter-configuration.properties, thus ensuring that they will never be filtered.

Workaround

There are three approaches for working around this issue:

1. End users can upload problematic file types by zipping them up.
2. Sysadmins can disable file upload filtering entirely.
3. Sysadmins can add support for a list of file types in use at their institution to their system, so those no longer get mangled.

I did #2:

1. Goto the Administrator Panel
2. Click “Text Editor”
3. Uncheck Validate HTML Markup Whenever Users Submits Content
4. Submit

]]>