Bug 10097

also, fix the %pretransinstall script in the rpm package; currently it is:

if [ ! -d /etc/httpd/conf/sites.d ]; then
    mkdir -p /etc/httpd/conf/sites.d
    if [ -d /etc/httpd/conf/webapps.d ]; then
        mv -f /etc/httpd/conf/webapps.d/* /etc/httpd/conf/sites.d 2>/dev/null
        rmdir /etc/httpd/conf/webapps.d
    fi
    if [ -d /etc/httpd/conf/vhosts.d ]; then
        mv -f /etc/httpd/conf/vhosts.d/* /etc/httpd/conf/sites.d 2>/dev/null
        rmdir /etc/httpd/conf/vhosts.d
    fi
fi

(it isn't run if /etc/httpd/conf/sites.d present along with old webapps.d or vhosts.d dirs; so those old dirs are not deleted and it conflicts with them being symlinks in new rpm )


it should be:

if [ -d /etc/httpd/conf/webapps.d ]; then
    if [ ! -d /etc/httpd/conf/sites.d ]; then
        mkdir -p /etc/httpd/conf/sites.d
    fi
    mv -f /etc/httpd/conf/webapps.d/* /etc/httpd/conf/sites.d 2>/dev/null
    rmdir /etc/httpd/conf/webapps.d
fi
if [ -d /etc/httpd/conf/vhosts.d ]; then
    if [ ! -d /etc/httpd/conf/sites.d ]; then
        mkdir -p /etc/httpd/conf/sites.d
    fi
    mv -f /etc/httpd/conf/vhosts.d/* /etc/httpd/conf/sites.d 2>/dev/null
    rmdir /etc/httpd/conf/vhosts.d
fi

CC: (none) => pablo

(sorry, disregard my previous comment, it was intended for 2.4.x version of the package)

Oden has uploaded a patched package for Mageia 2.

It fixes this issue, as well as a buffer overflow in htdigest (PR54893 upstream).

Oden, is this ready for QA, and do you have any notes on the second issue fixed?

I guess 2.4.x isn't affected?

Packages built:
apache-2.2.24-1.1.mga2
apache-mpm-prefork-2.2.24-1.1.mga2
apache-mpm-worker-2.2.24-1.1.mga2
apache-mpm-event-2.2.24-1.1.mga2
apache-mpm-itk-2.2.24-1.1.mga2
apache-mpm-peruser-2.2.24-1.1.mga2
apache-mod_dav-2.2.24-1.1.mga2
apache-mod_ldap-2.2.24-1.1.mga2
apache-mod_cache-2.2.24-1.1.mga2
apache-mod_disk_cache-2.2.24-1.1.mga2
apache-mod_mem_cache-2.2.24-1.1.mga2
apache-mod_file_cache-2.2.24-1.1.mga2
apache-mod_deflate-2.2.24-1.1.mga2
apache-mod_proxy-2.2.24-1.1.mga2
apache-mod_proxy_ajp-2.2.24-1.1.mga2
apache-mod_proxy_scgi-2.2.24-1.1.mga2
apache-mod_suexec-2.2.24-1.1.mga2
apache-mod_userdir-2.2.24-1.1.mga2
apache-mod_ssl-2.2.24-1.1.mga2
apache-mod_dbd-2.2.24-1.1.mga2
apache-mod_authn_dbd-2.2.24-1.1.mga2
apache-mod_reqtimeout-2.2.24-1.1.mga2
apache-htcacheclean-2.2.24-1.1.mga2
apache-devel-2.2.24-1.1.mga2
apache-source-2.2.24-1.1.mga2
apache-doc-2.2.24-1.1.mga2

from apache-2.2.24-1.1.mga2.src.rpm

PR 54893 is minor, but why not fix it anyway.

https://issues.apache.org/bugzilla/show_bug.cgi?id=54893
http://svn.apache.org/viewvc?view=revision&revision=1476242
 	
htdigest: Fix buffer overflow when reading digest password file with very long lines.

The CVE-2013-1862 flaw has not been fixed in 2.4.x from what I can see so far, so assuming it don't apply.

Thanks Oden.

Assigning to QA.

Advisory:
========================

Updated apache packages fix security vulnerabilities:

It was found that mod_rewrite did not filter terminal escape sequences from
its log file. If mod_rewrite was configured with the RewriteLog directive,
a remote attacker could use specially-crafted HTTP requests to inject
terminal escape sequences into the mod_rewrite log file. If a victim viewed
the log file with a terminal emulator, it could result in arbitrary command
execution with the privileges of that user (CVE-2013-1862).

A buffer overflow when reading digest password file with very long lines in
htdigest (PR54893).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1862
https://issues.apache.org/bugzilla/show_bug.cgi?id=54893
https://rhn.redhat.com/errata/RHSA-2013-0815.html
========================

Updated packages in core/updates_testing:
========================
apache-2.2.24-1.1.mga2
apache-mpm-prefork-2.2.24-1.1.mga2
apache-mpm-worker-2.2.24-1.1.mga2
apache-mpm-event-2.2.24-1.1.mga2
apache-mpm-itk-2.2.24-1.1.mga2
apache-mpm-peruser-2.2.24-1.1.mga2
apache-mod_dav-2.2.24-1.1.mga2
apache-mod_ldap-2.2.24-1.1.mga2
apache-mod_cache-2.2.24-1.1.mga2
apache-mod_disk_cache-2.2.24-1.1.mga2
apache-mod_mem_cache-2.2.24-1.1.mga2
apache-mod_file_cache-2.2.24-1.1.mga2
apache-mod_deflate-2.2.24-1.1.mga2
apache-mod_proxy-2.2.24-1.1.mga2
apache-mod_proxy_ajp-2.2.24-1.1.mga2
apache-mod_proxy_scgi-2.2.24-1.1.mga2
apache-mod_suexec-2.2.24-1.1.mga2
apache-mod_userdir-2.2.24-1.1.mga2
apache-mod_ssl-2.2.24-1.1.mga2
apache-mod_dbd-2.2.24-1.1.mga2
apache-mod_authn_dbd-2.2.24-1.1.mga2
apache-mod_reqtimeout-2.2.24-1.1.mga2
apache-htcacheclean-2.2.24-1.1.mga2
apache-devel-2.2.24-1.1.mga2
apache-source-2.2.24-1.1.mga2
apache-doc-2.2.24-1.1.mga2

from apache-2.2.24-1.1.mga2.src.rpm

Assignee: bugsquad => qa-bugs

Testing complete mga2 32

No PoC so just testing apache generally and mod_rewrite specifically works as expected.

Tested apache using webapps (eg. phpmyadmin, wordpress, drupal, etc)

Edited /etc/httpd/conf/httpd.conf and changed the section below to AllowOverride All

# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
#   Options FileInfo AuthConfig Limit Indexes

    AllowOverride None

Then restarted httpd
# service httpd restart

and followed this to test mod-rewrite:
http://www.webasyst.net/support/help/general-modrewrite-test.html

# cd /var/www/html
# mkdir mod_rewrite_test
# cd mod_rewrite_test

Create two files there .htaccess (don't miss the dot) and index.php with the following content..

.htaccess:

RewriteEngine On
RewriteRule ^.*$ index.php

index.php:

<?php
print 'mod_rewrite works!';
?>


Then browse to http://localhost/mod_rewrite_test/check

It should show 'mod_rewrite works!'

Testing Mageia 2 x86_64 shortly.

CC: (none) => davidwhodgins

Testing complete on Mageia 2 x86_64.

Could someone from the sysadmin team push the srpm
apache-2.2.24-1.1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates.

Advisory: Updated apache packages fix security vulnerabilities:

It was found that mod_rewrite did not filter terminal escape sequences from
its log file. If mod_rewrite was configured with the RewriteLog directive,
a remote attacker could use specially-crafted HTTP requests to inject
terminal escape sequences into the mod_rewrite log file. If a victim viewed
the log file with a terminal emulator, it could result in arbitrary command
execution with the privileges of that user (CVE-2013-1862).

A buffer overflow when reading digest password file with very long lines in
htdigest (PR54893).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1862
https://issues.apache.org/bugzilla/show_bug.cgi?id=54893
https://rhn.redhat.com/errata/RHSA-2013-0815.html

https://bugs.mageia.org/show_bug.cgi?id=10097

Keywords: (none) => validated_update
Whiteboard: has_procedure mga2-32-ok => has_procedure mga2-32-ok MGA2-64-OK
CC: (none) => sysadmin-bugs

Advisory 10097.adv ready to push

(In reply to Dave Hodgins from comment #9)
> Advisory 10097.adv ready to push

In the CVE list, what is PR54893 ?

It doesn't look like a CVE identifier.

CC: (none) => boklm

It's not a CVE, it's a reference to the upstream bug which is in the references:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54893

Ok, so it should not be listed in the CVE. I removed it.

It's still a security issue which was fixed though Nicolas, it's normal for us to list these too.

(In reply to claire robinson from comment #13)
> It's still a security issue which was fixed though Nicolas, it's normal for
> us to list these too.

It can be listed in references, but it should not be in the CVE list.

You're altering the rules a bit there. It's never been a 'CVE list' as such, it's just an advisory to say what was fixed. In this case it's a security update which fixes multiple security issues, one has a CVE and one doesn't.

So I should remove the CVE list from advisories ?

In case it's not clear, I'm talking about removing it from this CVE list, not from the advisory text :
http://svnweb.mageia.org/advisories/10097.adv?r1=45&r2=51

http://advisories.mageia.org/MGASA-2013-0174.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Ahh I see, thanks for clarifying, that makes perfect sense.

Just starting to look at these now.