-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/15/2013 09:18 AM, Reindl Harald wrote:
>
>
> Am 15.03.2013 13:56, schrieb Georgios Petasis:
>> Dear Reindl,
>>
>> I am sorry if I gave a wrong impression, but I was reffering to the tmp,
>> cache and tmp folders inside the joomla installation, not the OS or
>> apache ones
>
> i am too
>
> in your case this would even not had happend if it would have been /tmp of
> the OS beause it is not rechable from outside, not that i would let a
> web-app use /tmp which is shared with other apps and services
>
> on the other hand with "PrivateTmp=yes" in the systemd-unit it would be
> pretty safe and NOT shared, but better have each docroot it's own
> temp-folders to isolate them with open_basedir
>
>> The whole apache document root is owned by root and has a read-only
>
> which is good
>
>> selinux policy (apache cannot write anything in there) The only folders
>> owned by apache and had rw selinux permissions, where the cache, log &
>> tmp folder of the joomla installation (i.e. /var/www/html/joomla/tmp)
>
> which is correct and needed the application needs write permissions there
>
>> This was the folder I found two php files that were executed by calling
>> them though a POST http request.
>
> i understood this well, but read my post again
>
> i explained how to prevent POST and excute to such folders which should be
> done in any context to secure a web-app
>
> the best location for such things is in reality OUTSIDE the docroot at all
> and have open_basedir contain the docroot and this folders outside and if
> possible put includes also outside the docroot
>
> and if you would like get open_basedir really usable you should disable ANY
> function which can execute applications in the "php.ini" -> this DOES NOT
> work with "php_admin_value" perdir even if it is wrongly shown in phpinfo()
> as working
>
> disable_functions = "popen, pclose, exec, passthru, shell_exec, system,
> proc_open, proc_close, proc_nice, proc_terminate, proc_get_status,
> pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo,
> posix_setpgid, posix_setsid, posix_setuid, mail, symlink, link"
>
> with suhosin you have the possibility to work perdir but you can NOT allow
> a function which is contained in "disable_functions", i use all three
> everywhere php_admin_value suhosin.executor.func.blacklist ".........."
> php_admin_value suhosin.executor.eval.blacklist ".........."
>
>> Regards, George
>>
>> Στις 15/3/2013 2:30 μμ, ο/η Reindl Harald έγραψε:
>>>
>>> Am 15.03.2013 12:16, schrieb Georgios Petasis:
>>>> I suspect that it is a joomla 1.5.26 exploit. I have found two php
>>>> files in the tmp folder of one web site, and POSTs to them in the
>>>> apache access log file. I know this is an old version of joomla
>>> this is the main problem
>>>
>>> what your machine does / did is attack 3rd parties and this is the most
>>> common what happens after intrusion and without your ISP having open
>>> yes you would still not know that it happened
>>>
>>> and this is the reason why my reaction on malinglists to posts starzign
>>> with "i installed Fedora 14" is pure anger because it is unacceptable
>>> and i was there on the other side of a DDOS-Attack from many thousand
>>> ip's for nights and can tell anybody that it is no fun try to hold the
>>> business alive in such situations - you can be sure ALL of this
>>> thousands attackers where hijacked servers / clients with whatever OS
>>>
>>>> and I have made the mistake to make the folders tmp, cache & log
>>>> writtable by the apache in selinux...)
>>> the writeable is not the problem, how should they work readonly but
>>> make them accessable AND executeable from the web is a big mistake for
>>> several reasons:
>>>
>>> * log: you do not want access to logfiles from outside * cache: you do
>>> not want get applications cache readed from outside * tmp: you do not
>>> want get temp-fiels of the application readed from outside
>>>
>>> for any folder: you do not want to get executed code from outside which
>>> can be injected this affects also the log-file, i have seen attacks
>>> where php-code was in the requests and someone found a small injection
>>> leak and used the log file to prepare his whole script and execute it
>>> with the injection leak _________________________________________
>>>
>>> i generally protect any log/temp/cache AND all folders where from users
>>> uploaded files (miages, pdf...) are stored with disable the php-engine
>>> and fro tmp/log deny access at all
>>>
>>> "IfVersion" needs "mod_version.so" loaded and is used here to prepare a
>>> smooth upgrade to Apache 2.4 after mod_security acts correct with
>>> "mod_remoteip" behind a proxy
>>>
>>> [harry@srv-rhsoft:~]$ cat /www/www.rhsoft.net/temp/.htaccess <IfModule
>>> mod_php5.c> php_flag engine off </IfModule> <IfModule mod_php6.c>
>>> php_flag engine off </IfModule> <IfVersion < 2.4> Order deny,allow Deny
>>> from all </IfVersion> <IfVersion >= 2.4> Require all denied
>>> </IfVersion>
>
>
>
Do you have your SELinux logs. AVC? What ports were they able to connect to?
On Fedora 19 the only labels apache process is able to both write and execute is
sesearch -A -s httpd_t -p execute -c file -C | grep write
DT allow httpd_t httpdcontent : file { ioctl read write create getattr setattr
lock append unlink link rename execute open } ; [ httpd_enable_cgi
httpd_unified && httpd_builtin_scripting && ]
So you would have to have httpd_unified boolean turned on?
getsebool httpd_unified
httpd_unified --> off
It is off by default, and for most systems should probably be turned off,
going forward.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFDI04ACgkQrlYvE4MpobPYBACePqsVKlXQTB5Te8Azy4OWdPAG
1JkAn1HnBWy2EQINQXUcdNKkEmwxeZpD
=zlRH
-----END PGP SIGNATURE-----
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
