Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Dec 2011 14:24:16 -0800
From:      Xin Li <delphij@delphij.net>
To:        Mike Tancsa <mike@sentex.net>
Cc:        "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, d@delphij.net, Przemyslaw Frasunek <przemyslaw@frasunek.com>
Subject:   Re: ftpd security issue ?
Message-ID:  <4EE13910.2030103@delphij.net>
In-Reply-To: <4EE131B8.7040000@sentex.net>
References:  <4ED68B4D.4020004@sentex.net> <4ED69B7E.50505@frasunek.com>	<4ED6C3C6.5030402@delphij.net> <4ED6D1CD.9080700@sentex.net>	<4ED6D577.9010007@delphij.net> <4ED6DA75.30604@sentex.net> <4EE131B8.7040000@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/08/11 13:52, Mike Tancsa wrote:
> On 11/30/2011 8:37 PM, Mike Tancsa wrote:
>> On 11/30/2011 8:16 PM, Xin LI wrote:
>>> 
>>> Sorry I patched at the wrong place, this one should do.
>>> 
>>> Note however this is not sufficient to fix the problem, for
>>> instance one can still upload .so's that run arbitrary code at
>>> his privilege, which has to be addressed in libc.  I need some
>>> time to play around with libc to really fix this one.
>> 
>> Hi, Yes, that looks better!  With respect to users uploading .so
>> files, I guess why not just upload executables directly ?
>> Although I suppose if they are not allowed to execute anything,
>> this would be a way around that.
>> 
>> Now to prod the proftpd folks
> 
> I was testing sshd when the user's sftp session is chrooted to see
> how it behaves. Because of the safety design of the way sshd is
> written, its not possible to do this out of the box.  The person
> would first need to create those files as root since the chroot
> directory is not writeable by the user as explained in 
> http://www.gossamer-threads.com/lists/openssh/dev/44657
> 
> But if somehow the user is able to create those directories at the
> top, or those directories are created ahead of time for the user
> thats writeable by them, the bogus lib will and does run in the
> user's context.
> 
> I dont imagine this is common, but I am sure there is some
> potential foot shooting going on.  Looking at the scponly port, it
> seems well aware of this based on the suggested setup.  But again,
> foot shooting could happen if the lib path is not secured
> properly.
> 
> Other than having /etc/nsswitch.conf, are there any other methods
> that would trigger loading of shared libs in the chrooted
> environment ?

PAM and iconv (not enabled by default) come to mind.

Cheers,
- -- 
Xin LI <delphij@delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7hORAACgkQOfuToMruuMCzZACfSmhjQjXck5tQGbMWuKhnQvjo
JuwAn2odZWw9Lw8nUqtbl8c2Jzysz/oc
=QAvJ
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EE13910.2030103>