Re: Feedback needed: suexec different-owner patch

[Jacob Champion]

On 03/30/2016 01:49 PM, Stefan Fritsch wrote:
> You are doing the configuration parsing in httpd, and then pass the 
> allowed uid/group to suexec as command line arguments.
> 
> Sorry, but that is not a good approach. You must assume that a local 
> attacker calls suexec directly and passes arguments of his liking. 
> That is the attack vector that suexec's rather annoying restrictions 
> try to avoid.

Checking my own understanding... so if an attacker is able to make
arbitrary calls to suexec as the httpd user (which requires another
vulnerability to begin with), then with this patch, they are able to
execute any scripts in the DocumentRoot as any user. Whereas before they
would have been limited to running scripts only as their owners. Is that
correct?

Other possible issues, not necessarily security-related:

- It looks like the args passed to execv[e]() begin with the original
argv[5] (the trusted group name) instead of the original argv[3] (the
command to execute).

- There is also a compatibility change for suexec itself:

suexec target_uname target_gname cmd arg1 arg2 arg3

will now interpret "arg1" and "arg2" as the trusted user and group,
respectively. I don't know if suexec has any compatibility guarantees
from release to release.

(monttyle, please correct me if I've misread the patch.)

> So the config file parsing would have to be done inside suexec, with 
> the config file path being compiled into the suexec utility. Of 
> course, this would cause some slowdown because suexec would need to 
> parse its config file on every request.
> 
> A different idea would be to use filesystem xattrs. Maybe check for an 
> xattr APACHE_SUEXEC_ALLOWED, and if a file is owned by root and has 
> that xattr, suexec would allow to change to the user specified in the 
> xattr.
> 
> But these two approaches are just ideas. I don't know if they would be 
> accepted in httpd.

A third approach from the original IRC discussion was to simply compile
the "trusted" user/group directly into suexec, as another configured option.

--Jacob

Re: Feedback needed: suexec different-owner patch

[Stefan Fritsch]

On Saturday 19 March 2016 11:09:40, montt...@heavyspace.ca wrote:
> Since its been a while since this issue was mentioned, this patch
> allows Apache to suexec files by a different (but still restricted
> by UID) owner, to avoid the security issue where apache forces you
> to suexec to files it has full chmod access to.
> 
>  Original Message 
> Subject: suexec different-owner patch
> Date: 2016-03-04 18:33
>  From: montt...@heavyspace.ca
> To: dev@httpd.apache.org
> Reply-To: dev@httpd.apache.org
> 
> Here is my first try at a patch for my suggestion, modified from
> httpd 2.2.31.  It works to my satisfaction, able to switch to a UID
> other than the file's owner, while still strictly matching the UID
> and GID of the file against known values.  I make no guarantees of
> correctness or bug-freeness however.  The changes are so simple
> though, I hope there's nothing flagrantly wrong.
> 
> It uses another option, "SuexecFileGroup", which independently
> defines the specific user and group the file must belong to.  If
> you don't define it, it defaults to the old behavior.  I re-used
> suexec's own sanity checking on the new option where it seemed
> appropriate.
> 
> Criticisms, please?

You are doing the configuration parsing in httpd, and then pass the 
allowed uid/group to suexec as command line arguments.

Sorry, but that is not a good approach. You must assume that a local 
attacker calls suexec directly and passes arguments of his liking. 
That is the attack vector that suexec's rather annoying restrictions 
try to avoid.

So the config file parsing would have to be done inside suexec, with 
the config file path being compiled into the suexec utility. Of 
course, this would cause some slowdown because suexec would need to 
parse its config file on every request.

A different idea would be to use filesystem xattrs. Maybe check for an 
xattr APACHE_SUEXEC_ALLOWED, and if a file is owned by root and has 
that xattr, suexec would allow to change to the user specified in the 
xattr.

But these two approaches are just ideas. I don't know if they would be 
accepted in httpd.

Re: [PATCH] Add "FreeListen" to support IP_FREEBIND

[Stefan Fritsch]

On Tuesday 29 March 2016 07:26:06, Jan Kaluža wrote:
> > I am not against the freebind feature as such, it's useful for
> > failover solutions/VRRP/etc. But I am strictly against advertising
> > this as a workaround for broken systemd design.
> 
> We do not advertise it publicly as a workaround for systemd issues.
> I  was using systemd in my email just to show the use-case I'm
> personally interested in. In the httpd documentation for this
> config option in my patch, there is no mention of systemd.

ok, if you keep it that way I am fine with it.

Re: [users@httpd] Strange with AllowOverrideList Directive

[Daniel Ruggeri]

I'm assuming that compiler optimizations would make both patches "six to
one, half dozen to the other" as far as code path followed during the
request cycle... but I agree.

Fixed in trunk in r1737114 and proposed for backport in 2.4 in STATUS.

-- 
Daniel Ruggeri

On 3/30/2016 8:02 AM, Plüm, Rüdiger, Vodafone Group wrote:
>
> But the attached patch is not correct. IMHO it needs to be
>
>  
>
> Index: request.c
>
> ===
>
> --- request.c   (revision 1735931)
>
> +++ request.c   (working copy)
>
> @@ -1009,7 +1009,9 @@
>
>  /* No htaccess in an incomplete root path,
>
>   * nor if it's disabled
>
>   */
>
> -if (seg < startseg || (!opts.override &&
> opts.override_list == NULL)) {
>
> +if (seg < startseg || (!opts.override
>
> +   &&
> apr_is_empty_table(opts.override_list)
>
> +   )) {
>
>  break;
>
>  }
>
>  
>
>  
>
> Regards
>
>  
>
> Rüdiger
>

RE: [users@httpd] Strange with AllowOverrideList Directive

[Plüm , Rüdiger , Vodafone Group]

But the attached patch is not correct. IMHO it needs to be

Index: request.c
===
--- request.c   (revision 1735931)
+++ request.c   (working copy)
@@ -1009,7 +1009,9 @@
 /* No htaccess in an incomplete root path,
  * nor if it's disabled
  */
-if (seg < startseg || (!opts.override && opts.override_list == 
NULL)) {
+if (seg < startseg || (!opts.override
+   && 
apr_is_empty_table(opts.override_list)
+   )) {
 break;
 }


Regards

Rüdiger

From: Luca Toscano [mailto:toscano.l...@gmail.com]
Sent: Mittwoch, 30. März 2016 14:42
To: us...@httpd.apache.org
Cc: dev@httpd.apache.org
Subject: Re: [users@httpd] Strange with AllowOverrideList Directive

Hi again!

> +dev@ to get their opinion! Bug in documentation or small fix required? (or
> me missing something?)

https://bz.apache.org/bugzilla/show_bug.cgi?id=58528 seems to be very similar 
and a patch is attached. We can follow up on it adding a use case or just 
openinig a new one.

Thanks!

Luca

Re: http2 in custom logs

[Eric Covener]

On Wed, Mar 30, 2016 at 8:53 AM, Stefan Eissing
 wrote:
> I need your advice: I want to offer more HTTP/2 related log variables. The
> question is how to best do this:

> a) %x (or another free char) could work. I do not know which one is really
>   unallocated out there, though. I could make %{VAR_NAME}x work to provide
>   the different values.

Slim pickings, and the two-character ones are ugly for backwards compat.

%{PUSHED}^H2

> b) %{VAR_NAME}e, but then I'd need to populate subprocess_env too much and
>   I do not like the +StdEnvXXX configuration...

I think if they are cheap to "calculate" and short they do not need to
be opt-in like the SSL vars.

This would also allow them to be used in expressions and conditional
logs without more work too.

> c) ???
>


> Thanks for the help,
>
> -Stefan
>
> PS. Current plans are to provide
> HTTP2 "on"|"off"connection uses h2/h2c
> H2PUSH"on"|"off"connection allows Server Push
> H2_PUSH   "on"|"off"same
> H2_PUSHED NULL|"PUSHED" when request is being PUSHed by the server
> H2_PUSHED_ON  NULL|nstream identifier that initiated the PUSH

I meant to look at this one, there was a good question on
stackexchange about why pushed items show up in the logs. The users
instinct was that the push didn't work!

> H2_STREAM_ID  NULL|nHTTP/2 stream number for request
> H2_STREAM_TAG NULL|m-n  process wide unique tag from connection id + 
> stream id, e.g. 64-13
>



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

http2 in custom logs

[Stefan Eissing]

I need your advice: I want to offer more HTTP/2 related log variables. The
question is how to best do this:
a) %x (or another free char) could work. I do not know which one is really
  unallocated out there, though. I could make %{VAR_NAME}x work to provide
  the different values.
b) %{VAR_NAME}e, but then I'd need to populate subprocess_env too much and
  I do not like the +StdEnvXXX configuration...
c) ???

This is, again, in the context of a 2.4 backport restriction...

Thanks for the help,

-Stefan

PS. Current plans are to provide
HTTP2 "on"|"off"connection uses h2/h2c
H2PUSH"on"|"off"connection allows Server Push
H2_PUSH   "on"|"off"same
H2_PUSHED NULL|"PUSHED" when request is being PUSHed by the server
H2_PUSHED_ON  NULL|nstream identifier that initiated the PUSH
H2_STREAM_ID  NULL|nHTTP/2 stream number for request
H2_STREAM_TAG NULL|m-n  process wide unique tag from connection id + stream 
id, e.g. 64-13
 

Re: [users@httpd] Strange with AllowOverrideList Directive

[Luca Toscano]

Hi again!

> +dev@ to get their opinion! Bug in documentation or small fix required?
> (or
> > me missing something?)
>

https://bz.apache.org/bugzilla/show_bug.cgi?id=58528 seems to be very
similar and a patch is attached. We can follow up on it adding a use case
or just openinig a new one.

Thanks!

Luca

Re: core.c clang warn/err

[Yann Ylavic]

On Wed, Mar 30, 2016 at 1:22 PM, Stefan Eissing
 wrote:
> Someone wants to check in his/her solution? Otherwise I commit the (x) 
> approach...

Committed the != 0 approach in r1737103, too much danger with the '!' :)

Re: svn propchange: r1737103 - svn:log

[Stefan Eissing]

Let me know when your shell interprets my log messages...

> Am 30.03.2016 um 13:35 schrieb Yann Ylavic :
> 
> On Wed, Mar 30, 2016 at 1:32 PM,   wrote:
>> Author: ylavic
>> Revision: 1737103
>> Modified property: svn:log
>> 
>> Modified: svn:log at Wed Mar 30 11:32:40 2016
>> --
>> --- svn:log (original)
>> +++ svn:log Wed Mar 30 11:32:40 2016
>> @@ -1 +1 @@
>> -core: 'xauth list|grep yl4p |awk '{print }' == 0' => 'x != 0' to avoid a 
>> compiler warning (suggesting parens).
>> +core: '!x == 0' => 'x != 0' to avoid a compiler warning (suggesting parens).
> 
> Oups, somehow my shell interpreted the exclamation mark in the command line :)

Re: svn propchange: r1737103 - svn:log

[Yann Ylavic]

On Wed, Mar 30, 2016 at 1:32 PM,   wrote:
> Author: ylavic
> Revision: 1737103
> Modified property: svn:log
>
> Modified: svn:log at Wed Mar 30 11:32:40 2016
> --
> --- svn:log (original)
> +++ svn:log Wed Mar 30 11:32:40 2016
> @@ -1 +1 @@
> -core: 'xauth list|grep yl4p |awk '{print }' == 0' => 'x != 0' to avoid a 
> compiler warning (suggesting parens).
> +core: '!x == 0' => 'x != 0' to avoid a compiler warning (suggesting parens).

Oups, somehow my shell interpreted the exclamation mark in the command line :)

core.c clang warn/err

[Stefan Eissing]

Someone wants to check in his/her solution? Otherwise I commit the (x) 
approach...

-Stefan

Re: Status for 2.4.20

[Yann Ylavic]

On Wed, Mar 30, 2016 at 11:02 AM, Nick Edwards  wrote:
> So after a thread stop message, why do you feel you need to troll bait them?
> It's clear they both agreed to ignore each other, it's been clear one party
> had no intention on keeping his word (having had myriad of clashes with the
> fool reindl myself on other lists I'm not at all surprised he expected it to
> all one way), so the other advises " gates of hell will open ", so, what's
> your angle?

My angle is that William's warning (seconded by mine, maybe
unnecessarily) also applies to the friend(s) of the one or the other
willing to continue on this road...

Re: Status for 2.4.20

[Nick Edwards]

So after a thread stop message, why do you feel you need to troll bait them?
It's clear they both agreed to ignore each other, it's been clear one party
had no intention on keeping his word (having had myriad of clashes with the
fool reindl myself on other lists I'm not at all surprised he expected it
to all one way), so the other advises " gates of hell will open ", so,
what's your angle? what's the point of your post, posts like yours only
invites trouble. If they don't want to adhere to thread stop William will
wield his big stick as he clams to have, their problem.



On Wed, Mar 30, 2016 at 8:15 AM, Yann Ylavic  wrote:

> On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jr 
> wrote:
> > FULL STOP.
>
> Really, NOW, simply don't talk to each other here (this way at least,
> but anyway is fine too since it seems hopeless).
>
> You are able to block each other on your respective networks, well,
> keep reading your logs for bounced emails if it pleases you, but this
> list (or any @a.o one) is definitively not an loop-hole!
>

Re: Status for 2.4.20

[Yann Ylavic]

On Wed, Mar 30, 2016 at 7:49 AM, William A Rowe Jr  wrote:
> FULL STOP.

Really, NOW, simply don't talk to each other here (this way at least,
but anyway is fine too since it seems hopeless).

You are able to block each other on your respective networks, well,
keep reading your logs for bounced emails if it pleases you, but this
list (or any @a.o one) is definitively not an loop-hole!

Re: [users@httpd] Strange with AllowOverrideList Directive

[Luca Toscano]

[+dev@]

Hi!

2016-03-29 11:06 GMT+02:00 Виталий Фадеев :

> Hello!
>
> I trying to completely disable of .htaccess.
> I have this in httpd.conf:
> 
> Options FollowSymLinks
> AllowOverride None
> Require all denied
> 
>
> Also, i have this in vhost include file:
> 
> Options FollowSymLinks
> AllowOverride None
> AllowOverrideList None
> Require all granted
> CUT...
> 
>
> Directory /var/www/development still contain .htaccess files as i do
> not want to remove them.
>
> Documentation
> https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride
> says:
> "When this directive is set to None and AllowOverrideList is set to
> None .htaccess, files are completely ignored. In this case, the server
> will not even attempt to read .htaccess files in the filesystem."
>
> But when i open my vhost, i get 500:
> [Tue Mar 29 01:27:12.868576 2016] [core:alert] [pid 9361:tid [client
> 192.168.1.1:58722] /var/www/development/.htaccess: ErrorDocument not
> allowed here
> As first line of my .htaccess start with ErrorDocument.
>
> And also, any subdirectories that contains .htaccess is failed with 500.
>
> As i see, this is mismatch in documentation?


I can reproduce on 2.4.16: AllowOverride None alone behaves as expected,
but with AllowOverrideList None I get the same error message (" not
allowed here").

+dev@ to get their opinion! Bug in documentation or small fix required? (or
me missing something?)

Luca