Respondus LockDown Browser: Ineffective, Dangerous, and Obsolete
A few months ago I enrolled in a class that required the use of Respondus Lockdown browser; a piece of software that is difficult to install, unforgiving of system incompatibilities, doesn't work on FOSS operating systems and encourages users to open themselves to large vectors of attack.
Potential Dangers
The most basic danger to a program such as this, is that it may crash. When LockDown browser crashes while being used, it invalidates the test being taken and also leaves the student in a desktop with no task manager/switcher, no way to spawn another process, and no way to get back to any work they were doing previously to running the software, this means that they must hard re-boot the machine, which can be quite messy on NTFS file system and corrupt the machine if done at a bad time. This is one of the most common complaints on-line about the software.As with all software, the LockDown browser may become infected or be run on an infected machine. Respondus uses may windows libraries that are also used by viruses due to their similar nature. Once access is granted to Respondus, any virus tagging on to the file will also get those permissions. For this reason Respondus suggests that you run an anti-virus software to mitigate such risks, but AV softwares are only as good as their updates, and it may take some time for an update to be released, especially for common 0-day exploits.
Being that Respondus uses Safari and Internet Explorer libraries for browsing the web rather than using a secure, open source, sand-boxed rendering engine such as Presto as a library it forces students to use historically insecure software.
Browser | Rendering Engine | CVEs Mentioning 10/2008 – 10/2011 | Mean Time To Patchi (days) | Vendor |
| Opera | Presto | 139ii | 117 | Opera |
| Safari | WebKit | 254iii | 647 | Apple |
| Internet Explorer | Trident | 236iv | 1270 | Microsoft |
| Firefox | Gecko | 366v | 334 | Firefox |
Significant Overlooks in Design
Along with being potentially dangerous, LockDown Browser contains a rather poor mechanism for stopping potentially unwanted third party programs from being run on a machine. It uses what is commonly called a blacklist, meaning that it looks for and kills programs that are on a preset list, hard coded in to the application. This means that when a user attempts to run the browser while running blacklisted programs, those programs will be stopped. LockDown also has a way to stop many programs that are not in the blacklist, most likely by looking at the libraries loaded by the other files to see if they include anything not allowed. All of these can, of course, be changed through on-line sources to allow universities (or third parties, such as firewalls between the browser and the server or rootkits) to change the rules.Even if Respondus were to have perfect blacklisting, which is impossible as new applications are developed every day, there are certain services that Respondus may not kill, like those required for Blackboard to run properly i.e. Java, and/or Flash. If any kind of subversive application were to be written in either of these (several Java screen sharing apps can be found for free on SourceForge.net) it would not be killed allowing students to bypass any wanted security restrictions.
There is, actually a much easier way to get LockDown browser to ignore the starting of an application all it took was a few moments thought: starting the application after LockDown begins. This is a simple trick, and nearly impossible to block as any process could spawn any application at any time, this is expected in any modern operating system. The following code took about thirty seconds to put together, and defeats the no remote desktop part of Respondus, which keeps the test taker from doing everythingthe software claims to prevent. By installing TightVNC and running this script then running LockDown browser all security measures are circumvented:
- ping -n 30 127.0.0.1 > nul
- “C:\Program Files\TightVNC\tvnserver.exe” -start
Ineffectiveness
Client side security doesn't work, because clients say whatever their owners tell them, and a server's only way of questioning the client depends on secret keys embeded in software; the problem is that the software can't keep secrets being that it needs the same keys to encrypt or decrypt messages. The whole model rests on the hope that the user isn't smart enough to discover the keys. The things that must be kept in mind while implementing the browser at a university are a) students are smart, otherwise they wouldn't have been offered positions in the university, b) compared to the LockDown browser developers, students have near infinite resources and time, and c) there are lots of reasons to crack the browser, especially when such an emphasis is placed on obtaining an education while there are few reasons to patch the browser until someone actually notices students cracking it.There are already several “cracks” of the browser on-line, some of which change the Blacklist, others which turn off Virtual Machine checking, and still others which entirely disable the security mechanisms by removing references to Windows Libraries.
If the purpose of the browser was to take tests in-class, it would be more effective to provide access to secure machines for the students to use, that way firewall rules could be fully enforced and the machines could be ensured to be entirely secure. However, if the purpose was to aid in test-taking at home, there are far easier ways to get around the security restrictions than in class, such as using a smartphone, another computer, a tablet, or even printed notes or a textbook. A far better solution would be providing time limits to those taking the test.
Future Compatibility
The LockDown Browser also has problem of future compatibility. As tablets become more and more prevalent students won't find a reason to purchase a bulky, expensive laptop; the LockDown browser won't work on any tablet operating system due to the inherent sand-boxing and security built in against “malicious” applications that make the systems do anything other than what they were designed to do, such as disabling application switchers like Respondus does on the desktop.Incompatibilities even exist within the University of Denver's own campus hardware. None of the computers in the UTS lab adjoining the library will run the browser, due to the fact that they are virtual machines running on thin-clients. These clients are substantially easer to maintain, upgrade, are far cheaper, both in hardware and maintenance; and more secure than traditional desktops.
As of Windows 8, set to be released this year, Microsoft is deprecating the Win32 API which LockDown browser requires to run. It is even reported that the traditional desktop will not be allowed to be installed on RISC platforms which will account for an increasing market share of laptops in the coming years due to the lower power consumption of the processors and thus longer battery lives and popularity. The traditional Desktop environment will even be an optional component in new installs; meaning that there will be no way to lock down the system as software becomes increasingly sandboxed and secure. From personal experience, the browser is highly unstable on Windows 8, even with the Desktop environment and Win32 installed.
iWeb Browser Security Summary http://www.webdevout.net/browser-security Updated Feb 10, 2009
iiDownload CVE's From http://cve.mitre.org/data/downloads/ performed a grep -v Operation | grep “Opera “ and counted the number between Oct 2008 and Oct 2011
iiiDownload CVE's From http://cve.mitre.org/data/downloads/ performed a grep “Safari “ and counted the number between Oct 2008 and Oct 2011
ivDownload CVE's From http://cve.mitre.org/data/downloads/ performed a grep “Internet Explorer “ and counted the number between Oct 2008 and Oct 2011
vDownload CVE's From http://cve.mitre.org/data/downloads/ performed a grep “Firefox “ and counted the number between Oct 2008 and Oct 2011
