Re: VUDDY: unpatched CVEs in apache httpd

[Eric Covener]

On Wed, May 24, 2017 at 1:16 PM, Reindl Harald  wrote:
> for user/admin/vendor it's nothing different than any of the other undrets
> to thousands of packages on their system "yum/dnf upgrade, apt-get
> upgrade.." and now they *really* are up-to-date

That's already how it works for a vendor-packaged httpd too.

Re: VUDDY: unpatched CVEs in apache httpd

[Reindl Harald]

Am 24.05.2017 um 19:12 schrieb Eric Covener:

On Wed, May 24, 2017 at 1:05 PM, Reindl Harald  wrote:

than also the source should not be bundeled and instead a requirement to
have it installed for build


Already covered ITT: "apr-util 1.6.0 will ship without an embedded
copy of the expat software."


sorry, i missed the "without" and "Obtaining expat and keeping it 
refreshed and up to date with respect to security patches will become an 
exercise for the user/admin/vendor" sound typically more like the usual 
problem of httpd, php and others having burried a random version inside 
the soorce tarball


for user/admin/vendor it's nothing different than any of the other 
undrets to thousands of packages on their system "yum/dnf upgrade, 
apt-get upgrade.." and now they *really* are up-to-date

Re: VUDDY: unpatched CVEs in apache httpd

[Eric Covener]

On Wed, May 24, 2017 at 1:05 PM, Reindl Harald  wrote:
> than also the source should not be bundeled and instead a requirement to
> have it installed for build

Already covered ITT: "apr-util 1.6.0 will ship without an embedded
copy of the expat software."

-- 
Eric Covener
cove...@gmail.com

Re: VUDDY: unpatched CVEs in apache httpd

[Reindl Harald]

Am 24.05.2017 um 17:46 schrieb Eric Covener:

On Wed, May 24, 2017 at 11:44 AM, Reindl Harald  wrote:

and why does it need to be an embedded copy?


It's not required to be embedded


than also the source should not be bundeled and instead a requirement to 
have it installed for build - problem is with the bundeling many people 
don't realize that their system updates for libraries don't cover the 
default build of random software - httpd/apr is just one of them

Re: The drive for 2.4.26

[Luca Toscano]

2017-05-22 16:35 GMT+02:00 Jim Jagielski :

> I think we are *really* close! What say we try for a T
> sometime this week?
>
> Who wants to RM? If no one does, I will.
>

One last thing! :)

I am wondering if we could think about reviewing/backporting to 2.4.x the
code that Yann wrote (and Stefan Priebe tested together with mod_http2
enhancements) to allow mpm-event to use APR_POLLSET_WAKEABLE (avoiding
periodical wakeups every 100ms - IIRC - even if idling).

It seems stable enough after some testing in a real world use case scenario.

Yann, any opinion?

Luca

Re: VUDDY: unpatched CVEs in apache httpd

[Eric Covener]

On Wed, May 24, 2017 at 11:44 AM, Reindl Harald  wrote:
> and why does it need to be an embedded copy?

It's not required to be embedded

Re: VUDDY: unpatched CVEs in apache httpd

[Reindl Harald]

Am 24.05.2017 um 17:02 schrieb William A Rowe Jr:

apr-util 1.6.0 will ship without an embedded copy of the expat software.

Obtaining expat and keeping it refreshed and up to date with respect
to security patches will become an exercise for the user/admin/vendor.

This is scheduled for "RSN" - real soon now


and why does it need to be an embedded copy?
bundle libraries is the start of all evil

[root@buildserver:~]$ rpm -qa |grep expat
expat-2.1.1-2.fc24.x86_64
expat-devel-2.1.1-2.fc24.x86_64

Re: VUDDY: unpatched CVEs in apache httpd

[William A Rowe Jr]

apr-util 1.6.0 will ship without an embedded copy of the expat software.

Obtaining expat and keeping it refreshed and up to date with respect
to security patches will become an exercise for the user/admin/vendor.

This is scheduled for "RSN" - real soon now.

Bill


On Wed, May 24, 2017 at 1:43 AM, Stefan Priebe - Profihost AG
 wrote:
> Hello list,
>
> while reading "http://www.ieee-security.org/TC/SP2017/papers/71.pdf;
> they claim to have found unpatched security holes in apache httpd. While
> reading further it seems that the only missing peace is the unpatched
> xmlparse from expat.
>
> While searching on our build server it turns out to me that the bug is
> not in apache httpd but in aprutil:
>
> # grep -nHr 'newHash = hash' apr-util-1.5.4
>
> apr-util-1.5.4/xml/expat/lib/xmlparse.c:5431:  unsigned long
> newHash = hash(table->v[i]->name);
>
> Did i miss anything from the paper? Is a new apr-util version planned
> which fixes the problem? Are there any special build options or modules
> needed?
>
> Greets,
> Stefan

Re: mod_substitute debugging

[Ruediger Pluem]

On 05/24/2017 03:56 PM, Nick Gearls wrote:
> I added some debugging features in mod_substitute, damned useful when trying 
> to troubleshoot things.
> I'll propose a patch but I'd like your advise about when to log debug info:
> 
> I added the following info:
> 1. line to be parsed, type or search (regex/string), replace string
> 2. in case of matching, the new value
> 
> All logging of debugging info is in level TRACE8
> 
> Remark: the matching string/regex is compiled, so it's not available at 
> run-time.
> I added this info in the subst_pattern_t struct - with a #ifdef _DEBUG to not 
> waste memory in release mode
> 
> My main question is: do I leave all logging in release mode (TRACE8 level) or 
> do I also make this logging dependent on
> the compile flag?

Neither :-).

Have a look at the

APLOG_*_IS_LEVEL macros in http_log.h and wrap the code that creates effort 
accordingly.
If the effort is just a simple ap_log_?error line then you need to nothing if 
compiled with a c99 compiler. See the
ap_log_* macro magic in http_log.h

Regards

Rüdiger

mod_substitute debugging

[Nick Gearls]

I added some debugging features in mod_substitute, damned useful when 
trying to troubleshoot things.

I'll propose a patch but I'd like your advise about when to log debug info:

I added the following info:
1. line to be parsed, type or search (regex/string), replace string
2. in case of matching, the new value

All logging of debugging info is in level TRACE8

Remark: the matching string/regex is compiled, so it's not available at 
run-time.
I added this info in the subst_pattern_t struct - with a #ifdef _DEBUG 
to not waste memory in release mode


My main question is: do I leave all logging in release mode (TRACE8 
level) or do I also make this logging dependent on the compile flag?


Nick

Re: is the mod_authz_host's parsed_subnets cache htaccess-safe?

[Eric Covener]

On Wed, May 24, 2017 at 8:37 AM, Eric Covener  wrote:
> I was copy/pasting bits of this from mod_authz_host into a derivative
> of mod_limit_ipconn and noticed that the parsed_subnets cache seems
> unsafe if we are parsing directives in multiple threads from htaccess.
>
> parsed_subnets is an apr_hash_t that we write to when parsing 'Require ip ..'.
>
> It seems like it would be helpful to have a bit in cmd_parms to tell
> us that it came from htaccess, then ap_check_cmd_context() could check
> it and we could skip caching new subnets.
>
> Since it requires write access to htaccess, I don't consider it a
> security issue.

Whoops, it's already protected in a post_config hook.

is the mod_authz_host's parsed_subnets cache htaccess-safe?

[Eric Covener]

I was copy/pasting bits of this from mod_authz_host into a derivative
of mod_limit_ipconn and noticed that the parsed_subnets cache seems
unsafe if we are parsing directives in multiple threads from htaccess.

parsed_subnets is an apr_hash_t that we write to when parsing 'Require ip ..'.

It seems like it would be helpful to have a bit in cmd_parms to tell
us that it came from htaccess, then ap_check_cmd_context() could check
it and we could skip caching new subnets.

Since it requires write access to htaccess, I don't consider it a
security issue.

-- 
Eric Covener
cove...@gmail.com

VUDDY: unpatched CVEs in apache httpd

[Stefan Priebe - Profihost AG]

Hello list,

while reading "http://www.ieee-security.org/TC/SP2017/papers/71.pdf;
they claim to have found unpatched security holes in apache httpd. While
reading further it seems that the only missing peace is the unpatched
xmlparse from expat.

While searching on our build server it turns out to me that the bug is
not in apache httpd but in aprutil:

# grep -nHr 'newHash = hash' apr-util-1.5.4

apr-util-1.5.4/xml/expat/lib/xmlparse.c:5431:  unsigned long
newHash = hash(table->v[i]->name);

Did i miss anything from the paper? Is a new apr-util version planned
which fixes the problem? Are there any special build options or modules
needed?

Greets,
Stefan