The closest to being in control we’ll ever be is in that moment when we realize we’re not. – Brian Kessler

“Control less, trust more” should be the mantra everywhere, and especially in education, but it seems like people love to control every aspect of each others’ lives, to the point where it’s just pointless and creepy.

One such example is Respondus’s LockDown Browser. I know that the post title says CollegeBoard, so let me explain. Respondus develops the LockDown Browser and licenses it out to OEMs. Some product manager over at CollegeBoard probably saw the tech white-paper from Respondus and decided to adopt it for CollegeBoard’s online AP courses.

That would be perfectly dandy and fine, except for the fact that Respondus’s software is a flaming pile of garbage.

Adobe Flash and security

Take the installer, for example. On installation, LockDown Browser installs an outdated version of Adobe Flash Player – specifically version 32.0.0.207 (as of March 12th, 2020). This version is susceptible to the vulnerability CVE-2019-8075, allowing attackers to steal data. Not exactly a critical vulnerability since it doesn’t allow for privilege escalation, but LockDown Browser is already off to a bad start in my books. You never, ever install dependencies, like Java or Flash, alongside your software. Instead, you ask the user if he or she wishes to install dependencies. -1.

Not to mention Adobe Flash Player has already been deprecated. It’s 2020, and Respondus is still clinging onto an old platform, because developing a new solution costs money and companies try to save a dime wherever possible, at the cost of users’ – in this case, students – experience and safety.

Speaking of safety, LockDown Browser grants itself full access of your webcam, whenever and wherever. That means if somebody found a vulnerability in LockDown Browser, they could theoretically look into students’ private lives if the vulnerability is successfully exploited. Not good at all!

How do I know all this? You need to deconstruct the installer.

Deconstructing the installer

This is fairly easy -– any novice Linux user can follow along and finish in under 20 minutes. For reference, I’ll be using the Mac version of LockDown Browser found on CollegeBoard’s website (you may need to be signed into AP Classroom in order to download the file).

Undoing the archive, we see a single package file. But Respondus decided to be sneaky and disabled the “Show Package Contents” option. What should we do?

missing-show-package-contents

Fortunately, “The Unarchiver” from the Mac App Store solves this problem easily. Simply install the app, and then click on “Open With > The Unarchiver”. After a few seconds, out pops a folder:

lockdown-browser-installer-package-contents

We ignore everything but the lockdownbrowser.pkg file, since that is the biggest file in this directory. Fortunately, this time they didn’t think to disable the “Show Package Contents” option. We burrow deeper.

lockdown-browser-package-contents

The Bom file is macOS’s standard bill-of-materials file. It shows exactly what the package installer will install to your computer. We don’t need that, since we don’t see the files themselves, only the filenames. We don’t need PackageInfo either, even though it does look promising. We’ll come back to that later. Let’s see what this Payload file is.

But Eric, you say. The file doesn’t have an extension. We’re screwed!

Every file has a magic number, or file signature. If we open up the file in a hex editor, the first few bytes will contain unique information about what type of file it is. That is called the “magic number.” For example, these are the first few bytes of a typical .zip file are 50 4B 03 04. It may be different depending on what type of archive it is, but basically all files are like this, unless they are encrypted files. You can check the full list here.

So what file is this? We can hex edit this, but I’m lazy. I’ll just use the standard file command:

➜  lockdownbrowser.pkg > file Payload
Payload: gzip compressed data, from Unix, original size modulo 2^32 179979776 gzip compressed data, unknown method, ASCII, has CRC, extra field, has comment, encrypted, from FAT filesystem (MS-DOS, OS/2, NT), original size modulo 2^32 179979776
➜  lockdownbrowser.pkg >

Hmm.. interesting. It’s an “encrypted” gunzip file. I wonder if the tar utility can extract it…

➜  lockdownbrowser.pkg > tar -xzvf Payload
x .
x ./LockDown Browser OEM.app
// --------------------------------
// Output truncated for readability
// --------------------------------
➜  lockdownbrowser.pkg >

So yeah, tar can unpack the archive. Guess it wasn’t “encrypted” after all.

The Payload archive in fact contains one app: “LockDown Browser OEM.app”. That’s it. Let’s take a peek inside. One “Show Package Contents” later, I noticed that LockDown Browser used something that looked suspiciously familiar… Can you guess what it is from this screenshot?

lockdown-browser-oem-app-package-contents

Yup. LockDown Browser uses the Chromium Embedded Framework (CEF), just like your desktop Spotify app.

“Native” app

The Chromium Embedded Framework (CEF) is sort of like Electron, and allows developers to write desktop apps in web technologies (*shudder*). Now normally this wouldn’t be a surprise, except for the fact that Chromium already includes Adobe Flash Player. So what’s going on?

Well, one guess I have is that the version of Adobe Flash Player inside CEF is severely hobbled, to the point where not using it is the better option. Because Flash is easy to exploit by hackers and is prone to crashing the entire computer, the developers over at Google probably removed a bunch of functions/implementations that Flash Player has to the system with stubs that do nothing, limiting security vulnerabilities but at the same time hobbling it’s feature-set. But instead of opting for the sane method, the developers over at Respondus decided to force installation of the regular PPAPI Adobe Flash Player so that they could have more access over the computer. This is a guess, so I’m not completely sure, but it explains why Respondus requires two versions of Adobe Flash Player installed at the same time.

More security nightmare

Let’s go back. Remember how I said LockDown Browser has consistent access to your webcam? Well, if you look at the config.xml file, you see that LockDown Browser declares the use of the webcam:

lockdown-browser-config-webcam

Once the user grants access, LockDown Browser has complete control to turn on your microphone and webcam at any time. Yikes.

Of course, I would not point this out on most applications, because most applications are written properly in proper languages and do not rely on old software like Adobe Flash. But since LockDown Browser does, I am being extremely cautious. Even if Respondus doesn’t have any bits of code that send back images and video to their servers, a 3rd party could easily gain access to the application through the vulnerabilities I highlighted above.

And it gets worse. The app contains an “update helper”:

lockdown-browser-update-helper

However, before we go stage a complete riot against Respondus, it could be used for non-nefarious purposes – like updating the app on every launch. But since it’s a closed-source module, we don’t know this. How do you know the helper is not constantly open in the background, downloading commands from Respondus’s servers? You don’t. Another creepy thing to add to the checklist. I wonder when this will end.

How do you know if it installs Adobe Flash Player if you haven’t installed it? Glad you asked. Time to unpack the Scripts archive:

➜  lockdownbrowser.pkg > tar -xzvf Scripts
x .
x ./._.DS_Store
x ./Adobe Flash Player.pkg
// --------------------------------
// Output truncated for readability
// --------------------------------

➜  lockdownbrowser.pkg >

Hah! The guy who packaged the LockDown Browser was probably also using a Mac and in a hurry. We see the .DS_Store file and Adobe Flash Player package, and if you dive into it eventually you’ll find the version code string. But that’s not relevant anymore since I pointed it out above.

So even from installation, there are multiple sirens going off in my head. But the software has to be good, right?

Nope.

Actually using the damn thing is hard from the start

So I got creeped out by LockDown Browser’s extensive list of permissions and decided to install it in a virtual machine. Surprise, surprise – it detected that it was in a virtual machine and shut down. Guess I need to install it on bare metal. So I just installed it on my Mac and covered up my webcam with a Post-It. (Don’t worry – the assessment I took did not require webcams.)

Once you enter an online AP examination on CollegeBoard’s website, LockDown Browser launches. So far, so good, right? It full-screens the test and only allows you to interact with the test.

Wait… what? I understand that you don’t want to let students cheat. But full screening the app and blocking off access to the menu bar or volume control? Why? (At the end of this post I’ll show you why this doesn’t even matter.) Not to mention that something is horribly wonky with the application, so it shows you a really small version of the test that takes up one-quarter of your screen. What?

Okay, okay, but I need to finish this assessment. Let’s just finish it quickly and resume what I was doing. I finished the assessment and LockDown Browser closed.

Revealing my desktop.

Wait. Where are all my programs? Why the fuck did you just close all of my programs? Where is my IDE? Where is my study material I had open? What about the Word document I didn’t save yet? Everything was fucking gone. LockDown Browser had quit all processes – including the BetterTouchTool utility I use – even though I would have no access to these applications because the browser full-screened itself.

Why? Who thought this was a good idea? You don’t close my shit down without asking. That’s rude and that interrupts my workflow. I got so pissed by this. At least show me a fucking warning dialog that you’re about to close all my programs and to save my work!

If all this made you decide to remove LockDown Browser, you’d be shocked to hear that you can’t uninstall it fully – at least not in the conventional way. According to the support article from Respondus, the uninstallation process is very complicated and apparently very finicky – in one instance, they recommend reinstalling LockDown Browser before trying to uninstall it. Huh?

The situation doesn’t even get better for Mac users. They just recommend deleting the .app file, which won’t clear up all the junk that the installer left behind. Fortunately, I’ve found AppCleaner to do a sufficient job at cleaning things up – mostly, if not all the way. For those of you who do not wish to download a 3rd-party app to uninstall apps, here is a script to remove all of the junk that LockDown Browser leaves behind:

#!/bin/bash

sudo rm -rf \
"/Applications/LockDown Browser OEM.app" \
"~/Library/Application Support/LockDown Browser OEM" \
"~/Library/Caches/com.Respondus.LockDownBrowserOEM" \
"~/Library/Preferences/com.Respondus.LDBCEFHelper.plist" \
"~/Library/Preferences/com.Respondus.LockDownBrowserOEM.plist" \
"/var/db/receipts/com.Respondus.LockDownBrowserOEM.pkg.bom" \
"/var/db/receipts/com.Respondus.LockDownBrowserOEM.pkg.plist"

But, at the end of the day, it seems like all that engineering effort by Respondus’s team was wasted. During the assessment, my phone next to my laptop rang with the Microsoft Teams notification sound. It was my science class asking me where I was.

Secure assessments, my ass.

If I had been a cheater I could’ve used my phone right then or there. Or used a spare laptop alongside my test-taking laptop. This also leads to a horrible aspect that CollegeBoard or Respondus probably didn’t consider – students with access to more resources and devices have a potential advantage over those who don’t. Really leads you to wonder exactly what CollegeBoard is protecting with this program.

Administering security-theater tests

So what’s the solution? What can Respondus and CollegeBoard tweak?

Well, for starters, I would remove most parts of the program. No restrictions whatsoever. No checking to see if we’re running on virtual machines. No closing down applications. No installing Flash Player. No installing a separate program just to take the test. In fact, the test should function exactly like a web page – independent of operating system and platform and conforming completely to web standards.

“That lowers the barrier to cheat!” You say. “You haven’t improved anything at all.”

Yes, you can argue that. But cheaters will always find a way to cheat, regardless of what restrictions there are. If you make something fool-proof, the world just creates a better fool. It’s the same model screamed by millions of IT professionals – anything on the web can and will get breached. It’s not a question of if, but a question of when. And when a situation occurs where that individual can’t cheat, they will have played themselves.

But enough of that philosophical talk. What are the benefits of moving to a non-secure-secure-testing model?

Well, it opens the floodgates to more students. Think about kids that couldn’t afford an x86-platform machine. Kids that have dinky Android tablets or iPads. LockDown Browser will never work correctly on these. Think about kids that exclusively study on iPads. Even if they could afford an x86-based machine, it would be a huge cost-saving measure to let them take tests wherever they like.

Couple that with no security vulnerabilities, and the benefits just outweigh the downsides, if any exist in the first place (like I said above, cheaters are cheaters). Conclusion

Thanks for reading this far. If you’re a high school student like me and are tired of the LockDown Browser shenanigans, please share this post on social media and try and tag CollegeBoard and Respondus’s teams. Maybe we can get them to change their practices and help make a better online education platform for everybody.

Update - after taking the AP exams

My friends and I were a bit afraid that CollegeBoard would force the use of LockDown Browser during the AP exams, but it turned out to be a simple webpage, devoid of any anti-cheat mechanisms. I don’t know if anybody at CollegeBoard read my blog, but it seems like they realized the limitations of a program such as LockDown Browser.

And they were right to not use LockDown Browser. By not doing so, they:

  • allowed students with non-x86 instruction-set devices to participate in the AP exams. This is really significant, because people without access to a proper x86/x86_64 computer ended up submitting on whatever device they had, be it an iPhone or an Android tablet or even an Xbox (!) (although they did receive the “unsupported browser” warning and their exam was canceled). More students had the chance to prove their knowledge, and I’m glad CollegeBoard let them.
  • prevented any additional security holes from installing such a program.
  • prevented bugs arising from such an anti-cheat program itself. Some of my friends, while completing the AP practice exam questions on CollegeBoard’s website, reported that LockDown Browser frequently crashed, didn’t send their responses to the server, or ended up hanging indefinitely while the timer still ran. If that happened on the actual AP exam, CollegeBoard would have been sued ten times over. (To be fair, they still did get sued because their servers went down on the actual AP exam dates.)

In addition, CollegeBoard used a timed approach, while allowing students to consult their notes. By doing so, they tested extensive knowledge of the material while preventing cheating by setting a time limit, so that students didn’t have enough time to cheat on the Internet and formulate a response.

I’m happy that CollegeBoard decided to use open web standards to administer the AP exams, and hope that they will continue to push for open standards in the future.