Skip to content ↓ | Skip to navigation ↓

In February 2015, the FBI seized control of computer servers running a child sexual abuse website called Playpen.

But rather than shutting down the site immediately, the FBI chose to continue to make the site available, planting software that could collect the real IP and MAC addresses of users.

On a regular website that might not be a hard thing to accomplish, but Playpen was running on the dark web – and its visitors were browsing the website using Tor, designed to keep their browsing behaviour secret and their identities anonymous.

As The Register reported last month, the FBI has refused to share details of precisely how it managed to infect computers with code that could track and unmask visitors to the paedophile website.

The FBI argues that sharing details of precisely how it exploited the computers of alleged visitors to the Playpen site – such as Seattle teacher Jay Michaud – is irrelevant, as “disclosure of the ‘exploit’ would do nothing to shed light on whether the government exceeded scope of the NIT warrant.”

“The exploit merely enabled the government to bypass the security protections on Michaud’s computer to deliver the NIT (Network Investigative Technique) instructions.”

Let’s not beat around the bush here. There’s a very good reason why the FBI might be uncomfortable sharing the exploit publicly – they’re worried that if it becomes public then it becomes worthless. Products will be patched, anti-virus software will be updated, and the FBI won’t be able to use their exploit anymore.

A judge decided, however, that the FBI must share the exploit with Michaud’s defence team, but not with any third-parties which might have the ability to fix the security hole.

I don’t know about you, but that leaves me worried. If there’s a security hole, then it can surely be exploited by more than the FBI? Couldn’t criminals and other nation states use it as well? Isn’t it better if a flaw that potentially puts privacy of Tor users at risk gets fixed?

That’s certainly the view of Mozilla, which has asked the court to order the FBI to reveal details of the flaw – as potentially millions of Firefox users could be at risk.

In a blog post, Mozilla’s Chief Legal and Business Officer, Denelle Dixon-Thayer, explains the concern:

“The Tor Browser is partially based on our Firefox browser code. Some have speculated, including members of the defense team, that the vulnerability might exist in the portion of the Firefox browser code relied on by the Tor Browser. At this point, no one (including us) outside the government knows what vulnerability was exploited and whether it resides in any of our code base.”

“The judge in this case ordered the government to disclose the vulnerability to the defense team but not to any of the entities that could actually fix the vulnerability. We don’t believe that this makes sense because it doesn’t allow the vulnerability to be fixed before it is more widely disclosed.”

“Court ordered disclosure of vulnerabilities should follow the best practice of advance disclosure that is standard in the security research community. In this instance, the judge should require the government to disclose the vulnerability to the affected technology companies first, so it can be patched quickly.”

As Help Net Security reports, Mozilla is requesting that if the defendants are to be shared with the defendant and if it does exploit a flaw in Mozilla’s code, then the court should also order the government to share details with Mozilla 14 days prior to the defence disclosure, giving enough time for the vulnerability to be evaluated and fixed.

I think Mozilla is right. Nobody wants to obstruct law enforcement in their investigations into alleged child abuse networks, but all law-abiding internet users need to feel confident that the software that they are using is safe, and not vulnerable to security holes that might be deliberately kept out of the hands of those best placed to fix them.


Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.