Hi All As you all know a non root user can not run iftop. So the most obvious workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access.
Please comment.
Regards
Hi All As you all know a non root user can not run iftop. So the most obvious workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access.
Please comment.
Regards
Ali,
On 18 Jan 2010, at 16:35, Ali Jawad wrote:
As you all know a non root user can not run iftop. So the most obvious workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
I have to say, I'd completely forgotten that that feature existed!
At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access.
Indeed.
There are two answers to this. The first is that although this provides the user with a very direct and simple way of getting a shell, I would not warrant that there are not bugs in either iftop or any of it's library dependencies that can be exploited to give privilege escalation. This applies to just about any non-trivial program that you may wish to make available via sudo.
The second answer is that there's a compile-time option to disable this functionality (which I'd also forgotten about, but the change log claims it was introduced in 0.17).
I can't remember exactly how to use it, but something like:
export CFLAGS=-DNO_SYSTEM
then rebuilding may do what you want.
Paul
Hi Paul I discovered it by accident, and well you are right about bugs for privilege escalation. But this is not a bug, it is a feature that can be used for privilege escalation. I did google around and as you said it is barely known. I can see the benefits of the feature, to see live changes in traffic shapping by executing different traffic shapping scripts through the commad prompts and seeing the results.
For my own needs, I will remove the deb package and recompile from source.
Regards
On Mon, Jan 18, 2010 at 9:24 PM, Paul Warren pdw@ex-parrot.com wrote:
Ali,
On 18 Jan 2010, at 16:35, Ali Jawad wrote:
As you all know a non root user can not run iftop. So the most obvious
workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
I have to say, I'd completely forgotten that that feature existed!
At this point a user can execute su, and he will get a root shell. He can
also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access.
Indeed.
There are two answers to this. The first is that although this provides the user with a very direct and simple way of getting a shell, I would not warrant that there are not bugs in either iftop or any of it's library dependencies that can be exploited to give privilege escalation. This applies to just about any non-trivial program that you may wish to make available via sudo.
The second answer is that there's a compile-time option to disable this functionality (which I'd also forgotten about, but the change log claims it was introduced in 0.17).
I can't remember exactly how to use it, but something like:
export CFLAGS=-DNO_SYSTEMthen rebuilding may do what you want.
Paul
Just to be fair, even text editor do allow for such functionality. The simplest way to deal with this is to make use of the noexec functionality of sudo. It does prevent a process from spawning a shell.
On Mon, Jan 18, 2010 at 9:34 PM, Ali Jawad alijawad1@gmail.com wrote:
Hi Paul I discovered it by accident, and well you are right about bugs for privilege escalation. But this is not a bug, it is a feature that can be used for privilege escalation. I did google around and as you said it is barely known. I can see the benefits of the feature, to see live changes in traffic shapping by executing different traffic shapping scripts through the commad prompts and seeing the results.
For my own needs, I will remove the deb package and recompile from source.
Regards
On Mon, Jan 18, 2010 at 9:24 PM, Paul Warren pdw@ex-parrot.com wrote:
Ali,
On 18 Jan 2010, at 16:35, Ali Jawad wrote:
As you all know a non root user can not run iftop. So the most obvious
workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
I have to say, I'd completely forgotten that that feature existed!
At this point a user can execute su, and he will get a root shell. He can
also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access.
Indeed.
There are two answers to this. The first is that although this provides the user with a very direct and simple way of getting a shell, I would not warrant that there are not bugs in either iftop or any of it's library dependencies that can be exploited to give privilege escalation. This applies to just about any non-trivial program that you may wish to make available via sudo.
The second answer is that there's a compile-time option to disable this functionality (which I'd also forgotten about, but the change log claims it was introduced in 0.17).
I can't remember exactly how to use it, but something like:
export CFLAGS=-DNO_SYSTEMthen rebuilding may do what you want.
Paul
Hi!
At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access.
Indeed. [..] The second answer is that there's a compile-time option to disable this functionality (which I'd also forgotten about, but the change log claims it was introduced in 0.17).
I can't remember exactly how to use it, but something like:
export CFLAGS=-DNO_SYSTEM
then rebuilding may do what you want.
There ist still an other way (which I just learned myself): Properly configre your sudoers.
sudo can (on supported platforms) prevent subshells (or any subcommands) to be run.
E.g. the following:
are ALL=NOEXEC: /usr/sbin/iftop
Allows the user "are" to execute iftop, but prevents him from executing a subshell. iftop will then display a "permission denied" error.
More details are in the sudo manpage under the topic "REVENTING SHELL ESCAPES".
Best regards, Alexander, wondering if the Debian packages should this disable this feature completly or just document and recommend the NOEXEC trick.
On Mon, Jan 18, 2010 at 07:35:52PM +0300, Ali Jawad wrote:
As you all know a non root user can not run iftop. So the most obvious workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access. Please comment.
I'd make availability of "!" depend on explicit commandline switch -- IIRC comparing getuid()/geteuid() won't help much, and for a program intended to run with elevated privileges having means to start another program is something worth reconsidering.
2 ldv: what would you say?
PreScriptum: Paul, could you please accept changes done here? http://git.altlinux.org/people/ldv/packages/?p=iftop.git
I'm attaching the full diff between 0.17 and ALT Linux package, as well as individual patch (which was since updated, see git).
2 ldv: what would you say?
--- On Wed, Jan 20, 2010 at 04:07:23PM +0200, Michael Shigorin wrote:
On Mon, Jan 18, 2010 at 07:35:52PM +0300, Ali Jawad wrote:
As you all know a non root user can not run iftop.
Unless iftop is installed suid-root.
So the most obvious workaround is to use sudo. Now if you give a regular user sudo access he will execute.
sudo iftop
Once he is inside iftop. He can execute ! he will get the following promtp
command >
At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode. The idea of using sudo initially was giving the user iftop access. However the user ends up with total root access. Please comment.
I'd make availability of "!" depend on explicit commandline switch -- IIRC comparing getuid()/geteuid() won't help much, and for a program intended to run with elevated privileges having means to start another program is something worth reconsidering.
2 ldv: what would you say?
I think that a privileged program shouldn't execute arbitrary user specified programs unless explicitly configured to allow such insecure behaviour.
A process can check at startup time whether it is executed: - suid-root, by comparing results of getuid() and geteuid(); - by sudo, by checking SUDO_USER environment variable.
It is important to do the check at startup time, because process privileges could be lowered later.
-- ldv ---
On 20 Jan 2010, at 15:21, Michael Shigorin wrote:
PreScriptum: Paul, could you please accept changes done here? http://git.altlinux.org/people/ldv/packages/?p=iftop.git
I need to review what has been done there, as those patches appear to tackle a range of different issues.
I would encourage you to submit patches directly to the list in future, as you write them, as it's much easier to discuss and accept them as they are written.
I think that a privileged program shouldn't execute arbitrary user specified programs unless explicitly configured to allow such insecure behaviour.
iftop is not, by design, a privileged program. There is nothing in the documentation that endorses running it setuid root, or in a sudo wrapper. As such, the ability to get to a shell is no different from the fact that vim allows you to run arbitrary programs.
That said, the fact that iftop requires root privileges in order to run in the vast majority of environments means that a shell escape that is on by default may come as a nasty surprise to admins who use sudo / setuid root to grant access to iftop to semi-trusted users, and I would certainly consider making this an off-by-default compile time option.
Paul
On Mon, Jan 18, 2010 at 07:35:52PM +0300, Ali Jawad wrote:
Once he is inside iftop. He can execute ! he will get the following promtp command > At this point a user can execute su, and he will get a root shell. He can also execute any command in privileged mode.
OTOH I didn't exactly manage to execute anything with Dmitry Levin's iftop-0.16-alt-droproot.patch (commit 04f8d2cb0e0e07bd834f49dcb4d49bf07e060d04 in http://git.altlinux.org/people/ldv/packages/?p=iftop.git) and pseudouser having his shell and home set to /dev/null:
$ sudo iftop -BP -i eth0 interface: eth0 IP address is: ... MAC address is: ... ls /: exited with code 127 echo test: exited with code 127 Press any key....
See also ChangeLog as of 0.17: * Addition of "NO_SYSTEM" compiler flag to prevent subshell execution
Seems like nice default, er?
In the mean time, I'm pushing ALT Linux package built with CFLAGS="-DNO_SYSTEM" just in case, thanks for spotting.
-
Alexander Reichle-Schmehl -
Ali Jawad -
Michael Shigorin -
Paul Warren