NTOP is a network usage monitoring tool for unix systems. It can be invoked at the console or as a server daemon, presenting statistics information via http with the -w parameter. In this mode, it is vulnerable to a buffer overflow before the user connecting to it can be authenticated. If exploited, an attacker can gain remote access to the system with the priviliges ntop is executing with. It is interesting to note that setuid ntop drops priviliges before this can be exploited, but is installed on *BSD systems only executable by members of group wheel. This leads to the assumption that it may often be executed as root (since users in wheel typically have root access..), so despite the fact that it drops priviliges it can still yield remote root access for the attacker if exploited when run as root.
Certain versions of the software shipped to configure the Raptor GFX cards are vulnerable to an PATH environment variable attack due to insecure code within pgxconfig the main configuration utility. In particular the pgxconfig uses an insecure system call (system(3s). This function effectively executes binaries resident on the system from within the program. Given that this call must execute binaries on the system at hand it relies on the $PATH variable to tell it where the system binaries reside. This variable is configurable by the user, and therefore a user can provide there own binary to be executed. In this particular case because the program also issues a setuid(0) call (a call which set's the UID of the process in this case, root) the program which the user substitutes is executed as root.
A vulnerability exists in version 1.4.2 and prior of the AnswerBook2 server from Sun. It is possible for remote users who have administrative access to execute arbitrary commands on the machine running AnswerBook2. These commands will be executed with the privileges of user 'daemon'. An attacker could specify a destination log like 'x ; uname -a' that will translate to 'sh -c "cp /var/log/ab2/logs/original_log /var/log/abs/logs/x ; uname -a"'
Aptis Software offers a billing / provisioning solution for ISPs called TotalBill. One component of the TotalBill package is a network service called Sysgen that listens on or around port 9998. It allows a client connecting to it to execute any command on the host it is running on (with whatever uid the service runs as, typically root) without any authentication. If this service is not filtered, anonymous attackers can easily gain root access on the target host by remotely exploiting this naive service.
A lack of authentication checks for certain scripts within the administration interface of AnswerBook2 versions 1.4.2 and prior, for Solaris, allows remote users to create administration accounts. By directly accessing the /cgi-bin/admin/admin script present under the AnswerBook2 dwhttpd web server, it is possible to add users to the administration interface. This will allow the attacker to read log files and manage content.
ntop is a tool that shows the network usage, similar to what the popular top Unix command does. Starting ntop in web mode (with the -w parameter) starts ntop with it's own built in HTTP server, to allow remote access to the functions it provides. ntop does not properly authenticate requests and is vulnerable to a ../../ request whereby unauthorized files can be retrieved, including files which are only readable by root. The default directory ntop serves HTML from is /etc/ntop/html so to retrieve /etc/shadow one can request the following URL: http://URL:port/../../shadow
A malicious user can create a file with an escape sequence and commands embedded in the file name, then execute suidperl in such a way that the security check fails. suidperl will send a message to root via /bin/mail with the escape sequence embedded in the message. This will cause /bin/mail to start a root shell and execute the commands.
A flaw in Netscape Communicator's implementation of Java allows malicious applets to read any resource reachable via a URL from the local machine by using the netscape.net.URLConnection and netscape.net.URLInputSteam classes. This allows malicious applets to read local files as well as download data from hosts that would otherwise could be protected by a firewall. An untrusted applet normally is no allowed to read or write to the local file system, or to open network connections to any machine other than that from which it was downloaded. Netscape's netscape.net.URLConnection and netscape.net.URLInputStream classes seem to ignore or not perform these checks when passed an URLs. Thus malicious classes and read local files using URLs of the type “file://”. If the machine running the malicious applet is behind a firewall it will also be able to download resources that can be accessed via a URL, such as web server (“http://” or “https://”) or FTP servers (“ftp://”), that the attacker in control of the machine from which the applet was downloaded could not. In this way a malicious applet could be used to penetrate a firewall.
A set of flaws in multiple vendors' Java implementation allows a malicious applet to open a listening socket to accept network connections against the security policy. Java applications use the java.net.ServerSocket class to create a listening network socket on which to accept network connections. The server socket class should use the SecurityManager.checkListen() method to determine whether a class is allowed to create a server side listening socket. A SecurityException should be thrown if the class is not allowed to create such socket. By default untrusted classes such as applets should not be allowed to create such sockets. The implementation of Java fails to throw a SecurityException when an applet create a ServerSocket. After a ServerSocket object has been created an application must accept network connections by called the ServerSocket.accept() method or by subclassing the ServerSocket class an using the ServerSocket.implAccept() method of ServerSocket to implement their own accept method. The ServerSocket.accept() method normally calls the SecurityManager.checkAccept() method to determine if a class can accept a server connection. The ServerSocket.accept() and the ServerSocket.implAccept() methods both accept the network connection before determining if the class can accept the connection. This is done to determine the remote address and remote port number of the connection. If the connection should not be accepted these methods shutdown the connection by calling the socket's Socket.close() method, and then throwing a SecurityException. Because the ServerSocket.implAccept() method takes as an argument a Socket object to use for the connection a malicious class can pass it an object which is subclass of the Socket class that overloads its close() method not to close the socket. By then ignoring the SecurityException the malicious class can now accept the connection and make use of the socket.
A buffer overflow condition exists in code that handles the LOGNAME environment variable in the mail(1) program, also known as mail_att. This could be exploited to elevate privileges.
Services By CQR