full-disclosure - Potential DoS in WinSyslog/MonitorWare Agent Interactive Syslog Server

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: rgerhards at hq.adiscon.com (Rainer Gerhards)
Subject: Potential DoS in WinSyslog/MonitorWare Agent Interactive Syslog
 Server

This is a vendor-bulletin.

There is a potential DoS in Interactive Syslog Server, a debugging and
interactive troubleshooting tool, included in WinSyslog  and MonitorWare
Agent. All versions downloaded prior to 2003-09-16 have the vulnerable
component included and installed by default.

Full details can be found at

http://www.adiscon.com/Common/en/advisory/2003-09-15.asp

The core issue is that received data was handed to a Microsoft Grid
Control without length check. The grid in turn experiences the the
performance issues that lead to DoS of the Interactive Server. It is
fixed by limiting the amount of data that is passed over.

We have learned that there is a not-fully-correct security advisory
available from Secunia:

    http://www.secunia.com/advisories/10004/

Please note that the solution proposed in the advisory does NOT work.
The solution is to download the fix. The proposed solution does not work
because (quotes from the advisory):

>Run the WinSyslog service and interactive syslog server on the same
>system and make sure that the interactive syslog server only binds to
>the localhost (127.0.0.1) interface.

WinSyslog Interactive Server can not be configured to listen to
127.0.0.1, only (looking at the menu options would have showed that ;-))
Besides that, it is good advise to use Interactive Server only on the
same system as the "real" syslog server.

>In infrastructures where the WinSyslog service and the interactive
>syslog server is required to be on two separate systems, they should be
>placed on their own network with a filtering device in front. This
>should only allow traffic to the syslog service on port 514/udp and
>services required for management purposes.

>From an architectural point of view, relying on an interactive,
non-automated process is bad design and brings up many more potential
security issues. There is no need to do this with WinSyslog, so don't do
it. If you use it that way, please contact support@...scon.com so that
we can help you migrating to a reliable logging infrastructure.

>NOTE: It is not sufficient to just filter traffic to port 10514/udp so
>only traffic from trusted IPs is accepted, since UDP traffic is easily
>spoofed.

Just a side note: This is true, but proper filtering would block the
spoofed traffic before it enters the internal network. We recommend this
measure in any case, because otherwise syslog data can be horribly
messed up.

Rainer Gerhards
Adiscon