mod-security-packagers

Re: [mod-security-packagers] [mod-security-users] ModSecurity 2.5.10 Released

[Brian R. <bre...@gm...>]

ModSecurity has always required Lua 5.1.x.  Perhaps this version is
finding 5.0 by mistake instead of ignoring it?  The --without-lua
configure option should help you.  I'll look at adding a version check
to the next release.

thanks,
-B

On Fri, Sep 25, 2009 at 12:16 PM, Mike Duncan <Mik...@no...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A heads up...I think that this version requires lua 5.1.4 (possibly a
> little less version tho). I have RHEL 5.4 with lua 5.0.2 from DAG
> installed currently and 2.5.9 seems fine. However, 2.5.10's make fails...
>
> ===
> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic
> - -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
> - -fno-strict-aliasing  -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -pthread
> - -I/usr/include/httpd  -I/usr/include/apr-1   -I/usr/include/apr-1  -O2
> - -g -Wall -I/usr/include/httpd -I/usr/include/httpd -I.
> - -I/usr/include/apr-1 -I/usr/kerberos/include -I/usr/include/libxml2
> - -I/usr/include -DWITH_LUA  -c -o msc_lua.lo msc_lua.c && touch msc_lua.slo
> msc_lua.c: In function 'lua_compile':
> msc_lua.c:96: warning: implicit declaration of function 'luaL_openlibs'
> msc_lua.c: In function 'resolve_tfns':
> msc_lua.c:159: warning: implicit declaration of function 'lua_objlen'
> msc_lua.c: At top level:
> msc_lua.c:338: error: array type has incomplete element type
> msc_lua.c: In function 'lua_execute':
> msc_lua.c:378: warning: implicit declaration of function 'luaL_register'
> apxs:Error: Command failed with rc=65536
> .
> make: *** [mod_security2.la] Error 1
> ===
>
> On another RHEL 5.4 with lua 5.1.4 (devel as well) installed everything
> compiles fine. You can download lua binary packages from here:
> http://luaforge.net/frs/?group_id=110.
>
> Let me know if I am wrong on the versioning or msising something. I
> guess DAG has not updated this package in some time.
>
> Mike Duncan
> ISSO, Application Security Specialist
> Government Contractor with STG, Inc.
> NOAA :: National Climatic Data Center
>
>
> Brian Rectanus wrote:
>> ModSecurity 2.5.10 has been released and is now available.
>>
>> This release fixes a number of small issues.  Notable issues that have
>> been fixed are a cleaner build process, fixes to mlogc to build on
>> Windows and allow more reliable SSL neg. to the console, less verbose
>> logging when using anomaly scoring with CRS v2.x and a feature to
>> allow easier use with Apache mpm-itk.
>>
>> Downloads and docs from modsecurity.org as usual.
>>
>>
>> 18 Sep 2009 - 2.5.10
>> --------------------
>>  * Cleanup mlogc so that it builds on Windows.
>>  * Added more detailed messages to replace "Unknown error" in filters.
>>  * Added SecAuditLogDirMode and SecAuditLogFileMode to allow fine tuning
>>    auditlog permissions (especially with mpm-itk).
>>  * Cleanup SecUploadFileMode implementation.
>>  * Cleanup build scripts.
>>  * Fixed crash on configuration if SecMarker is used before any rules.
>>  * Fixed SecRuleUpdateActionById so that it will work on chain starters.
>>  * Cleanup build system for mlogc.
>>  * Allow mlogc to periodically flush memory pools.
>>  * Using nolog,auditlog will now log the "Message:" line to the auditlog, but
>>    nothing to the error log.  Prior versions dropped the "Message:" line from
>>    both logs.  To do this now, just use "nolog" or "nolog,noauditlog".
>>  * Forced mlogc to use SSLv3 to avoid some potential auto negotiation
>>    issues with some libcurl versions.
>>  * Fixed mlogc issue seen on big endian machines where content type
>>    could be listed as zero.
>>  * Removed extra newline from audit log message line when logging XML errors.
>>    This was causing problems parsing audit logs.
>>  * Fixed @pm/@pmFromFile case insensitivity.
>>  * Truncate long parameters in log message for "Match of ... against ...
>>    required" messages.
>>  * Correctly resolve chained rule actions in logs.
>>  * Cleanup some code for portability.
>>  * AIX does not support hidden visibility with xlc compiler.
>>  * Allow specifying EXTRA_CFLAGS during configure to override gcc specific
>>    values for non-gcc compilers.
>>  * Populate GEO:COUNTRY_NAME and GEO:COUNTRY_CONTINENT as documented.
>>  * Handle a newer geo database more gracefully, avoiding a potential crash for
>>    new countries that ModSecurity is not yet aware.
>>  * Allow checking &GEO "@eq 0" for a failed @geoLookup.
>>  * Fixed mlogc global mutex locking issue and added more debugging output.
>>  * Cleaned up build dependencies and configure options.
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Appliances, Rule Sets and Support:
>> http://www.modsecurity.org/breach/index.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkq9FwMACgkQnvIkv6fg9hZCnQCff0odqo/9ex1bkThN0IUXNBXf
> QHkAmwWop19wTZwhUmq4k1VOKv4JyHFH
> =y+b5
> -----END PGP SIGNATURE-----
>

[mod-security-packagers] ModSecurity 2.5.10 Released

[Brian R. <bre...@gm...>]

ModSecurity 2.5.10 has been released and is now available.

This release fixes a number of small issues.  Notable issues that have
been fixed are a cleaner build process, fixes to mlogc to build on
Windows and allow more reliable SSL neg. to the console, less verbose
logging when using anomaly scoring with CRS v2.x and a feature to
allow easier use with Apache mpm-itk.

Downloads and docs from modsecurity.org as usual.


18 Sep 2009 - 2.5.10
--------------------
 * Cleanup mlogc so that it builds on Windows.
 * Added more detailed messages to replace "Unknown error" in filters.
 * Added SecAuditLogDirMode and SecAuditLogFileMode to allow fine tuning
   auditlog permissions (especially with mpm-itk).
 * Cleanup SecUploadFileMode implementation.
 * Cleanup build scripts.
 * Fixed crash on configuration if SecMarker is used before any rules.
 * Fixed SecRuleUpdateActionById so that it will work on chain starters.
 * Cleanup build system for mlogc.
 * Allow mlogc to periodically flush memory pools.
 * Using nolog,auditlog will now log the "Message:" line to the auditlog, but
   nothing to the error log.  Prior versions dropped the "Message:" line from
   both logs.  To do this now, just use "nolog" or "nolog,noauditlog".
 * Forced mlogc to use SSLv3 to avoid some potential auto negotiation
   issues with some libcurl versions.
 * Fixed mlogc issue seen on big endian machines where content type
   could be listed as zero.
 * Removed extra newline from audit log message line when logging XML errors.
   This was causing problems parsing audit logs.
 * Fixed @pm/@pmFromFile case insensitivity.
 * Truncate long parameters in log message for "Match of ... against ...
   required" messages.
 * Correctly resolve chained rule actions in logs.
 * Cleanup some code for portability.
 * AIX does not support hidden visibility with xlc compiler.
 * Allow specifying EXTRA_CFLAGS during configure to override gcc specific
   values for non-gcc compilers.
 * Populate GEO:COUNTRY_NAME and GEO:COUNTRY_CONTINENT as documented.
 * Handle a newer geo database more gracefully, avoiding a potential crash for
   new countries that ModSecurity is not yet aware.
 * Allow checking &GEO "@eq 0" for a failed @geoLookup.
 * Fixed mlogc global mutex locking issue and added more debugging output.
 * Cleaned up build dependencies and configure options.

[mod-security-packagers] ModSecurity v2.5.10-dev3 released

[Brian R. <Bri...@br...>]

ModSecurity v2.5.10-dev3 has been released. This is the third (and 
hopefully last) development release for 2.5.10 which fixes some build 
issues and adds some features for managing audit log permissions 
(especially with mpm-itk).

Please test the release out on your development/test systems and let the
list know if there are any issues.


You can download the release from modsecurity.org:

http://www.modsecurity.org/download/


Bugs fixed (see the roadmap):

https://www.modsecurity.org/tracker/browse/MODSEC


24 Aug 2009 - 2.5.10-dev3
-------------------------

* Added SecAuditLogDirMode and SecAuditLogFileMode to allow fine tuning
   auditlog permissions (especially with mpm-itk).

* Cleaned up SecUploadFileMode implementation.

* Cleanup build scripts.


thanks,
-B

--
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity v2.5.10-dev2 released

[Brian R. <Bri...@br...>]

ModSecurity v2.5.10-dev2 has been released. This is the second 
development release for 2.5.10 which fixes some build issues with mlogc, 
a potential configuration crash and SecRuleUpdateActionById. 
Additionally, this release includes the latest release of the Core Rule 
Set (CRS) v2.0.1.

Please test the release out on your development/test systems and let the 
list know if there are any issues.


You can download the release from modsecurity.org:

http://www.modsecurity.org/download/


Bugs fixed (see the roadmap):

https://www.modsecurity.org/tracker/browse/MODSEC


thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.10-dev1 Released

[Brian R. <Bri...@br...>]

Hello all,

I have released the first development release of ModSecurity 2.5.10 for 
testing.  This release primarily fixes some build issues with 2.5.9 as 
well as some mlogc issues.  Additionally, this release includes a 
development release of the Core Rule Set (CRS) v2.0 for testing (I'll 
let Ryan Barnett explain more on that in a later note, but please be 
sure to read the README and CHANGELOG for the rules before applying them).

Please test the release out on your development/test systems and let the 
list know if there are any issues.


You can download the release from SourceForge:

http://sourceforge.net/projects/mod-security/files/


Bugs fixed (see the roadmap):

https://www.modsecurity.org/tracker/browse/MODSEC


Changes:

  * Allow mlogc to periodically flush memory pools.
  * Using nolog,auditlog will now log the "Message:" line to the
    auditlog, but nothing to the error log.  Prior versions dropped the
    "Message:" line from both logs.  To do this now, just use "nolog" or
    "nolog,noauditlog".
  * Forced mlogc to use SSLv3 to avoid some potential auto negotiation
    issues with some libcurl versions.
  * Fixed mlogc issue seen on big endian machines where content type
    could be listed as zero.
  * Removed extra newline from audit log message line when logging XML
    errors. This was causing problems parsing audit logs.
  * Fixed @pm/@pmFromFile case insensitivity.
  * Truncate long parameters in log message for "Match of ... against ...
    required" messages.
  * Correctly resolve chained rule actions in logs.
  * Cleanup some code for portability.
  * AIX does not support hidden visibility with xlc compiler.
  * Allow specifying EXTRA_CFLAGS during configure to override gcc
    specific values for non-gcc compilers.
  * Populate GEO:COUNTRY_NAME and GEO:COUNTRY_CONTINENT as documented.
  * Handle a newer geo database more gracefully, avoiding a potential
    crash for new countries that ModSecurity is not yet aware.
  * Allow checking &GEO "@eq 0" for a failed @geoLookup.
  * Fixed mlogc global mutex locking issue and added more debugging
    output.
  * Cleaned up build dependencies and configure options.


-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.9 (and 2.5.8) now available

[Brian R. <Bri...@br...>]

ModSecurity 2.5.9 is now available.  The 2.5.8 release was delayed until
the 2.5.9 version was ready due to a vulnerability disclosed after 2.5.8
code freeze.  For this reason, the 2.5.8 release should be disregarded
in favor of 2.5.9.

Please note that the I changed to my alternative key for signing these
releases as the previous key I used for signing expired.  This key is
available from most PGP/GPG key servers.

The 2.5.9 release fixes a potential DoS vulnerability discovered
by "Internet Security Auditors" when parsing multipart
requests as well as a potential DoS vulnerability discovered in the PDF
XSS protection engine (fixed in 2.5.8).  Additionally, 2.5.9 cleans up
the build process and adds a few features, including atomic updates of
persistent counters and macro expansion of the append/prepend
actions.  It is highly recommended to upgrade to this 2.5.9 release.

Please see the blog post for more information on the vulnerabilities
fixed in this release:

http://blog.modsecurity.org/2009/03/modsecurity-vulnerabilities-fixed.html


Packages can be downloaded via modsecurity.org as always.


The complete change log is below...

2.5.9
-----

 * Fixed parsing multipart content with a missing part header name which
would crash Apache.  Discovered by "Internet Security Auditors"
(isecauditors.com).

 * Added ability to specify the config script directly using --with-apr
and --with-apu.

 * Updated copyright year to 2009.

 * Added macro expansion for append/prepend action.

 * Fixed race condition in concurrent updates of persistent counters.
Updates are now atomic.

 * Cleaned up build, adding an option for verbose configure output and
making the mlogc build more portable.


2.5.8
-----

 * Fixed PDF XSS issue where a non-GET request for a PDF file would
crash the Apache httpd process.  Discovered by Steve Grubb at Red Hat.

 * Removed an invalid "Internal error: Issuing "%s" for unspecified
error." message that was logged when denying with nolog/noauditlog set
and causing the request to be audited.


thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] Looking toward ModSecurity 3

[Brian R. <Bri...@br...>]

All,

I am starting work on ModSecurity 3.  This version is concentrated on
isolating a ModSecurity core library from the web server component so
that we can port to other web platforms (notably Apache 1.3 and perhaps
even IIS).

With this change, I am refactoring the build.  I will be making full use
of the autotools for UNIX like OSes, which seems to be working well.  In
addition to this, I would like to better support building packages for
various distributions (RPMs, DEBs, etc).  However, I am still undecided
(and a bit inexperienced) with how to deal with Windows builds.  I would
appreciate any help, comments, suggestions and other insight into making
it easier to build distribution packages, especially for Windows.

The current layout is looking something like this (but may change).  It
would be ideal to be able to build everything under *nix and Windows.

src/            # Main source tree
  msc/          # ModSecurity core
  native/       # Native module/plugin tree
    apache1/    # Apache 1.3 module
    apache2/    # Apache 2.x module
include/        # Global include files
doc/            # Documentation (docbook refman and doxygen)
rules/          # Core rules
conf/           # Example configuration files
tools/          # Tools source tree
  mlogc/        # ModSecurity Log Collector source
t/              # Test tree
build/          # Misc build scripts/macros/etc.

Again, any comments from you that would make ModSecurity easier to
package would be greatly appreciated.

thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.7 Available

[Brian R. <Bri...@br...>]

ModSecurity 2.5.7 contains quite a few fixes for some not-so-common
issues.  No changes (other than version change) were made since
2.5.7-rc1.  If you are seeing any of the following issues, then please
upgrade to 2.5.7.

1) Cannot turn off the request body limit check.  This release allows
you to use ctl:requestBodyAccess=off and/or ctl:ruleEngine=off in
phase:1 so that you can selectively bypass this check.

2) Some XML issues were difficult (impossible?) to diagnose as the
underlying XML error/warning was not logged.  All XML processing errors
and warnings are now logged to the debug log (if level is high enough).

3) XML DTD/Schema validation still succeeded when the XML was not well
formed, but could still be parsed.  This is corrected and the validation
will fail on any request parsing errors.

4) The hostname logged in the error log is the canonical name, not the
request supplied name.  This makes sure that there is always a hostname
in the log entry.

5) The REQUEST_BODY variable was not available unless you forced the use
of URLENCODED processor.  This would cause parsing to fail if it was not
a url encoded POST.  You can now use ctl:forceRequestBodyVariable=on to
force populating the REQUEST_BODY variable without setting the processor
and thus avoiding the parsing errors.

6) Certain "legacy" protocols have been ported to be tunneled in HTTP
request.  Some of these requests use the 8th bit of each byte as a
parity bit.  This can cause problems when trying to perform matches on
the data.  It is now possible to transform (t:parityEven7bit,
t:parityOdd7bit) or remove (t:parityZero7bit) the parity.


Packages can be downloaded from modsecurity.org as always.


The complete change log is below...

24 Sep 2008 - 2.5.7
-------------------

* Fixed XML DTD/Schema validation which will now fail after request body
  processing errors, even if the XML parser returns a document tree.

* Added ctl:forceRequestBodyVariable=on|off which, when enabled, will
force the REQUEST_BODY variable to be set when a request body processor
is not set. Previously the REQUEST_BODY target was only populated by the
URLENCODED request body processor.

* Integrated mlogc source.

* Fixed logging the hostname in the error_log which was logging the
request hostname instead of the Apache resolved hostname.

* Allow for disabling request body limit checks in phase:1.

* Added transformations for processing parity for legacy protocols
ported to HTTP(S): t:parityEven7bit, t:parityOdd7bit, t:parityZero7bit

* Added t:cssDecode transformation to decode CSS escapes.

* Now log XML parsing/validation warnings and errors to be in the debug
log at levels 3 and 4, respectivly.


thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.7-rc1 Available

[Brian R. <Bri...@br...>]

ModSecurity 2.5.7 will contain quite a few fixes for some not-so-common
issues.  The first release candidate for 2.5.7 is available so that
those that are seeing these issues can first verify that they are indeed
fixed prior to an official 2.5.7 release.

To help use in the future, it would be nice to know if these release
candidates are useful.  Please send me a note (privately) with a comment
on how useful you think the release candidates are and how (and if) you
are using them.

If you are seeing any of the following issues (even if you previously
tested a patch), then please verify that 2.5.7-rc1 does indeed correct
the issue:

1) Cannot turn off the request body limit check.  This release allows
you to use ctl:requestBodyAccess=off and/or ctl:ruleEngine=off in
phase:1 so that you can selectively bypass this check.

2) Some XML issues were difficult (impossible?) to diagnose as the
underlying XML error/warning was not logged.  All XML processing errors
and warnings are now logged to the debug log (if level is high enough).

3) XML DTD/Schema validation still succeeded when the XML was not well
formed, but could still be parsed.  This is corrected and the validation
will fail on any request parsing errors.

4) The hostname logged in the error log is the canonical name, not the
request supplied name.  This makes sure that there is always a hostname
in the log entry.

5) The REQUEST_BODY variable was not available unless you forced the use
of URLENCODED processor.  This would cause parsing to fail if it was not
a url encoded POST.  You can now use ctl:forceRequestBodyVariable=on to
force populating the REQUEST_BODY variable without setting the processor
and thus avoiding the parsing errors.

6) Certain "legacy" protocols have been ported to be tunneled in HTTP
request.  Some of these requests use the 8th bit of each byte as a
parity bit.  This can cause problems when trying to perform matches on
the data.  It is now possible to transform (t:parityEven7bit,
t:parityOdd7bit) or remove (t:parityZero7bit) the parity.


Packages can be downloaded from modsecurity.org as always.


The complete change log is below...

17 Sep 2008 - 2.5.7-rc1
-----------------------

* Fixed XML DTD/Schema validation which will now fail after request body
  processing errors, even if the XML parser returns a document tree.

* Added ctl:forceRequestBodyVariable=on|off which, when enabled, will
force the REQUEST_BODY variable to be set when a request body processor
is not set. Previously the REQUEST_BODY target was only populated by the
URLENCODED request body processor.

* Integrated mlogc source.

* Fixed logging the hostname in the error_log which was logging the
request hostname instead of the Apache resolved hostname.

* Allow for disabling request body limit checks in phase:1.

* Added transformations for processing parity for legacy protocols
ported to HTTP(S): t:parityEven7bit, t:parityOdd7bit, t:parityZero7bit

* Added t:cssDecode transformation to decode CSS escapes.

* Now log XML parsing/validation warnings and errors to be in the debug
log at levels 3 and 4, respectivly.


thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.6 and Mlogc

[Brian R. <Bri...@br...>]

The ModSecurity Log Collector (mlogc) is used to send ModSecurity audit 
log data to a console or Breach Security appliance.  The final packaged 
release of ModSecurity 2.5.6 did not contain the mlogc source as it 
should have.  This means that a "make mlogc" will fail.  However, the 
mlogc source is also packaged separately and can be downloaded from 
Breach Labs (https://bsn.breach.com/downloads/mlogc/).  Please use the 
source from Breach Labs to build mlogc until the next release of 
ModSecurity.

-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.6 Regression Testing Suite

[Brian R. <Bri...@br...>]

Starting with ModSecurity 2.5.6, I have packaged in the regression suite 
I use prior to releases.  I encourage all packagers to execute this 
suite before publicly releasing packages.

The suite is executed via "make test-regression" and must be performed 
*after* ModSecurity is installed (make install) as the suite repeatedly 
loads the Apache web server it was compiled against (on localhost:8088) 
with various configurations in which requests are submitted and 
responses/logs are validated.  Apache httpd, perl and libwww-perl (LWP 
module) is required to execute the tests.

Please let me know if there are questions/problems/concerns running the 
regression suite.

thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.6 Released

[Brian R. <Bri...@br...>]

ModSecurity 2.5.6 was released earlier today.  This is a major bugfix 
release that  fixes issues associated with transformation caching which 
may result in an Apache crash or possibly evading ModSecurity under 
certain circumstances.  If you are using ModSecurity 2.5 you are advised 
to immediately apply a workaround and upgrade as soon as possible.

Packages can be downloaded from modsecurity.org as always.

To work around these issues until you can upgrade, use the following 
directive to disable transformation caching:

SecCacheTransformations Off


31 Jul 2008 - 2.5.6
-------------------

  * Transformation caching has been deprecated, and is now off by 
default. We now advise against using transformation caching in production.

  * Fixed two separate transformation caching issues that could cause 
incorrect content inspection in some circumstances.

  * Fixed an issue with the transformation cache using too much RAM, 
potentially crashing Apache with a large number of cache entries. Two 
new configuration options have been added to allow for a finer control 
of caching:

      maxitems: Max number of items to cache (default 1024)
      incremental: Whether to cache incrementally (default off)

  * Added an experimental regression testing suite. The regression suite 
may be executed via "make test-regression", however it is strongly 
advised to only be executed on a non-production machine as it will 
startup the Apache web server that ModSecurity is compiled against with 
various configurations in which it will run tests.

  * Added a licensing exception so that ModSecurity can be used in a 
derivative work when that derivative is also under an approved open 
source license.

  * Updated mlogc to version 1.4.5 which adds a LockFile directive and 
fixes an issue in which the configuration file may be deleted.


-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.5 Debian packages

[Alberto G. I. <ag...@in...>]

Hi All,

Packages for ModSecurity 2.5.5 are now available at my repository (i386
and amd64 for the moment).

Packages for sid/lenny can be obtained adding the following line to your
sources.list:
deb http://etc.inittab.org/~agi/debian/libapache-mod-security2/2.5.x ./

For Etch (stable) use this line in your sources.list:
deb http://etc.inittab.org/~agi/debian/libapache-mod-security2/2.5.x/etch ./

Cheers,

Alberto

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
agi@(inittab.org|debian.org)| en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

[mod-security-packagers] ModSecurity 2.5.5 Released

[Brian R. <Bri...@br...>]

Hello all,

ModSecurity 2.5.5 was released.  This release contains a number of
important fixes.  It is highly recommended that all current 2.5 users
upgrade to 2.5.5.

Packages can be downloaded from modsecurity.org as always.


05 Jun 2008 - 2.5.5
-------------------

* Fixed an issue where an alert was not logged in the error log
  unless "auditlog" was used.

* Enable the "auditlog" action by default to help prevent a
  misconfiguration. The new default is now: "phase:2,log,auditlog,pass"

* Improve request body processing error messages.

* Handle lack of a new line after the final boundary in a multipart
  request. This fixes the reported WordPress Flash file uploader
  problem.

* Fixed issue with multithreaded servers where concurrent XML processing
  could crash the web server (at least under Windows).

* Fixed blocking in phase 3.

* Force modules "mod_rpaf-2.0.c" and "mod_custom_header.c" to run before
  ModSecurity so that the correct IP is used.

-B

-- 
Brian Rectanus
Breach Security

Re: [mod-security-packagers] [mod-security-users] ModSecurity 2.5.4 Released

[Brian R. <Bri...@br...>]

Brian Rectanus wrote:
> Hello all,
> 
> ModSecurity 2.5.4 was released.  This fixes a problem with
> transformation caching in ModSecurity 2.5 through version 2.5.3.
> 
> Transformation Caching Issue Details:
> 
> If you are using a transformation in SecDefaultAction and t:none in a
> rule, then there is the potential for the rule to use the wrong cached
> value (the default transformation value), possibly resulting in a false
> negative (no match).  The Core Rules v1.6 do not require a default
> transformation, but there is a potential for a false negative if a
> default transformation is defined.  Upgrading to 2.5.4 is encouraged,
> however, workarounds are available until an upgrade is possible.
> 
> Workarounds for Transformation Caching Issue in 2.5.0-2.5.3:
> 
> 1) (recommended) Disable transformation caching until you can upgrade to
> 2.5.4 with:
> 
>    SecCacheTransformations Off
> 
> 2) Remove any default transformations in SecDefaultAction if other rules
> are not depending on them.
> 
> Packages can be downloaded from modsecurity.org as always.
> 
> -B
> 

I just wanted to clarify that the workarounds were *either* 1 *or* 2 and
both are not required.

thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.4 Released

[Brian R. <Bri...@br...>]

Hello all,

ModSecurity 2.5.4 was released.  This fixes a problem with
transformation caching in ModSecurity 2.5 through version 2.5.3.

Transformation Caching Issue Details:

If you are using a transformation in SecDefaultAction and t:none in a
rule, then there is the potential for the rule to use the wrong cached
value (the default transformation value), possibly resulting in a false
negative (no match).  The Core Rules v1.6 do not require a default
transformation, but there is a potential for a false negative if a
default transformation is defined.  Upgrading to 2.5.4 is encouraged,
however, workarounds are available until an upgrade is possible.

Workarounds for Transformation Caching Issue in 2.5.0-2.5.3:

1) (recommended) Disable transformation caching until you can upgrade to
2.5.4 with:

   SecCacheTransformations Off

2) Remove any default transformations in SecDefaultAction if other rules
are not depending on them.

Packages can be downloaded from modsecurity.org as always.

-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.3, Core Rules 1.6.1 and ModSecurity Console 1.0.4 Released

[Brian R. <Bri...@br...>]

Hello all,

ModSecurity 2.5.3 was released today with Core Rules 1.6.1.  ModSecurity
fixes a few minor issues, however the Core Rules fixed a number of
issues which may miss detection.  Please consider the upgrade to Core
Rules 1.6.1 a required upgrade if you are currently running 1.6.0.
While you should keep up-to-date with ModSecurity releases, 2.5.3 is not
required unless you are running into the issues that have been fixed.

24 Apr 2008 - 2.5.3
-------------------

 * Fixed issue where the exec action may not be able to execute
   shell scripts.
 * Macros are now expanded in expirevar and deprecatevar.
 * Fixed crash if a persistent variable name was more than 126
   characters.
 * Updated included Core Ruleset to version 1.6.1 which fixes
   some false negative issues in the migration to using some
   2.5 features.

Additionally, the ModSecurity Console v1.0.4 was released to fix a minor
 issue when upgrading from the 1.0.2 version.

Packages can be downloaded from modsecurity.org as always.

-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.1.7 and 2.5.2 Released

[Brian R. <Bri...@br...>]

Hello all,

I have two new ModSecurity releases today.  These are both minor bugfix
releases.  In addition to the ModSecurity changes below, the mlogc
source was missing from the 2.5.1 package and is back in the 2.5.2
release.  As always, you can get the source from modsecurity.org.

02 Apr 2008 - 2.1.7
-------------------
 * Make sure temporary filehandles are closed after a transaction.

02 Apr 2008 - 2.5.2
-------------------
 * Allow HTTP_* targets as an alias for REQUEST_HEADERS:*.
 * Make sure temporary filehandles are closed after a transaction.
 * Make sure the apache include directory is included during build.


-B

-- 
Brian Rectanus
Breach Security

Re: [mod-security-packagers] [mod-security-users] ModSecurity 2.5.1 now available

[Steffen <in...@ap...>]

Windows binary for Apache 2.2 is available at http://www.apachelounge.com/
(build with Visual Studio 2008).

Steffen




----- Original Message ----- 
From: "Brian Rectanus" <Bri...@br...>
To: "Mod Security" <mod...@li...>; "Mod 
Packagers" <mod...@li...>
Sent: Monday, 17 March, 2008 18:47
Subject: [mod-security-users] ModSecurity 2.5.1 now available


> ModSecurity 2.5.1 is now available.  This release fixes an
> issue with the new transformation cache, a 2.1 rule compatibility issue
> and some other minor build-related issues.
>
> There is an issue in 2.5.0 where it is possible for a matching rule to
> not completely trigger when using the transformation cache (default is
> On) with either the "pass" action or the engine in "DetectionOnly" mode.
> The Core Rules 1.6 that are distributed with ModSecurity 2.5 use "pass"
> rules to pre-qualify some more complex regex rules and these may fail to
> detect a problem when transformation caching is on.  It is therefor
> advised that current 2.5.0 users add the following to their
> configuration as a temporary workaround until the the 2.5.1 release
> can be installed to resolve this issue:
>
> SecCacheTransformations Off
>
>
>
> 14 Mar 2008 - 2.5.1
> -------------------
>
> * Fixed an issue where a match would not occur if
>   transformation caching was enabled.
>
> * Using "severity" in a default action is now just a warning.
>
> * Cleaned up the "make test" target to better locate headers/libraries.
>
> * Now search /usr/lib64 and /usr/lib32 for lua libs.
>
> * No longer treat warnings as errors by default
>   (use --enable-strict-compile).
>
> -- 
> Brian Rectanus
> Breach Security
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 

[mod-security-packagers] ModSecurity 2.5.1 now available

[Brian R. <Bri...@br...>]

ModSecurity 2.5.1 is now available.  This release fixes an
issue with the new transformation cache, a 2.1 rule compatibility issue
and some other minor build-related issues.

There is an issue in 2.5.0 where it is possible for a matching rule to
not completely trigger when using the transformation cache (default is
On) with either the "pass" action or the engine in "DetectionOnly" mode.
 The Core Rules 1.6 that are distributed with ModSecurity 2.5 use "pass"
rules to pre-qualify some more complex regex rules and these may fail to
detect a problem when transformation caching is on.  It is therefor
advised that current 2.5.0 users add the following to their
configuration as a temporary workaround until the the 2.5.1 release
can be installed to resolve this issue:

SecCacheTransformations Off



14 Mar 2008 - 2.5.1
-------------------

 * Fixed an issue where a match would not occur if
   transformation caching was enabled.

 * Using "severity" in a default action is now just a warning.

 * Cleaned up the "make test" target to better locate headers/libraries.

 * Now search /usr/lib64 and /usr/lib32 for lua libs.

 * No longer treat warnings as errors by default
   (use --enable-strict-compile).

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.1-rc1 and Workaround for an issue in 2.5.0

[Brian R. <Bri...@br...>]

ModSecurity 2.5.1-rc1 is now available.  This release candidate fixes an
issue with the new transformation cache, a rule compatibility issue and
some other minor build-related issues.

There is an issue in 2.5.0 where it is possible for a matching rule to
not completely trigger when using the transformation cache (default is
On) with either the "pass" action or the engine in "DetectionOnly" mode.
 The Core Rules 1.6 that are distributed with ModSecurity 2.5 use "pass"
rules to pre-qualify some more complex regex rules and these may fail to
detect a problem when transformation caching is on.  It is therefor
advised that current 2.5.0 users add the following to their
configuration as a temporary workaround until the official 2.5.1 release
can be installed to resolve this issue:

SecCacheTransformations Off



07 Mar 2008 - 2.5.1-rc1
-----------------------

 * Fixed an issue where a match would not occur if
   transformation caching was enabled.

 * Using "severity" in a default action is now just a warning.

 * Cleaned up the "make test" target to better locate headers/libraries.

 * Now search /usr/lib64 and /usr/lib32 for lua libs.

 * No longer treat warnings as errors by default
   (use --enable-strict-compile).


-- 
Brian Rectanus
Breach Security

[mod-security-packagers] [PROPOSAL] make mod_security2 more independent from external libs

[Guenter K. <ef...@gm...>]

Hi Ivan, Brian,
while before version 2.0 mod_security compiled fine idenpendently from other
libs, with 2.0 there was pcre dependency added, and now with 2.5 I see also a
dependency on libxml2. While I have no problems with that in first place
since I've ported libxml2 already long ago for Netware, and its available
for Win32 too, nevertheless I think these dependencies can probably avoided.

Apache 2.x comes with its own XML implementation based on Expat, and also
has its own wrapper around pcre.
Other than on Linux with NetWare and Win32 platform there's not each and every
symbol exported, but instead you have to tell the linker what to export.
Therefore I need to compile the pcre.c with mod_security in order get the needed
functions in. It would be nice if you could consider to change mod_security to use
the APIs which are exported by Apache 2.x to avoid this unnecessary inclusion of
pcre.c itself.
Then it would also be nice if you could check if the Apache2 XML implementation
found in apr-util is sufficient for what mod_security needs, and then change this
too to use the exported APIs.

I believe that only depending on Apache2 / APR / APR-UTIL would make mod_security
more user/admin-friendly.

greets, Guenter.

[mod-security-packagers] ModSecurity 2.5.0 released

[Brian R. <Bri...@br...>]

The final version of ModSecurity 2.5.0 is now available!  Please take a
look at the modsecurity.org site for more details.  While your there,
read the docs and download the release.

http://www.modsecurity.org/blog/

thanks,
-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.1.6 released

[Brian R. <Bri...@br...>]

ModSecurity version 2.1.6 is now available.  This release contains four
backports from the 2.5 branch.  As always, you can get the release from
the modsecurity.org web site.

-B

-- 
Brian Rectanus
Breach Security

[mod-security-packagers] ModSecurity 2.5.0-rc4 Released

[Brian R. <Bri...@br...>]

ModSecurity 2.5.0-rc4 is now available.  This release fixes some issues
found when building on Windows.  Thanks go to Tom and Steffen over at
Apache Lounge for getting me some feedback and building the binaries for
Windows.

-B

-- 
Brian Rectanus
Breach Security