All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Kirch <okir@suse.de>
To: mike@waychison.com
Cc: linux-nfs <nfs@lists.sourceforge.net>,
	autofs mailing list <autofs@linux.kernel.org>
Subject: Re: [PATCH/RFC 1/2] rpcproxyd
Date: Mon, 14 Mar 2005 11:52:49 +0100	[thread overview]
Message-ID: <20050314105249.GH14815@suse.de> (raw)
In-Reply-To: <37093.66.11.176.22.1110228819.squirrel@webmail1.hrnoc.net>

Hi Mike,

I'm somewhat wary of this idea, because it creates a very attractive
target for crackers. Once an attacker managers to fool this proxy
daemon, he can talk to your NFS Server, concealing his identity or
even posing as root, etc.

I looked at the code in the light of this, and there are a few
soft spots.

 -	you retrieve credentials in the initial negotiation
 	only. But client credentials can change, and should be
	checked with every packet.

	For instance, I can connect to your service, and fork off
	some setuid root application, with stderr connected to that
	socket. Any error message the application prints will be arrive
	with uid 0. If I manage to make that message appear valid to you,
	your daemon will accept any future input unquestioned.

	So my recommendation would be to validate credentials on
	every packet, and if they change from the original values
	received during negotiation, drop the connection.

	I'd also recommend to change the permissions on the Unix
	socket to 700.

 -	This mechanism is really a special-case workaround for the
 	mount problem, but you're creating a general purpose framework.
	That means if it's attacked successfully, it can be abused 
	to attack any RPC based service on any host.

	If you make it less generic, and allow only mount calls, you'll
	be much safer, because in the case of a bug, an attacker will
	be able to send fake MOUNT packets, but nothing else.

 -	In several places, you keep packet offsets (pos, bufferpos)
	in signed variables and compare them to unsigneds; that's
	dangerous.

 -	Your code assumes sizeof(unsigned long) == 4, eg here

	unsigned long len;
	[...]
		memcpy(&len, conn->buffer, 4);
		len = ntohl(len);
		buf = &conn->buffer[4];

	It's better to use uint32_t in such cases.

Regards,
Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  parent reply	other threads:[~2005-03-14 10:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07 20:52 [PATCH/RFC 0/2] Userspace RPC proxying mike
2005-03-07 20:53 ` [PATCH/RFC 1/2] rpcproxyd mike
2005-03-07 20:54   ` [PATCH/RFC 2/2] make mount(8)/umount(8) use clntproxy_create mike
2005-03-14 10:52   ` Olaf Kirch [this message]
2005-03-14 17:34     ` [PATCH/RFC 1/2] rpcproxyd mike
2005-03-14 17:34       ` mike
2005-03-14 19:24       ` Olaf Kirch
2005-03-14 20:08         ` mike
2005-03-14 20:08           ` mike

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050314105249.GH14815@suse.de \
    --to=okir@suse.de \
    --cc=autofs@linux.kernel.org \
    --cc=mike@waychison.com \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.