CWE-134: Uncontrolled Format String - CVE-2015-2894

For version 6.0 and 7.2, an unauthenticated attacker on the network may send either the "%n" or "%s" format parameters will cause the application to crash.

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - CVE-2015-2895

For version 7.4, an unauthenticated attacker on the network sending commands with an input that is larger than 1024 bytes will crash the application. Remote code execution is likely but currently unproven.

CWE-200: Information Exposure - CVE-2015-2896

For versions 7.6 and prior, an unauthenticated attacker on the network may send built-in commands to the port that the Up.time agent is using. These commands are not authenticated, and therefore the attacker can learn information such as the version of Up.time running, details about the underlying operating system running Up.time, details about other running processes on the system, and Windows operating system event log information.

A remote unauthenticated user may be able to perform a denial of service on Up.time, or obtain system information for future use. It may also be possible to execute code.

Apply an update

Idera has released Up.time version 7.6 which addresses CVE-2015-2894 and CVE-2015-2895. Affected users are encouraged to update as soon as possible.

The remaining issue, CVE-2015-2896, will be fully addressed in a future release but may be mitigated with the following actions:

Check configuration

According to Idera, affected users may also use the following configuration settings to mitigate these issues:

1. All agents run in a read only mode by default, where they can only poll metrics.
2. In order to use custom scripts or trigger recovery actions, you need to set a password on the agent, or add commands to the .uptmpasswd file for the linux agent.
3. Agents communication can be encrypted with SSL by using various SSL Tunneling/Proxy Utilities (openSSL, etc). KB articles cover the specifics for implementing with Stunnel on various platforms.
4. Agents running under xinet.d can also be secured at the service level by restricting incoming connections to only accept connections from the Monitoring Station, or limit the total number of connections, etc.
5. Disable Agent Commands you don't use either via the Agent Console or editing conf/agent_commands.txt.