Modsec ruleRemoveTargetById is not removing rules - mod-security2

I am trying to write modsecurity rule exclusions and cant seem to get ctl:ruleRemoveTargetById to work as per the reference manual.
My server is running Debian 9 with apache2 2.4.25-3+deb9 I have tried following the reference manual on github and tried emulating the sample rules in the file >REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf. I have written a simple rule to fire on certain arguments and then tried excluding it, but it wont exclude the rule based on the arguments. I can see both the rule id and the rule exclusion id in the logs.
I have, arbitrarily, put the below rule in REQUEST-905-COMMON-EXCEPTIONS.conf
SecRule ARGS "#rx propfind" "id:905999,phase:2,log,msg:'test msg delete rule'"
This fires as it should. There is an argument named <?xml version that contains the pattern "propfind" in my nextcloud settings page, which I am using for testing.
I have also written an exclusion and put it into REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
SecRule ARGS_NAMES "#rx <\?xml\sversion" "phase:2,log,id:1030,ctl:ruleRemoveTargetById=905999;ARGS:/<\?xml\sversion/"
This rule triggers as expected but does not prevent rule 905999 from firing on argument named <?xml version
I have simplified the rules to the two below and it works as expected; when I enter example.com/?test=trigger I see rule 905999 in the log, but if I send example.com/?testarg=trigger I only see the exclusion rule 1030 as expected.
SecRule ARGS "#rx trigger" "id:905999,phase:2,log,msg:'test msg delete rule'"
SecRule ARGS_NAMES "#rx testarg" "phase:2,log,id:1030,ctl:ruleRemoveTargetById=905999;ARGS:testarg"
When I open the nextcloud settings tab the HTTP request contains
<?xml version="1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:resourcetype/></d:prop></d:propfind>
which Modsec interprets as the argument name <?xml version, containing the value "1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:resourcetype/></d:prop></d:propfind>
I would expect my rule 1030 to stop 905999 from firing, but i still see both rules in the log. I am assuming it is because of the space between "xml" and "version" but cant figure out how to exclude the target.

For some reason the regex in ctl:ruleRemoveTargetById=905999;ARGS:/<\?xml\sversion/ did not work. Using SecRuleUpdateTargetById 905999 "!ARGS:/<\?xml\sversion" and placing it into RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf to update the rule targets after they are loaded works as desired.

Related

How to determine an SELinux rule from an error in dbus-monitor output

I have an issue in a yocto based embedded linux system. I have tracked it down to an interaction between dbus and SELinux, and using dbus-monitor I can see the following error:
error time=1621869986.514891 sender=org.freedesktop.DBus -> destination=:1.4 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=69729
string "An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_return", sender=":1.4" (uid=0 pid=905 comm="/usr/sbin/NetworkManager --no-daemon " label="system_u:system_r:NetworkManager_t:s0") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.6390" (uid=0 pid=14426 comm="/opt/metix-embedded/metix-wg-ui " label="system_u:system_r:init_t:s0")"
However, there is no 'AVC denied' error in the audit log, so I cannot use audit2allow to determine an SELinux rule to allow the interaction.
How can I work out the SELinux rule I need from the dbus-monitor error?
Further research shows that dbus itself is an SELinux aware application. It is checking the SELinux configuration, and taking enforcement actions within dbus itself. This accounts for why the denials from dbus do not appear in the audit log, even when silent denials are turned off.
My particular issue was solved by adding some allow rules for 'send_msg' as follows:
allow init_t NetworkManager_t:dbus send_msg;
allow NetworkManager_t init_t:dbus send_msg;
Note that the 'init_t' and 'NetworkManager_t' types are derived from the dbus-monitor error.
Further information:
https://hub.packtpub.com/handling-selinux-aware-applications/
https://blog.siphos.be/2014/06/d-bus-and-selinux/
https://relativkreativ.at/articles/how-to-compile-a-selinux-policy-package

TYPO3 Upgrade Wizard Fails on DatabaseRowsUpdateWizard

i updated a project from TYPO3 7.6 to ^8 by following the official guide. latest steps were the composer update. i removed extensions/packages not compatible with ^8 and updated the ones available for ^8. im able to reach the install tool, the TYPO3 admin backend and the frontend (with errors).
so i ended up at the step were i should use the upgrade wizards provided by the install tool. i completed a few wizards without any issues but then faces a pretty one - first i tried to run DatabaseRowsUpdateWizard within the install tool but that failed with a memory error - i tried the cli approach with
php -d memory_limit=-1 vendor/bin/typo3cms upgrade:wizard DatabaseRowsUpdateWizard
the processing worked but it ended up with following error:
[ Helhum\Typo3Console\Mvc\Cli\FailedSubProcessCommandException ]
#1485130941: Executing command "upgrade:subprocess" failed (exit code: "1")
thrown in file vendor/helhum/typo3-console/Classes/Install/Upgrade/UpgradeHandling.php
in line 284
the command initially failed is:
'/usr/bin/php7.2' 'vendor/bin/typo3cms' 'upgrade:subprocess' '--command' 'executeWizard' '--arguments' 'a:3:{i:0;s:24:"DatabaseRowsUpdateWizard";i:1;a:0:{}i:2;b:0;}'
and here is the subprocess exception:
[ Sub-process exception: TYPO3\CMS\Core\Resource\Exception\InvalidPathException ]
#1320286857: File ../disclaimer_de.html is not valid (".." and "//" is not allowed in path).
thrown in file typo3/sysext/core/Classes/Resource/Driver/AbstractHierarchicalFilesystemDriver.php
in line 71
im pretty much lost and dont know were to start to get this fixed - help is much appreciated
Issues like these usually stem from broken URLs in RTE fields as can be seen in the error output:
File ../disclaimer_de.html is not valid (".." and "//" is not allowed in path)
In this case you should manually prepare the database and run SQL statements which replace the broken/obsolete ../ prefix from all affected records. An example query:
UPDATE tt_content
SET bodytext = REPLACE(bodytext, 'href="../', 'href="')
WHERE bodytext LIKE '%href="../';
Notice that this query is very basic and can destroy your data, so make sure you run some SELECT statements first to make sure nothing breaks. Also keep a backup of your database at hand.
Sometime, custom or TER extension also have RTE such as tt_news where you might come across same issue. To fix that, you just need to run the same query with the according table.

XML Import Warning: Informatica

I am getting the following warning message while I tried to import XML file in Informatica repository.
Warning: Unexpected condition at: Wcursor.cpp: 305
Contact Informatica technical support for assistance
Continuing may result in damage to your repository.
The XML file is around 70mb and has got around 4500 objects in it. I am migrating an entire application from one server to another.
Not sure why this issue happens. I tried several times and from other client system as well, but no luck.
For importing the XML via command line using "pmrep" command, we need control file. But I dont have any control file for this XML. So cant go with that option.
It would be great if somebody can help me sort out this issue.
Details:
Infa version 9.1
Mounted on Unix environment.
Had the same problem back some time ago. XML parsing takes a lot of memory and / or GUI can't handle it. My solution was to use pmrep command line tool. Worked for me - my workflow was composed of around 3600 objects afair.
If you don't have a control file - create one! Here's a very simple template:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IMPORTPARAMS SYSTEM "impcntl.dtd">
<!--IMPORTPARAMS This inputs the options and inputs required for import operation -->
<!--CHECKIN_AFTER_IMPORT Check in objects on successful import operation -->
<!--CHECKIN_COMMENTS Check in comments -->
<!--APPLY_LABEL_NAME Apply the given label name on imported objects -->
<!--RETAIN_GENERATED_VALUE Retain existing sequence generator, normalizer and XML DSQ current values in the destination -->
<!--COPY_SAP_PROGRAM Copy SAP program information into the target repository -->
<!--APPLY_DEFAULT_CONNECTION Apply the default connection when a connection used by a session does not exist in the target repository -->
<IMPORTPARAMS CHECKIN_AFTER_IMPORT="YES" CHECKIN_COMMENTS="PMREP_IMPORT_TEST" RETAIN_GENERATED_VALUE="NO" COPY_SAP_PROGRAM="NO" APPLY_DEFAULT_CONNECTION="NO">
<!--FOLDERMAP matches the folders in the imported file with the folders in the target repository -->
<FOLDERMAP SOURCEFOLDERNAME="YOUR FIRST SOURCE FOLDER NAME" SOURCEREPOSITORYNAME="REP_DEV" TARGETFOLDERNAME="YOUR FIRST SOURCE FOLDER NAME" TARGETREPOSITORYNAME="REP_TEST"/>
<FOLDERMAP SOURCEFOLDERNAME="YOUR SECOND TARGET FOLDER NAME" SOURCEREPOSITORYNAME="REP_DEV" TARGETFOLDERNAME="YOUR SECOND TARGET FOLDER NAME" TARGETREPOSITORYNAME="REP_TEST"/>
<!--Import will only import the objects in the selected types in TYPEFILTER node -->
<!--TYPENAME type name to import. This should comforming to the element name in powermart.dtd, e.g. SOURCE, TARGET and etc.-->
<!--RESOLVECONFLICT allows to specify resolution for conflicting objects during import. The combination of specified child nodes can be supplied -->
<RESOLVECONFLICT>
<!--TYPEOBJECT allows objects of certain type to apply replace/reuse upon conflict-->
<!--TYPEOBJECT = ALL conflict resolution for ALL types of objects -->
<TYPEOBJECT OBJECTTYPENAME="ALL" RESOLUTION="REPLACE"/>
<!--SPECIFICOBJECT allows a particular object(name, typename etc.) to apply replace/reuse upon conflict -->
<!--NAME Object name-->
<!--EXTRANAME Source DBD name - required for source object to identify uniquely-->
<!--OBJECTTYPENAME Object type name-->
<!--FOLDERNAME Folder which the object belongs to-->
<!--REPOSITORYNAME Repository name that this object belongs to-->
<!--RESOLUTION Resolution to apply for the object in case of conflict-->
<!--SPECIFICOBJECT NAME="your_object" OBJECTTYPENAME="your_object_type" FOLDERNAME="your_source_folder" REPOSITORYNAME="your_source_repo" RESOLUTION="REPLACE"/-->
</RESOLVECONFLICT>
</IMPORTPARAMS>

in wordpress, a valid callback for cp_admin_init and _canonical_charset

I'm using WordPress 3.5 with child-theme of Twenty Eleven 1.5. Suddenly I'm getting following Warning,
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'cp_admin_init' was given in /home/templ/public_html/wp-includes/plugin.php on line 406
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_canonical_charset' was given in /home/templ/public_html/wp-includes/plugin.php on line 173
I'm using following plugins:
download-manager 2.3.9
wordpress-seo 1.4.7
wp-pagenavi 2.83
Some more points:
1) If I'm giving mysite.com it's giving above 2 line warning. If I give www.mysite.com, the following line also include,
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-includes/pluggable.php on line 876
2) If I give mysite.com/wp-admin/ or www.mysite.com/wp-admin/, It's giving 1st warning and 3rd warning.
3) If I goto www.mysite.com/wp-login.php, It's giving following 5 warning.
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'cp_admin_init' was given in /home/templ/public_html/wp-includes/plugin.php on line 406
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_canonical_charset' was given in /home/templ/public_html/wp-includes/plugin.php on line 173
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-login.php on line 368
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-login.php on line 380
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'wp_authenticate_spam_check' was given in /home/templ/public_html/wp-includes/plugin.php on line 173
4) If I give correct username and password, it's not going to login. giving following problem,
ERROR: Invalid username or incorrect password.
ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.
I'm trying to find solution. I can't. Can any-one help me?
This sounds like a corrupted install. So you have a few options to fix this:
Attempt to get logins operational again and doing an upgrade though the wp-admin: Explained Below.
Do a manual Update: http://codex.wordpress.org/Updating_WordPress#Manual_Update
But First: Make a Backup
Please be sure to backup your install! Before proceeding: http://codex.wordpress.org/WordPress_Backups
Getting Logins Working: Masking the symptoms
First I would disable debugging output because that should fix most of these issues. When a warning occurs in Wordpress, PHP starts writing the response body and closes the header section of the response. This means that whenever Wordpress tries to add another header after the original warning was raised, PHP will raise another warning:
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-login.php on line 380
So if we disable debugging then we should be able to mask the symptoms. This is a quick patch for a larger problem that we will have to solve with an in-place upgrade
To Disable Debugging
Ensure that the following constants exist and are set correctly is in your wp-config.php file
define('WP_DEBUG', false);
and
define('WP_DEBUG_DISPLAY', false);
Now you should be able to login to your site as an administrator without errors.
Disable your Plugins
Disable all your plugins in Plugins -> Installed Plugins This is imperative so that we can make sure that the update goes smoothly.
Do an Update
Go to Dashboard -> Updates and click either Update Now or Re-install Now
Reactivate your Plugins
Reactivate all your plugins in Plugins -> Installed Plugins and update them if necessary.
That's It
That's the process for reinstalling Wordpress. The key here is that you have Debugging enabled on a production site which is not good. You should always have WP_DEBUG and WP_DEBUG_DISPLAY set to false in a production environment.

Zend -> Warning: is_readable() [function.is-readable]: open_basedir restriction in effect

I am getting the following warning in my code:
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php/./views/helpers/Doctype.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
or
Warning: is_readable() [function.is-readable]: open_basedir restriction in effect. File(/usr/share/php//var/www/virtual/example.com/htdocs/rockhopper-v2/application/modules/default/views/helpers/Layout.php) is not within the allowed path(s): (/var/www/virtual/example.com/:/usr/share/pear/) in /var/www/virtual/example.com/htdocs/rockhopper-v2/library/Zend/Loader.php on line 198
what is the problem and will it cause problems in deployment and production stage of my application?
Thank you
This message appears because since Zend FW 1.10.1 the autoloader creates the path to those files differently. You can find some more information here: Zend FW Bug Report
To get rid of this message you can edit the file index.php and change the set_include_path to this:
set_include_path(
APPLICATION_PATH.'/../library'.PATH_SEPARATOR.
APPLICATION_PATH.'/../library/Zend'
);
open_basedir is set php is running in safe mode. It restricts you to the folders specified in the list. This might help: http://blog.php-security.org/archives/72-Open_basedir-confusion.html
And yes, you will need to change it on any server if you want to access files outside the default folder.