AliasMatch directive does not accept long URI

Bug #1534538 reported by Stanislas LEDUC on 2016-01-15
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Medium
Unassigned
Trusty
Medium
Wesley Wiedenmeier

Bug Description

[Impact]

When accessed long URI location that configured by AliasMatch directive,
Apache failed to allocate memory and process aborted.

It's same that https://bugzilla.redhat.com/show_bug.cgi?id=1120019.

This fixed in upstream, http://svn.apache.org/viewvc?view=revision&revision=1583175.
Can you please backports apache 2.4.10 from vivid or just fix in trusty ?
Thanks.

[Test Case]

Config:

ubuntu@ubuntu:/etc/apache2$ cat sites-available/alias.conf
<VirtualHost *:80>
   AliasMatch ^/alias-test/ /var/www/html/index.html
</VirtualHost>

With old apache:

ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/short_uri
<!doctype html>
<html>
<body>
<h1>TEST</h1>
</body>
</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/very_loooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooong_____uri
curl: (52) Empty reply from server
ubuntu@ubuntu:/etc/apache2$

With new apache:

ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/short_uri
<!doctype html>
<html>
<body>
<h1>TEST</h1>
</body>
</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/very_loooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooong_____uri
<!doctype html>
<html>
<body>
<h1>TEST</h1>
</body>
</html>

[Regression Potential]

There should be no regression potential for this patch, as it just removes an incorrect strlen check.

description: updated
Robie Basak (racb) on 2016-01-20
Changed in apache2 (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
tags: added: bitesize
Robie Basak (racb) on 2016-06-22
Changed in apache2 (Ubuntu):
assignee: nobody → Wesley Wiedenmeier (wesley-wiedenmeier)

Here is a debdiff to pull in the patch from upstream. I am testing it right now and should be able to confirm that it resolves the issue shortly.

Since there was no testcase in the description, here is the testcase from the bugzilla.redhat.com bug:

Steps to Reproduce:
# prepare test file.
echo "<html>hello</html>" > /var/www/html/index.html
# add config to apache
echo "AliasMatch ^/alias-test/ /var/www/html/index.html" > /etc/httpd/conf.modules.d/02-alias-test.conf
# (re)start httpd
systemctl restart httpd.service

Actual results:
# When I request short URI, the response is good as follow:
[takayuki@localhost ~]$ wget -t1 -O - -S -v http://127.0.0.1/alias-test/short_uri
--2014-07-16 14:04:38-- http://127.0.0.1/alias-test/short_uri
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Wed, 16 Jul 2014 05:04:38 GMT
  Server: Apache/2.4.9 (Fedora)
  Last-Modified: Wed, 16 Jul 2014 04:49:10 GMT
  ETag: "13-4fe483eb8a9d6"
  Accept-Ranges: bytes
  Content-Length: 19
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=UTF-8
Length: 19 [text/html]
Saving to: 'STDOUT'

 0% [ ] 0 --.-K/s <html>hello</html>
100%[=========================================================================================>] 19 --.-K/s in 0s

2014-07-16 14:04:38 (2.03 MB/s) - written to stdout [19/19]

# When I request log URI, the connection is closed and Apache logged error as follow:
[takayuki@localhost ~]$ wget -t1 -O - -S -v http://127.0.0.1/alias-test/very_looooooooooooooooooooooong_uri
--2014-07-16 14:07:40-- http://127.0.0.1/alias-test/very_looooooooooooooooooooooong_uri
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... No data received.
Giving up.

[root@localhost takayuki]# tail /var/log/httpd/error_log
[crit] Memory allocation failed, aborting process.
[Wed Jul 16 14:03:17.231921 2014] [core:notice] [pid 21808] AH00052: child pid 21809 exit signal Aborted (6)
[crit] Memory allocation failed, aborting process.
[Wed Jul 16 14:03:23.239149 2014] [core:notice] [pid 21808] AH00052: child pid 21812 exit signal Aborted (6)
[crit] Memory allocation failed, aborting process.
[Wed Jul 16 14:07:40.487959 2014] [core:notice] [pid 21808] AH00052: child pid 21945 exit signal Aborted (6)

The attachment "fix_aliasmatch_long_uri.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch

I confirm that the debdiff supplied does fix the bug. In case anyone wants to test it, there is a build of it here:

https://launchpad.net/~wesley-wiedenmeier/+archive/ubuntu/tmp

Test case used to verify:

Config:

ubuntu@ubuntu:/etc/apache2$ cat sites-available/alias.conf
<VirtualHost *:80>
   AliasMatch ^/alias-test/ /var/www/html/index.html
</VirtualHost>

With old apache:

ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/short_uri
<!doctype html>
<html>
<body>
<h1>TEST</h1>
</body>
</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/very_loooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooong_____uri
curl: (52) Empty reply from server
ubuntu@ubuntu:/etc/apache2$

With new apache:

ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/short_uri
<!doctype html>
<html>
<body>
<h1>TEST</h1>
</body>
</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/very_loooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooong_____uri
<!doctype html>
<html>
<body>
<h1>TEST</h1>
</body>
</html>

Changed in apache2 (Ubuntu):
status: Triaged → Fix Released
description: updated
Michael Hudson-Doyle (mwhudson) wrote :

Thank you for your contribution to Ubuntu!

The patch looks OK to me (although I had to rebase it onto the current patch in trusty-proposed). I've uploaded it to the trusty queue, although I imagine it won't get into trusty-proposed until the current package there completes verification (which should be soon).

Can you fill out the [regression potential] section of the description?

Changed in apache2 (Ubuntu Trusty):
status: New → In Progress

Hi,

Thanks for reviewing the patch, sorry I didn't notice the pending one in trusty proposed.
There should be no regression potential for this patch, as it just removes an incorrect strlen check.

I will update the debdiff with the regression potential field set and based on the pending apache in trusty-proposed and have it posted here this afternoon.

Thanks

Hello Stanislas, or anyone else affected,

Accepted apache2 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apache2/2.4.7-1ubuntu4.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apache2 (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in apache2 (Ubuntu Trusty):
importance: Undecided → Medium
Mathew Hodson (mathew-hodson) wrote :

This SRU has been shadowed by a security update and needs to be re-merged.

Changed in apache2 (Ubuntu Trusty):
status: Fix Committed → Triaged
tags: removed: verification-needed
description: updated

I have rebased the patch on the newest version in trusty updates apache2_2.4.7-1ubuntu4.13, which includes the security fix. The updated debdiff is attached.

If anyone would like to test there is a .deb with the updated patch building in in the ppa at:
ppa:wesley-wiedenmeier/tmp

I will confirm that the new version of the patch works again once the package has built.

Changed in apache2 (Ubuntu):
assignee: Wesley Wiedenmeier (wesley-wiedenmeier) → nobody
Changed in apache2 (Ubuntu Trusty):
assignee: nobody → Wesley Wiedenmeier (wesley-wiedenmeier)
status: Triaged → In Progress

The updated package at version apache_2.4.7-1ubuntu4.14 does fix the issue for me:

/etc/apache2/sites-available/alias.conf:
<VirtualHost *:80>
    AliasMatch ^/alias-test/ /var/www/html/index.html
</VirtualHost>

/var/www/html/index.html:
<html>test</html>

With current apache in trusty-updates:
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/010203040506070809101112
<html>test</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/01020304050607080910111213
curl: (52) Empty reply from server

After update to apache 2.4.7-1ubuntu4.14:
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/010203040506070809101112
<html>test</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/01020304050607080910111213
<html>test</html>

Hi,

I'm back from holidays.
Its work like charm.

Use apache_2.4.7-1ubuntu4.14

Thanks Wesley for our patch and ubuntu team member.

Best regard.

Marc Deslauriers (mdeslaur) wrote :

ACK on the debdiff in comment #8, I've uploaded it to trusty for processing by the SRU team. Thanks!

Brian Murray (brian-murray) wrote :

Hello Stanislas, or anyone else affected,

Accepted apache2 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apache2/2.4.7-1ubuntu4.14 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apache2 (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed

Hi,

I reran the verification using the build in trusty-proposed, and it works nicely. Since I've verified twice and the original bug author has verified the build that was in my ppa earlier, which was identical to the one in trusty-proposed, I am confident that the version in trusty-proposed fixes the patch.

I'm going to mark verification-done.

Here's the verification from trusty proposed:

ubuntu@ubuntu:~$ apt-cache show apache2 | grep Version
  Version: 2.4.10-1ubuntu1.1~ubuntu14.04.1
  Version: 2.4.7-1ubuntu4.13
  Version: 2.4.7-1ubuntu4
ubuntu@ubuntu:/etc/apache2$ cat sites-enabled/alias.conf
  <VirtualHost *:80>
      AliasMatch ^/alias-test/ /var/www/html/index.html
  </VirtualHost>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/010203040506070809101112
  <html>test</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/01020304050607080910111213
  curl: (52) Empty reply from server

ubuntu@ubuntu:/etc/apache2$ apt-cache show apache2 | grep Version
  Version: 2.4.10-1ubuntu1.1~ubuntu14.04.1
  Version: 2.4.7-1ubuntu4.14
  Version: 2.4.7-1ubuntu4.13
  Version: 2.4.7-1ubuntu4
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/010203040506070809101112
  <html>test</html>
ubuntu@ubuntu:/etc/apache2$ curl localhost/alias-test/01020304050607080910111213
  <html>test</html>

tags: added: verification-done
removed: verification-needed
Brian Murray (brian-murray) wrote :

While the verification of this bug fix was successful, it looks like the changes have caused failures with the autopkgtest for puppet.

http://autopkgtest.ubuntu.com/packages/p/puppet/trusty/i386/
http://autopkgtest.ubuntu.com/packages/p/puppet/trusty/amd64/

Please investigate this matter.

tags: added: verification-failed
removed: verification-done

Hi,

After looking into the autopkgtest failure reported in the puppet logs, I am not sure if this is an error with puppet compatibility with apache or an issue with the autopkgtest test bed used for running the tests, as I had previously seen a failure (a slightly different one though), but am no longer able to. I currently can run the puppet autopkgtests on amd64 with no failures with -proposed enabled using the most recent trusty ephemeral '20161003_03:49'. A log of the a test run is attached.

In the log at http://autopkgtest.ubuntu.com/packages/p/puppet/trusty/amd64/ it looks like something went wrong when trying to install puppet, so that may be the cause of the failure:

  autopkgtest [21:49:22]: @@@@@@@@@@@@@@@@@@@@ apt-source puppet
  E: Command line option --only-source is not understood

Since I do not have a way to reproduce the test failure at the moment, I am not sure if I can resolve the issue.

Hi,

After looking into the autopkgtest failure reported in the puppet logs, I am not sure if this is an error with puppet compatibility with apache or an issue with the autopkgtest test bed used for running the tests, as I had previously seen a failure (a slightly different one though), but am no longer able to. I currently can run the puppet autopkgtests on amd64 with no failures with -proposed enabled using the most recent trusty ephemeral '20161003_03:49'. A log of the a test run is attached.

In the log at http://autopkgtest.ubuntu.com/packages/p/puppet/trusty/amd64/ it looks like something went wrong when trying to install puppet, so that may be the cause of the failure:

  autopkgtest [21:49:22]: @@@@@@@@@@@@@@@@@@@@ apt-source puppet
  E: Command line option --only-source is not understood

Since I do not have a way to reproduce the test failure at the moment, I am not sure if I can resolve the issue.

Hi,

After looking into the autopkgtest failure reported in the puppet logs, I am not sure if this is an error with puppet compatibility with apache or an issue with the autopkgtest test bed used for running the tests, as I had previously seen a failure (a slightly different one though), but am no longer able to. I currently can run the puppet autopkgtests on amd64 with no failures with -proposed enabled using the most recent trusty ephemeral '20161003_03:49'. A log of the a test run is attached.

In the log at http://autopkgtest.ubuntu.com/packages/p/puppet/trusty/amd64/ it looks like something went wrong when trying to install puppet, so that may be the cause of the failure:

  autopkgtest [21:49:22]: @@@@@@@@@@@@@@@@@@@@ apt-source puppet
  E: Command line option --only-source is not understood

Since I do not have a way to reproduce the test failure at the moment, I am not sure if I can resolve the issue.

Hi,

After looking into the autopkgtest failure reported in the puppet logs, I am not sure if this is an error with puppet compatibility with apache or an issue with the autopkgtest test bed used for running the tests, as I had previously seen a failure (a slightly different one though), but am no longer able to. I currently can run the puppet autopkgtests on amd64 with no failures with -proposed enabled using the most recent trusty ephemeral '20161003_03:49'. A log of the a test run is attached.

In the log at http://autopkgtest.ubuntu.com/packages/p/puppet/trusty/amd64/ it looks like something went wrong when trying to install puppet, so that may be the cause of the failure:

  autopkgtest [21:49:22]: @@@@@@@@@@@@@@@@@@@@ apt-source puppet
  E: Command line option --only-source is not understood

Since I do not have a way to reproduce the test failure at the moment, I am not sure if I can resolve the issue.

The version of apache2 in the proposed pocket of Trusty that was purported to fix this bug report has been removed because the bugs that were to be fixed by the upload were not verified in a timely (105 days) fashion.

Changed in apache2 (Ubuntu Trusty):
status: Fix Committed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments