Security

Jonny Robertson reported that Zebra can be remotely crashed if a Zebra password has been enabled and a remote attacker can connect to the Zebra telnet management port. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0795 to this issue.

Herbert Xu reported that Zebra can accept spoofed messages sent on the kernel netlink interface by other users on the local machine. This could lead to a local denial of service attack. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0858 to this issue.

• CAN-2003-0461: /proc/tty/driver/serial reveals the exact character counts for serial links. This could be used by a local attacker to infer password lengths and inter-keystroke timings during password entry.

• CAN-2003-0462: Paul Starzetz discovered a file read race condition existing in the execve() system call, which could cause a local crash.

• CAN-2003-0464: A recent change in the RPC code set the reuse flag on newly-created sockets. Olaf Kirch noticed that his could allow normal users to bind to UDP ports used for services such as nfsd.

• CAN-2003-0476: The execve system call in Linux 2.4.x records the file descriptor of the executable process in the file table of the calling process, allowing local users to gain read access to restricted file descriptors.

• CAN-2003-0501: The /proc filesystem in Linux allows local users to obtain sensitive information by opening various entries in /proc/self before executing a setuid program. This causes the program to fail to change the ownership and permissions of already opened entries.

• CAN-2003-0550: The STP protocol is known to have no security, which could allow attackers to alter the bridge topology. STP is now turned off by default.

• CAN-2003-0551: STP input processing was lax in its length checking, which could lead to a denial of service.

• CAN-2003-0552: Jerry Kreuscher discovered that the Forwarding table could be spoofed by sending forged packets with bogus source addresses the same as the local host.

Another buffer overflow in Apache 2.0.47 and earlier in mod_cgid's mishandling of CGI redirect paths could result in CGI output going to the wrong client when a threaded MPM is used. CAN-2003-0789.

The BIND 4 and BIND 8.2.x stub resolver libraries, and other libraries such as glibc 2.2.5 and earlier, libc, and libresolv, uses the maximum buffer size instead of the actual size when processing a DNS response, which causes the stub resolvers to read past the actual boundary ("read buffer overflow"), allowing remote attackers to cause a denial of service (crash).

GtkHTML supplied with versions of Evolution prior to 1.2.4 contain a bug when handling HTML messages. Alan Cox discovered that certain malformed messages could cause the Evolution mail component to crash.

• CAN-2003-0690: Privilege escalation with specific PAM modules. The XDM display manager that ships with XFree86 prior to 4.3 is also vulnerable.
• CAN-2003-0692: Session cookies generated by KDM are potentially insecure

The uml_net utility in kernel-utils packages with Red Hat Linux 8.0 was incorrectly shipped setuid root. This could allow local users to control certain network interfaces, add and remove arp entries and routes, and put interfaces in and out of promiscuous mode.

All users of the kernel-utils package should update to these packages that contain a version of uml_net that is not setuid root.

Alternatively, as a work-around to this vulnerability issue the following command as root:

chmod -s /usr/bin/uml_net

It has been conjectured that excessive data passed to the involved to_ascii_xxx() functions may overrun the bounds of an insufficient buffer reserved in heap memory, resulting in the corruption of heap based memory management structures that are adjacent to it. It is currently believed that under the correct circumstances an attacker may use this to execute arbitrary instructions in the context of the PostgreSQL server.

The Common Vulnerabilities and Exposures (CVE) project assigned the id CAN-2003-0901 to the problem.

You are only vulnerable if you actually run saned e.g. in xinetd or inetd. If the entries in the configuration file of xinetd or inetd respectively are commented out or do not exist, you are safe.

Try "telnet localhost 6566" on the server that may run saned. If you get "connection refused" saned is not running and you are safe.

The Common Vulnerabilities and Exposures project identifies the following problems:

• CAN-2003-0773: saned checks the identity (IP address) of the remote host only after the first communication took place (SANE_NET_INIT). So everyone can send that RPC, even if the remote host is not allowed to scan (not listed in saned.conf).
• CAN-2003-0774: saned lacks error checking nearly everywhere in the code. So connection drops are detected very late. If the drop of the connection isn't detected, the access to the internal wire buffer leaves the limits of the allocated memory. So random memory "after" the wire buffer is read which will be followed by a segmentation fault.
• CAN-2003-0775: If saned expects strings, it mallocs the memory necessary to store the complete string after it receives the size of the string. If the connection was dropped before transmitting the size, malloc will reserve an arbitrary size of memory. Depending on that size and the amount of memory available either malloc fails (->saned quits nicely) or a huge amount of memory is allocated. Swapping and OOM measures may occur depending on the kernel.
• CAN-2003-0776: saned doesn't check the validity of the RPC numbers it gets before getting the parameters.
• CAN-2003-0777: If debug messages are enabled and a connection is dropped, non-null-terminated strings may be printed and segmentation faults may occur.
• CAN-2003-0778: It's possible to allocate an arbitrary amount of memory on the server running saned even if the connection isn't dropped. At the moment this can not easily be fixed according to the author. Better limit the total amount of memory saned may use (ulimit).

When configured to listen for incoming connections (instead of being invoked by xinetd), stunnel can be configured to either start a thread or a child process to handle each new connection. If Stunnel is configured to start a new child process to handle each connection, it will receive a SIGCHLD signal when that child exits.

Stunnel versions prior to 4.04 would perform tasks in the SIGCHLD signal handler which, if interrupted by another SIGCHLD signal, could be unsafe. This could lead to a denial of service.

Because of a programming error, memory was allocated and never freed if a connection was refused for any reason. An attacker could exploit this flaw to crash the xinetd server, rendering all services it controls unavailable.

In addition, other flaws in xinetd could cause incorrect operation in certain unusual server configurations.

All users of xinetd are advised to update to xinetd-2.3.11 which is not vulnerable to these issues.