Security issues in the debugger infrastructure

What are the issues?

Read the architecture document if you are not familiar with the client-server architecture. In what follows we generally assume that both Opera and debugging clients connect to the proxy over TCP/IP, as this is the most general case. Exceptions will be noted. Particular attention should be paid to debugging enabled in the desktop client for developers. In this case the debugging client and Opera might be the same instance, sharing memory directly through a proxy abstraction layer.

There are several issues:

The purposes of an attack may be information theft (including industrial espionage, provided Opera is configured with support for "secret" debugging services, as will be the case while debugging Opera on phones), or impersonation.

If developer tools are included in an end-user product, end-user security concerns must be taken into account, in particular spoofing and phishing. Debugging has the potential to be even more powerful than userJS, so all the concerns about userJS also hold.

Fake proxy

Debugging is enabled and the proxy location is set in opera.ini, and the computer running the proxy may be remote from the one running Opera. Thus there are several attacks here.

Attacking opera.ini

Opera.ini can be attacked and modified by intruders or spyware, so that it connects to a proxy when the user didn't want it to, or to the wrong proxy.

We can do a few things to detect unauthorized modification of opera.ini.

For end-user products, the UI must show that the page is being monitored/controlled. This can be done in style similar to yellow drop-down bars at the top of the page. End-user products should probably have a pop-up dialog the first time (each session) this happens, similar to the pop-up we have for userJS on https. If Opera will have the ability to connect to other debugging clients than Opera itself, or to be controlled remotely, then the user should have the option of setting username and password for the connections. Authentication should be digest if over tcp/ip, and may last for the length of the session.

Fake proxy in correct location

The attacker can start a fake proxy at the location configured in opera.ini.

This requires either that the fake proxy starts listening on the host port before the real proxy does, or that the real proxy is killed and replaced with a fake proxy.

In the former case the user will normally detect the intrusion, because the server ports won't be available when the real proxy is started.

In the latter case it is less certain that the user who started the proxy will realize that it's been replaced. The proxy is intended to be reliable and to potentially stay up for a long time, so the user may start it and forget about it. A user who has authority to kill processes on the proxy host can therefore attack in this way.

One workaround is to make the proxy print out a random number when it starts and require that this number be entered into Opera so that it can pass it to the proxy in some form. This too is subject to attacks.

Diverting network traffic

The proxy may run on a remote system. Traffic must be intercepted and routed to the attacking host.

To combat this an authentication protocol may be used. For normal use this may not be necessary.

Listening to network traffic

Communication might happen over an insecure network. For example, mobiles that only work over WiFi, or an operator network. The debugger might send memory objects in plain text (for example wand passwords) that would normally only be sent with encryption.

We can encrypt data to and from the proxy as an option.

Middle man attack

The agents are fooled to believe it connects to the correct other agent, while it actually connects to another proxy. The connection would then be
Opera <--> Proxy <--> Proxy <--> Debugger
where one of the proxies would be controlled by a third party.

Methods and solutions are as above; faking the proxy, diverting network traffic and attacking opera.ini.

Attacking the proxy

In this attack a hostile client connects to a legitimate proxy.

It is possible to attack the proxy by impersonating as the host (Opera) too. This may be used to gain keys/passwords used by the client in setting up the connection, or data from clients running automated scripts that reveal information.

The most reasonable approach to counter this attack seems to be to implement various levels of access control:

Access control based on IP can be configured in an ini file (if that file is secure). A password can be requested on proxy startup or stored in a file like the CVS password (ditto).

A different approach would be to delegate all authentication to the host and the debugger, neither one sending information to the proxy before they are satisfied with each other. Or it would be possible to let the host and the debugger specify which IP ranges they accept connections from. Both of these approaches may be overkill.

Other Notes

The proxy must go through a QA process. Exploitable bugs can be used to gain unauthorized access to the proxy, bypassing other security restrictions.

End-user builds with debugging/proxy functionality must have it verified (in the security regression tests) that the functionality is turned off by default.

For internal/customer use, behind firewalls, security issues should normally be relatively small, unless unecrypted WiFi is used. This may often be the case for mobile projects, so users should be warned (in the documentation of the proxy).

Enabling these tools could potentially show a lot of the internal workings of Opera. Distribution should be limited, and not all tools can be released to all customers/users.