Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1037226: libnginx-mod-http-modsecurity fails to start after update libmodsecurity3 to v3.0.9
378 views
Skip to first unread message
Daniel Suchy
Jun 8, 2023, 8:00:04 AM6/8/23
to
Package: libnginx-mod-http-modsecurity
Version: 1.0.3-1+b1
libmodsecurity3 was upgraded to version v3.0.9 and after that, nginx
integration/module fails to start:
[emerg] 348194#348194: dlopen()
"/usr/share/nginx/modules/ngx_http_modsecurity_module.so" failed
(/usr/share/nginx/modules/ngx_http_modsecurity_module.so: undefined
symbol: pcre_malloc) in
/etc/nginx/modules-enabled/50-mod-http-modsecurity.conf:1
That happened on debian/bookworm with libmodsecurity3 (3.0.9-1) and
libnginx-mod-http-modsecurity (1.0.3-1+b1) packages provided here.
Downgrade to 3.0.8-1 is working work-around. Between versions 3.0.8-1
and 3.0.9-1, there was removed debian-specific patch
(patches/pcrem4.patch), as I noticed - maybe this is cause of this issue.
Version: 1.0.3-1+b1
libmodsecurity3 was upgraded to version v3.0.9 and after that, nginx
integration/module fails to start:
[emerg] 348194#348194: dlopen()
"/usr/share/nginx/modules/ngx_http_modsecurity_module.so" failed
(/usr/share/nginx/modules/ngx_http_modsecurity_module.so: undefined
symbol: pcre_malloc) in
/etc/nginx/modules-enabled/50-mod-http-modsecurity.conf:1
That happened on debian/bookworm with libmodsecurity3 (3.0.9-1) and
libnginx-mod-http-modsecurity (1.0.3-1+b1) packages provided here.
Downgrade to 3.0.8-1 is working work-around. Between versions 3.0.8-1
and 3.0.9-1, there was removed debian-specific patch
(patches/pcrem4.patch), as I noticed - maybe this is cause of this issue.
Ervin Hegedüs
Jun 8, 2023, 9:10:05 AM6/8/23
to
Hi Daniel,
thanks for reporting.
On Thu, Jun 08, 2023 at 01:47:55PM +0200, Daniel Suchy wrote:
> Package: libnginx-mod-http-modsecurity
> Version: 1.0.3-1+b1
>
> libmodsecurity3 was upgraded to version v3.0.9 and after that, nginx
> integration/module fails to start:
>
> [emerg] 348194#348194: dlopen()
> "/usr/share/nginx/modules/ngx_http_modsecurity_module.so" failed
> (/usr/share/nginx/modules/ngx_http_modsecurity_module.so: undefined symbol:
> pcre_malloc) in /etc/nginx/modules-enabled/50-mod-http-modsecurity.conf:1
>
> That happened on debian/bookworm with libmodsecurity3 (3.0.9-1) and
> libnginx-mod-http-modsecurity (1.0.3-1+b1) packages provided here.
I can confirm this behavior.
Unfortunately when the package was uploaded (2023-01-22) [1] and
migrated into testing, both Nginx and previous libmodsecurity3
(3.0.8) used the "old" PCRE library.
Meanwhile Nginx upgraded, and we bumped the PCRE version in the
libmodsecurity3 too.
This is the reason.
> Downgrade to 3.0.8-1 is working work-around. Between versions 3.0.8-1 and
> 3.0.9-1, there was removed debian-specific patch (patches/pcrem4.patch), as
> I noticed - maybe this is cause of this issue.
There is an other workaround too: re-compile the package.
Before the steps below you have to remove the currently installed
module:
sudo dpkg -r libnginx-mod-http-modsecurity
and upgrade libmodsecurity3
sudo apt install libmodsecurity3
Then try to rebuild the package from source:
sudo apt install libnginx-mod-http-ndk-dev nginx-dev
mkdir -f ~/tmp
cd ~/tmp
apt source libnginx-mod-http-modsecurity
cd libnginx-mod-http-modsecurity-1.0.3/
dpkg-buildpackage -us -uc
sudo dpkg -i libnginx-mod-http-modsecurity_1.0.3-1_amd64.deb
Now be sure that the module is enabled:
ls -1 /etc/nginx/modules-enabled/
10-mod-http-ndk.conf
50-mod-http-modsecurity.conf
and check that the WAF is "on" and the log level is "info"
at least:
nl -ba /etc/nginx/nginx.conf
1 user www-data;
2 worker_processes auto;
3 pid /run/nginx.pid;
4 error_log /var/log/nginx/error.log info;
...
...
58
59 modsecurity on;
60
61 include /etc/nginx/conf.d/*.conf;
62 include /etc/nginx/sites-enabled/*;
...
Now after the restart you have to see that the engine is active:
sudo /etc/init.d/nginx restart
sudo systemctl status nginx.service
...
jún 08 14:59:16 debian-test nginx[4604]: 2023/06/08 14:59:16 [notice] 4604#4604: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/0/0)
jún 08 14:59:16 debian-test nginx[4605]: 2023/06/08 14:59:16 [notice] 4605#4605: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/0/0)
...
Please let me know if you can fix that with this workaround -
then I'm going top open a ticket for asking rebuild of the
module.
Thanks again.
a.
1: https://tracker.debian.org/pkg/libnginx-mod-http-modsecurity
thanks for reporting.
On Thu, Jun 08, 2023 at 01:47:55PM +0200, Daniel Suchy wrote:
> Package: libnginx-mod-http-modsecurity
> Version: 1.0.3-1+b1
>
> libmodsecurity3 was upgraded to version v3.0.9 and after that, nginx
> integration/module fails to start:
>
> [emerg] 348194#348194: dlopen()
> "/usr/share/nginx/modules/ngx_http_modsecurity_module.so" failed
> (/usr/share/nginx/modules/ngx_http_modsecurity_module.so: undefined symbol:
> pcre_malloc) in /etc/nginx/modules-enabled/50-mod-http-modsecurity.conf:1
>
> That happened on debian/bookworm with libmodsecurity3 (3.0.9-1) and
> libnginx-mod-http-modsecurity (1.0.3-1+b1) packages provided here.
Unfortunately when the package was uploaded (2023-01-22) [1] and
migrated into testing, both Nginx and previous libmodsecurity3
(3.0.8) used the "old" PCRE library.
Meanwhile Nginx upgraded, and we bumped the PCRE version in the
libmodsecurity3 too.
This is the reason.
> Downgrade to 3.0.8-1 is working work-around. Between versions 3.0.8-1 and
> 3.0.9-1, there was removed debian-specific patch (patches/pcrem4.patch), as
> I noticed - maybe this is cause of this issue.
Before the steps below you have to remove the currently installed
module:
sudo dpkg -r libnginx-mod-http-modsecurity
and upgrade libmodsecurity3
sudo apt install libmodsecurity3
Then try to rebuild the package from source:
sudo apt install libnginx-mod-http-ndk-dev nginx-dev
mkdir -f ~/tmp
cd ~/tmp
apt source libnginx-mod-http-modsecurity
cd libnginx-mod-http-modsecurity-1.0.3/
dpkg-buildpackage -us -uc
sudo dpkg -i libnginx-mod-http-modsecurity_1.0.3-1_amd64.deb
Now be sure that the module is enabled:
ls -1 /etc/nginx/modules-enabled/
10-mod-http-ndk.conf
50-mod-http-modsecurity.conf
and check that the WAF is "on" and the log level is "info"
at least:
nl -ba /etc/nginx/nginx.conf
1 user www-data;
2 worker_processes auto;
3 pid /run/nginx.pid;
4 error_log /var/log/nginx/error.log info;
...
...
58
59 modsecurity on;
60
61 include /etc/nginx/conf.d/*.conf;
62 include /etc/nginx/sites-enabled/*;
...
Now after the restart you have to see that the engine is active:
sudo /etc/init.d/nginx restart
sudo systemctl status nginx.service
...
jún 08 14:59:16 debian-test nginx[4604]: 2023/06/08 14:59:16 [notice] 4604#4604: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/0/0)
jún 08 14:59:16 debian-test nginx[4605]: 2023/06/08 14:59:16 [notice] 4605#4605: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/0/0)
...
Please let me know if you can fix that with this workaround -
then I'm going top open a ticket for asking rebuild of the
module.
Thanks again.
a.
1: https://tracker.debian.org/pkg/libnginx-mod-http-modsecurity
Daniel Suchy
Jun 8, 2023, 2:50:04 PM6/8/23
to
Hi,
On 6/8/23 15:02, Ervin Hegedüs wrote:
> There is an other workaround too: re-compile the package.
>
confirm rebuilding libnginx-mod-http-modsecurity package on updated
bookworm system is working solution.
- Daniel
On 6/8/23 15:02, Ervin Hegedüs wrote:
> There is an other workaround too: re-compile the package.
>
> Please let me know if you can fix that with this workaround -
> then I'm going top open a ticket for asking rebuild of the
> module.
>
yes, that's another option, I tried it on my test system and I can
> then I'm going top open a ticket for asking rebuild of the
> module.
>
confirm rebuilding libnginx-mod-http-modsecurity package on updated
bookworm system is working solution.
- Daniel
Ervin Hegedüs
Jun 8, 2023, 3:20:05 PM6/8/23
to
Hi,
On Thu, Jun 08, 2023 at 08:34:00PM +0200, Paul Gevers wrote:
> >
> > sure, but the package itself has not changed. I think without
> > tests we could't have discovered this.
>
> Sure. That's very common with c-libraries that change their ABI but not
> their API. The SONAME of the library gets bumped, the package maintainer
> ships a new binary package (which matches the SONAME), our tooling detects
> that and we can schedule rebuilds. You *seem* to be in a similar situation,
> except there was no SONAME bump involved, our tooling didn't detect it and
> everything went unnoticed until now.
I see,
> I guess
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html and maybe https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries
> can be good reads.
thanks, I'm going to review these.
> > libnginx-mod-http-modsecurity uses one of the PCRE packages: the
> > OLD PCRE, or the NEW, PCRE2 library.
> >
> > This is decided when we compile the source.
>
> Again sounds not uncommon. But apparently either nginx or libmodsecurity3
> changed it's ABI as a result of that, which broke the reverse dependencies
> that weren't rebuild.
I understand.
> > As I wrote above, libnginx-mod-http-modsecurity does not have any
> > control options to decide which PCRE version wants to use, but
> > during the compile time it sets the symbols. >
> > This is why it compiled to use the OLD PCRE, but not the Nginx,
> > neither the libmodsecurity3 don't use it.
> >
> > Hope now it's clear - let me know if I can help you in this.
>
> I'm not a library expert, but this really, really looks wrong to me.
do you have any opinion, how could be it fixed? I do not
participate in development of Nginx, but in libmodsecurity3. Is
there anything what we can do there?
> > > Raise the severity of the bug and document it in the release notes.
> >
> > Sorry for the dumb question, but in which release notes do I need
> > to document?
>
> https://www.debian.org/releases/bookworm/releasenotes which has its source
> here: https://salsa.debian.org/ddp-team/release-notes/
thanks,
> > uhm, that's a bad news.
> >
> > How can we fix it in unstable?
>
> Figure out what went wrong. I expect a new library package needs to be
> uploaded (please use experimental for that). Once that's done, a transition
> can be requested, see https://wiki.debian.org/Teams/ReleaseTeam/Transitions
many thanks.
> > Because it is decided at compile time.
>
> One the transition is ACK'ed the rebuild will be scheduled by the release
> team.
okay.
> > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/CHANGES#L6
> > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L41
> >
> > The ABI isn't changed, but the code itself was aligned to
> > Nginx.
>
> I a symbol is dropped, that means a break in the ABI.
ah, I think I see the point now.
> > I guess you remember my last e-mail in connection with
> > libapache2-mod-security issue:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037024
> >
> > This situation is similar: there is a dependency (there: libapr1,
> > here: Nginx), which changed the version since the affected
> > package (there: modsecurity-apache, here:
> > libnginx-mod-http-modsecurity) but here the dependent package
> > changed the 3rd-party library, which has a hard effect for the
> > package in subject.
>
> That situation was different (at least from the symptoms). The problem there
> was that it was emitting a *warning*, nothing broke. The warning is bad but
> not a real problem. Missing symbols is a problem.
sure, I got it.
> > I hope I could help to understand the situation.
>
> I hope you can figure out more what's wrong. We can't really fix it properly
> otherwise.
yes, now I see - many thanks for your help.
a.
On Thu, Jun 08, 2023 at 08:34:00PM +0200, Paul Gevers wrote:
> >
> > sure, but the package itself has not changed. I think without
> > tests we could't have discovered this.
>
> Sure. That's very common with c-libraries that change their ABI but not
> their API. The SONAME of the library gets bumped, the package maintainer
> ships a new binary package (which matches the SONAME), our tooling detects
> that and we can schedule rebuilds. You *seem* to be in a similar situation,
> except there was no SONAME bump involved, our tooling didn't detect it and
> everything went unnoticed until now.
I see,
> I guess
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html and maybe https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries
> can be good reads.
thanks, I'm going to review these.
> > libnginx-mod-http-modsecurity uses one of the PCRE packages: the
> > OLD PCRE, or the NEW, PCRE2 library.
> >
> > This is decided when we compile the source.
>
> Again sounds not uncommon. But apparently either nginx or libmodsecurity3
> changed it's ABI as a result of that, which broke the reverse dependencies
> that weren't rebuild.
I understand.
> > As I wrote above, libnginx-mod-http-modsecurity does not have any
> > control options to decide which PCRE version wants to use, but
> > during the compile time it sets the symbols. >
> > This is why it compiled to use the OLD PCRE, but not the Nginx,
> > neither the libmodsecurity3 don't use it.
> >
> > Hope now it's clear - let me know if I can help you in this.
>
> I'm not a library expert, but this really, really looks wrong to me.
do you have any opinion, how could be it fixed? I do not
participate in development of Nginx, but in libmodsecurity3. Is
there anything what we can do there?
> > > Raise the severity of the bug and document it in the release notes.
> >
> > Sorry for the dumb question, but in which release notes do I need
> > to document?
>
> https://www.debian.org/releases/bookworm/releasenotes which has its source
> here: https://salsa.debian.org/ddp-team/release-notes/
thanks,
> > uhm, that's a bad news.
> >
> > How can we fix it in unstable?
>
> Figure out what went wrong. I expect a new library package needs to be
> uploaded (please use experimental for that). Once that's done, a transition
> can be requested, see https://wiki.debian.org/Teams/ReleaseTeam/Transitions
many thanks.
> > Because it is decided at compile time.
>
> One the transition is ACK'ed the rebuild will be scheduled by the release
> team.
okay.
> > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/CHANGES#L6
> > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L41
> >
> > The ABI isn't changed, but the code itself was aligned to
> > Nginx.
>
> I a symbol is dropped, that means a break in the ABI.
ah, I think I see the point now.
> > I guess you remember my last e-mail in connection with
> > libapache2-mod-security issue:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037024
> >
> > This situation is similar: there is a dependency (there: libapr1,
> > here: Nginx), which changed the version since the affected
> > package (there: modsecurity-apache, here:
> > libnginx-mod-http-modsecurity) but here the dependent package
> > changed the 3rd-party library, which has a hard effect for the
> > package in subject.
>
> That situation was different (at least from the symptoms). The problem there
> was that it was emitting a *warning*, nothing broke. The warning is bad but
> not a real problem. Missing symbols is a problem.
sure, I got it.
> > I hope I could help to understand the situation.
>
> I hope you can figure out more what's wrong. We can't really fix it properly
> otherwise.
yes, now I see - many thanks for your help.
a.
Ronny Forberger
Jun 23, 2023, 6:10:04 AM6/23/23
to
Is there already a plan when it will be fixed?
Best regards,
Ronny Forberger
Ervin Hegedüs
Jun 23, 2023, 6:20:05 AM6/23/23
to
Hi,
as the previous message says ("Prepare a fixed package for the first point release (after ensuring it's fixed in unstable)."), the next release will contain the fix.
If you need the updated version, you can compile it manually, or you can use the unofficial ModSecurity repository:
a.
Ronny Forberger
Jun 23, 2023, 6:30:06 AM6/23/23
to
Any estimation when this will happen?
Thanks.
Best regards,
Ronny Forberger
Ronny Forberger
Ervin Hegedüs
Jul 29, 2023, 8:20:04 AM7/29/23
to
Seems like this bug is fixed.
# apt install libnginx-mod-http-modsecurity --default-release bookworm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
libnginx-mod-http-modsecurity
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.4 kB of archives.
After this operation, 196 kB of additional disk space will be used.
Get:1 http://ftp.hu.debian.org/debian bookworm/main amd64 libnginx-mod-http-modsecurity amd64 1.0.3-1+b2 [25.4 kB]
Fetched 25.4 kB in 0s (331 kB/s)
Selecting previously unselected package libnginx-mod-http-modsecurity.
(Reading database ... 57140 files and directories currently installed.)
Preparing to unpack .../libnginx-mod-http-modsecurity_1.0.3-1+b2_amd64.deb ...
Unpacking libnginx-mod-http-modsecurity (1.0.3-1+b2) ...
Setting up libnginx-mod-http-modsecurity (1.0.3-1+b2) ...
Processing triggers for nginx (1.22.1-9) ...
Triggering nginx reload ...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
libnginx-mod-http-modsecurity
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.4 kB of archives.
After this operation, 196 kB of additional disk space will be used.
Get:1 http://ftp.hu.debian.org/debian bookworm/main amd64 libnginx-mod-http-modsecurity amd64 1.0.3-1+b2 [25.4 kB]
Fetched 25.4 kB in 0s (331 kB/s)
Selecting previously unselected package libnginx-mod-http-modsecurity.
(Reading database ... 57140 files and directories currently installed.)
Preparing to unpack .../libnginx-mod-http-modsecurity_1.0.3-1+b2_amd64.deb ...
Unpacking libnginx-mod-http-modsecurity (1.0.3-1+b2) ...
Setting up libnginx-mod-http-modsecurity (1.0.3-1+b2) ...
Processing triggers for nginx (1.22.1-9) ...
Triggering nginx reload ...
Jul 29 14:11:10 debian12 systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...
Jul 29 14:11:10 debian12 nginx[1600]: 2023/07/29 14:11:10 [notice] 1600#1600: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/921/0)
Jul 29 14:11:10 debian12 nginx[1600]: 2023/07/29 14:11:10 [notice] 1600#1600: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/921/0)
Can we close this issue?
a.
On Sat, Jul 15, 2023 at 2:51 PM Tobias Frost <to...@debian.org> wrote:
Control: tags -1 pending
Conrtol: block -1 by 1040799
This bug has been fixed in unstable with the binNMU 1.0.3-1b3, see #1040858
It is also scheduled to be fixed in the next stable-point-release, see #1040799
--
tobi
Daniel Suchy
Jul 29, 2023, 4:10:04 PM7/29/23
to
Hello,
I can confirm this, this issue can be closed.
- Daniel
On 7/29/23 14:13, Ervin Hegedüs wrote:
> Seems like this bug is fixed.
>
> # apt install libnginx-mod-http-modsecurity --default-release bookworm
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following NEW packages will be installed:
> libnginx-mod-http-modsecurity
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 25.4 kB of archives.
> After this operation, 196 kB of additional disk space will be used.
> Get:1 http://ftp.hu.debian.org/debian <http://ftp.hu.debian.org/debian>
I can confirm this, this issue can be closed.
- Daniel
On 7/29/23 14:13, Ervin Hegedüs wrote:
> Seems like this bug is fixed.
>
> # apt install libnginx-mod-http-modsecurity --default-release bookworm
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following NEW packages will be installed:
> libnginx-mod-http-modsecurity
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 25.4 kB of archives.
> After this operation, 196 kB of additional disk space will be used.
0 new messages