[horde] calls to popen()

[Vilius Šumskas]

> Am 15.02.2012 11:19, schrieb Vilius Šumskas:
> >> Am 14.02.2012 20:46, schrieb Michael M Slusarz:
> >>> Quoting Jan Schneider <jan at horde.org>:
> >>>
> >>>> Zitat von Reindl Harald <h.reindl at thelounge.net>:
> >>>>
> >>>>> Am 11.02.2012 08:16, schrieb Vilius ?umskas:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Saturday, February 11, 2012, 12:57:10 AM, you wrote:
> >>>>>>
> >>>>>>> what is this after update H3 some minutes ago?
> >>>>>>
> >>>>>>> Feb 10 22:52:52 [30092] ALERT - function within blacklist called:
> >>>>>>> popen() (attacker '10.0.0.241', file
> >>>>>>> '/usr/share/horde/lib/Horde/Crypt/pgp.php', line 1696)
> >>>>>>
> >>>>>>> there are existing pear packages and no single need to
> >>>>>>> open command execution which nobody will do interested
> >>>>>>> in security for foreign software
> >>>>>>
> >>>>>> There  is nothing wrong with popen() calls. If you "security" software
> >>>>>> thinks overwise, then it is seriously botched.
> >>>>>
> >>>>> and the following proves you are wrong
> >>>>>
> >>>>> open_basedir will isolate vhosts where mod_php is needed
> >>>>> popen() and such commands are breakiing out of the vhost
> >>>>> if the following happens your whole machine is compromised
> >>>>
> >>>> This only proves that open_basedir is not much more than a duct tape.
> >>>
> >>> Sort of like suhosin's theory: if we break PHP so you can't use it, it is now
> >> more secure.  Stupid.
> >>>
> >>> I'm going to start a company that uses all of suhosin's buzzwords and
> then,
> >> when hired, I will go to the client's
> >>> office and disable the network interface on the PHP machine.  Ta-da!
> That
> >> PHP installation is now 100% secure!
> >>
> >> stop such nonsense
> >>
> >> there is NOTHING broken if anybody disables shell-access through PHP
> >> anybody who allows it should consider no longer maintain any
> >> production servers!
> >
> > What is a shell-access? It is access to the filesystem, that's all. PHP as a
> programming language have gazilion ways accessing a filesystem below,
> including file uploads and don't forget sockets. And blocking those totally
> criples all major applications. Other web programming languages doesn't
> even have such "security" configuration parameters. And for a good reason.
> It makes no sense. You have to ensure security on the system level, be it
> cgroups, jails, selinux or apparmor.
> 
> what is shell access?
> using exec('/bin/anything'); or popen('/bin/anything');
> 
> this are features which NEVER has to be used in ANY common
> web applications, they are nice for php shell-scripts but
> NOT in the context of a webserver

Then the context in which a webserver running is wrong. If you are concerned that webserver can execute files in /bin or elsewhere on the system then it should denied on the system level. That's why most distributions these days run apache on separate user. And the recommendation for shared hosting is to run each vhost on at least separate user (using suexec, fastcgi or similar).

 > any application relying on such commands in miss-designed!

But it's not, because in most cases running popen() or any other "dangerous" command is the only way to interface with external programs.

-- 
  Vilius