Bug#1018718: marked as pending in apache2
On Mon, 2023-04-03 at 10:38 +0400, Yadd wrote: > > Causes that would also make it fix #977014. > Sure, thanks for the link You've marked it as fixed but haven't closed it. Was that on purpose or should I close it? > I saw in this issue that you were a little frustrated by the lack of > responsiveness in apache2 maintenance. Uhm... don't take that too serious... it was rather just some unfortunate wording and not really meant critical... > But apache2 is "RFH" and I'm not > C expert neither apache user so I try to do my best until someone > more > qualified takes over. ... in general I highly appreciate the work of any DM/DD :-) Cheers, Chris.
Bug#1018718: marked as pending in apache2
Hey. Thanks for the fix. Am I right that this *generally* does not longer enable apache2- doc.conf per default (i.e. also on fresh installs)? Causes that would also make it fix #977014. Cheers, Chris.
Bug#1018718: apache2-doc: despite having been disabled, apache2-doc.conf gets rather silently re-enabled automatically
Package: apache2-doc Version: 2.4.54-1~deb11u1 Severity: important Hey. Unfortunately #977014 has been ignored so far, but no I just noted that even when one explicitly disabled apache2-doc.conf via a2disconf, it still gets rather silently re-enabled on upgrading the package, which is IMO quite unfortunate. Please fix at least that, or even better #977014, in which case this bug here would become obsolete. Thanks :-) Chris.
Bug#990658: apache2-doc: legacy conffiles leftover
Package: apache2-doc Version: 2.4.46-2 Severity: normal Hi. Apparently the package used to contain the conffiles: /etc/apache2/conf.d/apache2-doc but no longer does so. Please properly clean them up using dpkg-maintscript-helper(1). (AFAIU, the version that needs to be specified for that is NOT the version where the conffile was dropped, but rather "the latest version of the package whose upgrade should trigger the operation" Quoting the manpage: For example, for a conffile removed in version 2.0-1 of a package, prior-version should be set to 2.0-1~. This will cause the conffile to be removed even if the user rebuilt the previous version 1.0-1 as 1.0-1local1. Or a package switching a path from a symlink (shipped in version 1.0-1) to a directory (shipped in version 2.0-1), but only performing the actual switch in the maintainer scripts in version 3.0-1, should set prior-version to 3.0-1~. Also, it hadn't "registered" /etc/reader.conf.d/ so that will probably be left over, too, unless some other package that contains it is installed (like libccid). Cheers, Chris.
Bug#980137: apache2: multi-instance support, APACHE_CONFDIR and ServerRoot
Guess the better place to set it would be: /lib/systemd/system/apache2.service (just like it's already done in /lib/systemd/system/apache2@.service for the instance versions) This would also have the benefit that people could use APACHE_CONFDIR in their configs if they want to make paths relative to it, where the directive doens't use non-absolute paths per default relative to ServerRoot.
Bug#980137: apache2: multi-instance support, APACHE_CONFDIR and ServerRoot
btw: For that to work, APACHE_CONFDIR would also need to be exported, probably either from /usr/sbin/apachectl Cheers, Chris.
Bug#980137: apache2: multi-instance support, APACHE_CONFDIR and ServerRoot
Package: apache2
Version: 2.4.46-2
Severity: normal
Hi.
The default apache2.conf has:
#ServerRoot "/etc/apache2"
i.e. fall back to the compiled in default of /etc/apache2.
Shouldn't this better be set to:
ServerRoot "${/etc/apache2}"
?
Especially since, AFAICS, nothing in README.multiple-instances
tells people that they have to modify the ServerRoot directive.
Cheers,
Chris.
Bug#977014: apache2-doc: please do not enable apache2-doc site (or even better: remove it at all)
Package: apache2-doc Version: 2.4.46-2 Severity: wishlist Hi. I'd like to propose not to enable the apache2-doc "site" or even better completely remove it's config or move it to some location in /u/s/d/apache2/examples/ . Why? First, there is typically never every any reason to actually host it. People who really want this online and not just locally available (where it's "more secure") can always just use https://httpd.apache.org/docs/ . And any admin who wants to have access to the very specific version for his current package, can just use the local files. The current config places a pretty generic alias, "/manual", into the main server, which will be active in any vhost, unless specifically overridden. Absolutely no reason to do this, and in fact it's even like that this could disturb other content being served. There's a long standing history of needlessly automatically enabled stuff causing security issues (e.g. mod_status). The same principle applies here: why enabling something without any need? Cheers, Chris.
Bug#775176: please manage address/port listenings with the conf.d snippets system or something similar
retitle 775176 please manage address/port listenings with the conf.d snippets system or something similar stop On Sat, 2015-01-17 at 13:51 +0100, Harald Dunkel wrote: This bug report is about the files provided with the package. All I'm asking for is using a2enconf instead of ports.conf. I've understood that (and I corrected the title accordingly, since that implied something completely different)... So I did some tests just now, and unlike to what I was sure myself before, it *does* work, that you remove e.g. Listen foo:80, and still have Vhosts enabled which are configured for foo:80. Sorry for not having correctly verified that earlier. Therefore taking that back and claiming the opposite ;-) So you were right in that matter, one can actually make the Listen like a feature one disables/enables. At least the vhosts will continue to work, but just those where one still has listeners (e.g. on 443) will answer. I have *not* checked though, whether it works with all other places in apache, which refer to internal ports/addresses ... e.g. there *may* be directives, which reference port 80, and that simply make daemon start fail when that is no longer listening. Now with respect to your request: In principle you can implement this already now: Just empty ports.conf and add your Listen statement to e.g. conf.d snippets... I'm OK with having a single file for both ports. ... but of course the above only makes sense when you have multiple ports.conf like files, e.g. a2en/dis http.conf a2en/dis https.conf a2en/dis svn.conf ...where each of them contains the Listen directive's for one of these protocols. Whether this makes sense in practical usage is another question,... I for example configure my sites to do what I want, and if I don't want the to listen on http, I just don't configure them to do so,.. or I set up an (insecure) redirect to https. And if I'd have no http altogether (in all my sites), THEN I'd remove the Listen line from ports.conf But I'd never switch one or the other on/off on a regular/daily basis. So for me personally(!!) it wouldn't make that much sense, and I still think the handling should stay as it is... ...because, what definitely doesn't work (at least up to until Apache 2.2) is that you have the same Listen statement multiple times. So you cannot just add these to the sites configs (conceptually). So right now I think it makes more sense to take ports.conf as the single file that handles the listeners. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#775176: please don't open tcp/80 by default
On Thu, 2015-01-15 at 13:53 +0100, Harald Dunkel wrote:
Unfortunately the VirtualHost statement defines both IP address
and port for each virtual host. They don't work without the
appropriate Listen statements, so I cannot follow your independent
from each other.
That's basically why you need to tell the vhosts for which IPs they're
valid for, i.e. you can have probably different vhosts for the same
names (i.e. domain-names or addresses the client sets in the HTTP Host:
header) on different IP addresses.
So conceptually Listen is for the IP protocol level, while the address
in VirtualHost (which can actually be a hostname as well, that is then
however once resolved on startup) is just to tell on which addresses
that vhost should be used, which is btw: also necessary for IP based
vhosting (i.e. when no HTTP Host: header is given).
Can you confirm that the central Listen statement breaks the
modular approach of a2ensite?
Not sure what you mean.
I guess you'd probably want to get rid of the Listen statement
altogether, and that Apache determines all the address/port combinations
from all enabled vhosts automatically.
I'm not sure whether I would generally like this and which implications
it has... I think security wise it's not so good, because you loose that
one central point where you control where to actually listen on.
But anyway, this is not the case in Apache and one would have to request
such feature upstream... and until that, Listen is IMHO independent
from VirtualHost (but VirtualHost isn't independent from Listen)... and
as such it doesn't make sense IMHO to have it in the sites-available
dir,... and even less in the conf.d dir.
Thats my point: I want to disable apache2 for port 80/tcp without
the risk of loosing this setting on the next package upgrade.
First, you don't loose anything on package upgrade, since dpkg doesn't
blindly overwrite config files unless you tell it to - actually in the
many years of running apache now, it never asked me the typical
question, since the maintainer version of ports.conf never changed
And the next problem is, that the listening settings are so deeply in
the configuration schema of Apache, that you cannot just enable/disable
them so easily by removing a config file.
Even if you'd say a2dismod ports-http-80.conf or something like that...
all your other config snippets would e.g. still refer to port 80 and
fail then.
And AFAIK there is no IfListenOn conditional directive where you can
just opportunistically enable something, based on whether apache
actually does listen on it.
This could be implemented by splitting ports.conf into 2 parts
conf-available/{port80.conf,port443.conf} and to create the symlinks
in conf-enabled (to keep Debian's default). Just a suggestion, of
course.
Nah,... really not... then you get dozens of such small one liner
files... many people listen on much more ports than just 80 / 443.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Bug#775176: please don't open tcp/80 by default
On Wed, 2015-01-14 at 06:47 +0100, Harald Dunkel wrote: the interface to enable and disable virtual hosts is a2ensite/a2dissite. That includes the IP/IPv6 address / virtual host names *and* the ports to listen. apache2.conf should provide just a basic configuration common for all vhosts and modules. As said before... where Apache listens on and which (whether at all) you have vhosts, is in principle independent from each other. a2en/dissite should not change the listening behaviour. And wrt conf.d, this is IMHO rather other misc stuff, e.g. I put in files there which enforces httpOnly or secure on all cookies,... or things like that. But it doesn't seem to make much sense to make the port-listening such a config snippet which one can disable or enable - if you disable the port-listening than you effectively disable the daemon. I would suggest to move the default vhosts for 80/tcp and 443/tcp to their own host modules in mods-available, making ports.conf obsolete. Then the default vhosts can be kicked out and replaced using a2dissite, as usual. Maybe I misunderstand you,... but ports.conf doesn't define any vhosts,... and you need to set the listening addresses, even when you do no vhosting at all... so it doesn't make much sense to move something here. Apart from that, which default vhost do you mean? There's the default vhost vor IP based vhosting,.. the default one when namebased vhosting is done, an IIRC there's even the main server host, which is effectively when you put the config outsite of any IP/name based vhost stanzas. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#775176: please don't open tcp/80 by default
On Mon, 2015-01-12 at 09:48 +0100, Harald Dunkel wrote: Actually I don't see any reason why apache2 should unconditionally listen on 80/tcp for a https-only setup, so I wonder if ports.conf could be moved to conf.d to support a2disconf? You can just modify ports.conf and set the listening sockets as necessary? Moving ports.conf to conf.d seems not to be conceptually sensible, since one will always need listen addresses. Another option would be to move the Listen statements to the appropriate virtual host definitions, making ports.conf obsolete. Also not really clean, since a single listening address might be used by multiple VHs... so it doesn't really belong there. I'd rather vote for httpd not being started automatically after installation... which gives the admin time to configure it appropriately and not having it unconditionally / insecurely(?) listening. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Fri, 2012-10-26 at 13:18 +0200, Ondřej Surý wrote: + It is also advised that + you check your custom configuration whether it's not vulnerable to + foo.php.jpeg attacks. The php5_cgi configuration snippet can be used + as base - it's important to use FilesMatch or Files directive to + limit the handling to the last extension. Can we perhaps explain a bit more, what the foo.php.jpeg attack is? The last sentence hints it already a bit,... but I guess without clear explanation people may simply skip it. I think it became clear that we are stuck with no solution which would work for anyone Do you agree... that we should work on some hopefully general-everything-works framework for jessie? Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hey folks. On Tue, 2012-10-16 at 00:16 +0200, Stefan Fritsch wrote: And remove the php-cgi.conf completely, right? So this would introduce a different fix for the multi-views problem. Are you sure that there is no other problem that we would re-introduce? Maybe it's worth a try. There is at least no solution that is obviously right. I fear that regardless what we do, we will break some configs. I'd say we should sit together after wheezy however,... searching for some best-as-possible-overall-framework ;) Besides removing the media types from /etc/mime.types, one could add a RemoveType php ... to the apache config (but where?). I proposed that previously to Ondřej but only as a poor-man's guarantee... I wouldn't want to see that we really rely on it,... cause it may easily break... One never knows what upstream changes... e.g. at some day there might be a change in the order of evaluation from RemoveType and TypesConfig... or evil things like that... Or maybe, one could also set AddHandler default-handler php The latter is an idea I just had, I have not thought it through or tested it. Sounds like it could work,... and actually a nice idea ;) ... but it seems somewhat ugly to me... you know adding handlers and assigning stuff just for hackings something into... We cannot know how much something like this breaks... just imagine if a user has already his own default-handler defined. Maybe it would be better to create a single document with all possible solutions and pro and cons? I have started to create such an overview at http://wiki.debian.org/Apache/WheezyMimeTypes but it is not finished yet. Feel free to add more infos/solutions/pros/cons. The page may come in handy for the Jessie, too. Good idea... I hope I'll find some time into looking at it... But in general... I'm a bit scared that we clash into the release of wheezy with neither a perfect nor an at-least-somewhat-secure solution. So question the the group is: Should we continue with investigating in a perfect solution (and that wiki seems to somewhat go into that direction)... or should we simply admit there's a shitty situation for wheezy... add the necessary release notes with big fat exclamation marks... and shame ourselves till we come up with the uber-solution in jessie? ;-) Christoph: For mod-fastcgi/mod-fcgid, the file.fcgi.foo problem is somewhat mitigated that they require Options ExecCGI, too. And AFAICS that is not set by default. Any opinions if this is good enough for wheezy? I lean towards yes, but maybe I am missing something. Well... phew... I mean don't get me wrong... nearly all what we do here is about teaching users and/or helping them not to shoot themselves... so in theory you're right and this is enough... on the other hand: Practise looks like this that users often have merely an idea what they do... and I'd feel better, if both mods also place some Files block around. Actually,... I'd even feel better if they stop automatically enabling things. And this is not my usual security-paranoid installed-packages-shouldn't-enable-their-stuff-automatically talking... it's rather that in this special cases (namely Apache)... they enable things globally for the whole server... which is (to my experience) rarely needed. We could help users from potential security troubles,... if we force them to decide in which context they want to enable things. But how to proceed now? In general, if we secure these two mods from the evil.fcgi.jpeg issue, we have the same problem as with PHP (there Ondřej added a according entry to NEWS and README.Debian) namely that we potentially break some setups (those from such devilish admins coming straight from hell and used http content negotiation in some way with their interpreted stuff. I personally think it's definitely worth! Then we have the options: a) Either just secure it with Files blocks around the diretives that add the handlers... b) or disable global per-default activation but still document in each of the two packages how to do it right. I'd vote for (b). Depending on what you guys from the Apache Maintainer group say... I'd open respective bugs, and help Tatsuik and Taku with documentation and stuff... Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Hi Charles. On Thu, 2012-10-11 at 09:06 +0900, Charles Plessy wrote: Do you think that there is a way to fix #589384 (the *.php.foo problem) without removing the application/x-httpd-* media types ? I would say no, well at least not if we also want to use these media types later on in Apache to select something for interpretation. The problem with using /etc/mime.types via the TypesConfig directive in Apache is the usual with Apache: Most mod_mime directives (and maybe also others) will assign a media type if just any extension (i.e. also the foo in file.foo.bar) matches. The usual way around this is to place these directives in e.g. Files ?*.bar /Files or FilesMatch ^.+\.bar$ /FilesMatch TypesConfig however is a server wide scope directive, so this won't work here. As I mentioned previously, I think it's very dangerous to use TypesConfig per default. It's evil by design and people should need to intentionally enable it (and then hopefully know what they're doing). I really think we should not fiddle around with mime-types anymore, or better: I think we should stop using it to enable files for interpretation, even if that may break now some setups. Of course we should provide release notes hints on how to make them work again, which is usually quite easy. Also, please consider that people using advanced stuff like FastCGI can be expected to know what they're doing. I did not realise before that in the current release cycle, Apache stays at version 2.2 and that in Jessie, configurations will need to be re-adjusted anyway. It would of course be nice, if we could postpone this to jessie, but... I think that it is a good argument for a compromise, provided that #589384 stays solved and that we agree that in Jessie the media types application/x-httpd-* will be removed from /etc/mime.types. Right now I see no way to prevent the evil.php.jpeg issue otherwise. And note especially, that also FastCGI is in principle vulnerable to this. Though I haven't checked right now, how they actually select the PHP files for interpretation (which may or may not prevent the issue). easy way to adjust the priority of the SetHandler statement of php5_cgi.conf I think it's determined by the loading order... which makes it basically impossible IMHO to really make sure it gets loaded as we want it to. in a way that does not break FastCGI configurations. Even then we need to check whether fastcgi or fcgid are vulnerable to the evil.php.jpeg isseu. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
Oh and one more thing (even though this is PHP unrelated): Maybe I misunderstand something but it seems both: libapache2-mod-fcgid, which uses: IfModule mod_fcgid.c AddHandlerfcgid-script .fcgi FcgidConnectTimeout 20 /IfModule and libapache2-mod-fastcgi, which uses: IfModule mod_fastcgi.c AddHandler fastcgi-script .fcgi #FastCgiWrapper /usr/lib/apache2/suexec FastCgiIpcDir /var/lib/apache2/fastcgi /IfModule are highly vulnerable to the evil.fcgi.jpeg issue... Can you confirm this? Cause then we need to open some critical bugs. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, 2012-10-08 at 15:38 +0200, Ondřej Surý wrote: Just one last question which came to my mind. Would this all be fixed if we added non-magic type to mime-support (e.g. http://bugs.debian.org/670945) and reverting the changes done in the php5-cgi package? I'm a bit unsure how/why that would fix the general problem? Perhaps you can elaborate a bit more on what your ideas are :) I haven't looked into absolute details but I think the main problem here is, that different SAPIs use different fixed handler-names. And even if all would use the same,... we'd have a problem, namely how to select the right one. That I think would justify change in the mime-support package. Too much breakage on every front now. Well... I think it's quite dangerous to again play around at mime-support. I mean we all know the problems arising from there,... not only the security issues like foo.php.jpeg, but also that we are again quite dependant on some other package. Admittedly, we're in quite a shitty situation now, so close to wheezy, but I somewhat agree to Stefan, in better just adding some more release notes. The next step would/could be to think about post-wheezy release goals for the overall PHP framwork in Debian. Which includes IMHO: - unifying as much (apache) configs as possible for the different SAPIs - other packages (i.e. packaged PHP programs) should not rely on PHP being activated by the php packages (especially not globally), but should rather give the user a debconf option on where (which webserver) to activated it how (always only local scope,... and questioning which SAPI) - make the different SAPIs co-exist more out-of-the-box...which i.e. also addresses this very bug The ideal state would be that one can enable all SAPIs in one Apache instance and even use them in the same vhost... differentiating per Directory (well at least as far as this is possible for all the SAPIs). Maybe this requires that we patch things like mod_f(ast)cgid ... to use other handler names. I have not yet an idea how all this could be achieved. But back to this very bug: If we say we solve this for now, by just adding release notes as Stefan proposed... then there is still one important thing left. Namely those I asked in the mails from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#59 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687418#69 May we run into the problem, that again, files are accidentally served (as files)? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Fwd: [php-maint] Updating php5 to 5.4.4-5 broke FastCGI setup on my machine
On Mon, 2012-10-08 at 22:42 +0200, Ondřej Surý wrote:
Basically it would bring the old behaviour back while not mangling
with custom Set/AddHandler directives in the apache. Remember the
php5_cgi.{load,conf} hack was introduced after decision to fix this
only in Apache - which in turn caused more breakage in custom setups
then expected.
Ah... so you mean adding e.g. application/x-php (or whatever) but don't
use this with mod_php or normal CGI (where we'd still keep the
php5_cgi.{load,conf} then?)
Not sure about that...
I mean these types were removed for good reasons... and especially in
Apache people should at best stop using /etc/mime.types at all.
I somehow fear a bit,... that we might just end up with other new
(security?) issues being added.
Putting parts of PHP configuration (well I know it's not really that)
in other packages seems problematic to me IMHO the cleanest solution
would be, if PHP-packages add the necessary basic configuration to
installed webservers (ideally not only to Apache)... without activating
PHP.
The later then being done manually by the admin, or (more or less)
automagically by other packages.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Bug#654764: Apache and BEAST
Hi Stefan :) On Sun, 2012-09-16 at 10:31 +0200, Stefan Fritsch wrote: Browsers now have a workaround that splits/inserts TLS records that cause the IV to be changed. So this works also with CBC ciphers. Yeah I new,... This is basically the same what openssl does since before 0.9.6. ... I just looked at it from the perspective of the server operator... and from that I also want to enforce, that things are secured when a user would use a browser without that workaround :) http://my.opera.com/securitygroup/blog/2011/12/11/opera-11-60-and-new- problems-with-some-secure-servers Thanks... nice post. Unless you forbid CBC ciphers, I don't think you can do anything on the server. Uhm... I thought openssl =0.9.6. alone would already secure things? But forbidding the CBC ciphers gives up perfect forward secrecy Yep... The fix/workaround needs to be done by the browser. Ah... I see... so what openssl did was with respect to it acting as a SS/TLS1.0 client?! I guess in principle one could deactivate SSLv3 and TLS1.0 on the browser side,... to force things being secure (with respect to BEAST at least), right? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Apache and BEAST
Hi. I wondered about the status of the BEAST attack in Debian, especially: 1) Can I use any cipher suite and still be secure (e.g. use AES and disable RC4; the later which is often claimed to secure things... while there are however sources on the web claiming it would be even more vulnerable than AES)? 2) I know most browsers mitigate it already on their side,.. but I guess just by not selecting CBC ciphers if possible (???)... what however if I only offer such? So question is,.. how can I force it on the server side, to be secure against BEAST. I also found these: http://security.stackexchange.com/questions/17080/is-there-a-way-to-mitigate-beast-without-disabling-aes-completely http://blogs.cisco.com/security/beat-the-beast-with-tls/ which claim openssl fixed the problem already on a protocol level (even for TLS 1.0). So can we verify whether in Debian's openssl that SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is set? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
On Tue, 2012-08-21 at 09:07 +0200, Ondřej Surý wrote: Maybe add just a small paragraph that the configuration of the extensions has changed and php users should read the NEWS file? That's probably sensible approach. I have quickly drafted short paragraph which can be used for release notes: Sounds good... which have .php, .php[345] and .phtml extensions on a most right place May I suggest to add for security reasons in the end? I guess we all agreed that deliberately using foo.php.jpeg is in most cases dangerous and bad style, too,... so why not teach our users a bit?! :-) On Tue, 2012-08-21 at 09:48 +0200, Ondřej Surý wrote: Nope I mean that the extension should be last. Perhaps use the phrase rightmost extension, or trailing extension? Or even give a short example? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Possible release note for systems running PHP through CGI.
Hi Ondřej. On Mon, 2012-08-20 at 14:57 +0200, Ondřej Surý wrote: http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=commit;h=72eef08994f65b227103509617652d7c0bf0587a - You mention in the README.Debian now, that no other webserver likely used /etc/mime.types. Wasn't there someone who meant lighthttp was also using it? - I like the changes to the wording of the PHP 5 CGI and Apache HTTP Server section. - Where you write: add the mentioned configuration block to one or more virtual sites. ... you may even refine that to add the mentioned configuration block to one or more virtual hosts or directories. - Where you write: It's advised to not mixmatch mod_php and php5-cgi in the same is that intended, that php5-fpm is missing? To the rules: - They seem ok for a security point of view. - When using FilesMatch, one can slightly optimise the subpatterns, by placing ?: after the (, e.g. .+\.ph(?:p[345]?|t|tml)$ - At the places where you Deny, one might perhaps add Satisfy All again. It's All per default, but if one has set that to Any in main server context, your deny-intention might geht ineffective again. I agree on that, even though I think that PHP should have it's own mimetype definition (same as python or perl, e.g. application/x-php, but let's keep this discussion out of this issue, since it's something different). +1 on that. I am not aware of any other (Debian shipped) web server which uses system-wide mime-types. At least both nginx and lighttpd don't depend on system mime types for interpreting PHP files (both use extension based definitions). Ah ok,... so ignore my question from above... :) If more than one extension is given that maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html. Right, the others already pointed out in the meantime, what can still happen. I guess we should be largely safe of all this now. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#674089: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Fri, 2012-08-17 at 08:00 +0900, Charles Plessy wrote: - In Squeeze, using default configurations, files with .php in their name such as foo.php.jpeg are executed as PHP scripts by the Apache web server. Looking at mod-php5 5.3.3-7+squeeze14: not vulnerable, but not optimised either PHP5 with CGI _is_ vulnerable, when (only) the configuration as described in php5-common's README.Debian was followed. The latter doesn't defined it's own mime-type or handler for .php files, therefore the ones from mime-types are (likely) to be used, therefore vulnerable to the foo.php.jpeg issue. - To solve that problem, the media (MIME) type for PHP has been removed from /etc/mime.types (http://bugs.debian.org/589384). Seems so (*). That bug btw. is just THE justification for my demand to add a RemoveType ... if that would have been in place, the mime-types entries wouldn't have caused the foo.php.jpeg security issue (with the FilesMatch \.ph(p3?|tml)$ or an optimised version of that). But I guess another reason should have been, that these pseudo types should have never been there. - This breaks the websites executing PHP scripts through php5-cgi, and a solution will be documented in the php5 package's NEWS file, and the same text will be proposed to the release notes (http://bugs.debian.org/674089, work in progress). Guess so. - Unfortunately, the proposed solution exposes these websites to the original problem that caused the PHP media types to be removed from /etc/mime.types. No (well partially). As I told just in the mail you replied to (*feeling a bit annoyed*)... neither what Ondřej uses now (version 5.4.4-4) in the mod_php package's php5.conf: FilesMatch \.ph(p3?|tml)$ SetHandler application/x-httpd-php /FilesMatch FilesMatch \.phps$ SetHandler application/x-httpd-php-source /FilesMatch nor what he wrote in README.Debian for CGI: FilesMatch \.php$ AddType application/x-php php /FilesMatch are vulnerable, to the actual problem. They are though vulnerable to exactly what we talked above at (*), because Ondřej refuses to add the one line RemoveType. And the same is true for the optimised versions (for both mod_php and CGI) of the above I proposed in #674205, but which I guess won't be merged either. If the last point is true The reasons for that being not true it the FilesMatch \.php$ or in my optimised versions Files ?*.php sections, wrapping around the SetHandler or AddType. They ensure, that the handler or MIME type is only set for files matching these patterns. And files like foo.php.jpeg won't. In the slower FilesMatch version the $ in the end of the pattern is crucial for this to work. Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Wed, 2012-08-15 at 10:40 +0200, Ondřej Surý wrote: With the exception of RemoteType php they are all in the place. I've just had a look into git (I guess that's the canonical location?): http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob_plain;f=debian/php5-common.README.Debian;hb=HEAD and http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob_plain;f=debian/libapache2-mod-php5.conf;hb=HEAD Even, if you don't want to add RemoveType to secure things more,... the optimisations with respect to patterns and FilesMatch I've proposed before and after you closed the other bug seem to miss completely. Just in case this is by accident Please be aware that mime-types package dropped non-standard cosmetic: a the is missing before mime-types The package mime-types has dropped the following non-standard definitions: Seems to double the information from above a bit... I don't mind,.. just you want to make it shorter :) the a PHP Internet Media Type (commonly known as MIME type). They Typo: I guess that's from me ;-) ... the a is too much. In order to avoid any problems when not using Apache PHP5 module I don't like this negative advertising against the other SAPIs... :( the php5-common package on how to correctly configure PHP 5 running purely cosmetic: sometimes you/we write PHP5 sometimes PHP 5. Server) and take care, that and PHP files intended to be interpreted Typo: (also from me I guess?) the and seems to be too much, or something is missing Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Wed, 2012-08-15 at 21:07 +0200, Stefan Fritsch wrote: Since we have gone to great pains to not use the magic MIME types anymore, I think we should not recommend them here. Or at least not as the first option. Stefan, can you please elaborate on what you mean with magic MIME types? (you're talking about MIME type discovery via libmagic or similar? That would be not what's suggested above!) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [php-maint] Bug#674089: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Thu, 2012-08-16 at 00:24 +0200, Stefan Fritsch wrote: Stefan, can you please elaborate on what you mean with magic MIME types? (you're talking about MIME type discovery via libmagic or similar? That would be not what's suggested above!) The mime types that are also handler names and cause mod_php to execute scripts, i.e. application/x-httpd-php and application/x-httpd- php-source. Using these as mime types is dangerous because they may also cause things named like foo.php.bar to be executed. Well the same is (IIRC) the case when you use handlers? No? Anyway,... the configuration snippets I proposed in #674205 are _NOT_ vulnerable to the issue you describe, even though using AddType. btw: I've emphasised this several times already,... Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#674089: [php-maint] Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Wed, 2012-08-15 at 09:02 +0900, Charles Plessy wrote: For the moment there is the draft proposed by Christoph at http://bugs.debian.org/674089#66 I should note perhaps, that this draft expected all the proposals I made in #674205 to be in place, which they were not yet, when I've looked the last time. So additions might needed to be made. C. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Tue, 2012-08-14 at 08:06 +0900, Charles Plessy wrote: + You should also be aware, that a server deployed in CGI mode is open + to several possible vulnerabilities, see upstream CGI security page + to learn ow to defend yourself from such attacks: + http://www.php.net/manual/en/security.cgi-bin.php I doubt that this is a good idea,... to teach our users that the only mode (CGI/FCGI) that can be made somehow secure from an operational point of view, would be not. With respect to the site you refer to: The educated reader will quickly see, that 1/2 are simply about a problem that the CGI interpreter _would_ read any files... and how to prevent this. Well... but it never does,... given that cgi.force_redirect is set. (3) doc_root/user_dir should apply to the other SAPIs as well... The same is true for (4)... if you are stupid enough to put your mod_php libs into the web tree... well then no one can help you. + Action application/x-php /cgi-bin/php5-cgi + FilesMatch \.php$ + AddType application/x-php php + /FilesMatch See my really elaborate discussion on how this should be securely set (and how it can be optimised in contrast to the above) at the bug over at php5-common, which I've mentioned several times now... It get's boring to explain this over and over again,... honestly :( For the release note, I think that it would have to clearly indicate that this only impacts the system running PHP scripts via the CGI package, This depends... The mod_php packages ship their own, more or less secure (again, see my bug at php5-common) config snippet for Apache (!), that already registers it's own handler. So mod_php/Apache = safe. php-cgi = will be safe when the proposed steps are implemented. Question: Can any other webservers use mod_php? If so, they _might_ be vulnerable, as the supplied Apache config snippet probably doesn't apply to them. which in my understanding are the minority. Do we really know? Most people I know run either CGI (if just security counts) or FPM (if security and/or performance counts)... And apart from that question, I don't think a minority deserved less security, just because being a minority ;) If upgrading to Wheezy would unconditionally break these systems, No,... this is not necessarily the case,.. if people have e.g. set their own handlers/mime-times for php in apache. As you can see... there is not a single scenario or case where problems necessarily occur. Which is why I proposed before to add this not only to the release notes, but also to the NEWS files of php5-common and mime-types. To be honest (and this is not meant against you, Charles), I'm quite upset to see how things like this issue are handled. First, a feeling for security seem to be missing, and if something is not a typical attack on a binary, but insecurity on a higher level like dangerous configuration, it seems to be not considered as security problem. People argue forth and back for weeks, whether some text is too much at some place or whether a safety catch option at some place (that is not required under normal circumstances but might protect under bad situations) can be added per default or not. In the meantime, all those using testing/sid may have some problems... and in the real world, there are people using testing or even sid on their servers. Now I noticed that problem and fixed it on all my systems by deploying secure and even optimised Apache configs, which I then suggested Ondrej to add to his documentation for the benefit of all. Again, a not yet ended discussion, which really feels like a pain in the ar**. Okay,... so much ranting from my side ;-) But seriously,... I guess I've said what I'd do with respect to release-notes/NEWS files several times now,... and also what I'd put into php5-common for documentation and how I'd improve mod_php's default config snippet. So all I have to say is said... and unless someone has specific technical questions, I'd like to back out from that discussion. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Sat, 2012-08-04 at 12:44 +0900, Charles Plessy wrote: do I understand correctly that the problem would be solved by documenting the change in the release notes ? Well as said, I do _NOT_ consider this to be enough (see my previous mail for my proposed steps). If yes, can somebody write a draft and reassign this bug to the release-notes packages ? What about: --- mime-types package dropped non-standard definitions for PHP that might affect any systems using PHP --- The package mime-types has dropped the following non-standard definitions: application/x-httpd-phpphtml pht php application/x-httpd-php-source phps application/x-httpd-php3 php3 application/x-httpd-php3-preprocessed php3p application/x-httpd-php4 php4 application/x-httpd-php5 php5 Systems, especially webservers (including but possibly not limited to the Apache HTTPD Server) may have used this to mark files as having the a PHP Internet Media Type (commonly known as MIME type). They may have used it further, to determine that such files are to be interpreted by PHP rather than served as normal files. If a webserver would not consider these files to be interpreted anymore this would have at least the following effects: - PHP web programs/sites no longer work - PHP files are directly exposed, which may be a security problem In order to avoid any problems, read the README.Debian from the php5-common package on how to correctly configure PHP (examples are provided for the Apache HTTPD Server) and take care, that and PHP files intended to be interpreted are recognised as such (typically by adding MIME-Type or handler definitions in the webserver configuration). More information can be found in bug #674089 and partially in #674205. --- As you can see, I personally would put the burden of explaining how to (securely) configure PHP to the PHP packages... I have some discussions about that with Ondřej in #674205 ... I'm not yet fully happy with it (see there)... and although he closed the bug and said he'd have applied some of my proposals, I could not yet find these changes there. I haven't yet reassigned the bug, as I think my other steps of what I think should be done will get finally lost then. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
Hey folks. How are things going with this issue? I guess what I propose here (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674089#35) is the best/safest way to go: 1) something in the release notes 2) the NEWS files of at least mime-types, apache, php5-common (mod_php is not enough) likely also lighthttpd... maybe even more (nautilus? everything using mime-types?) 3) don't then add any default PHP type/handler definitions in the apache config... remove any existing ones. Optionally: 4) Add back a php mime type to mime-types. As outline above... I strongly suggest: application/x-php for this: Neither text/*... nor */php. The root of this bug is obviously a) apache's strang handling of mime-types and handlers and b) lack of clear _and_ safe rules provided by php upstream/deb-package for the end user, on how to enable php. 5) As noted before, I've opened #674205,... where I suggest the IMHO, safest way to get PHP enabled in Apache (there for CGI)... We should lobby the PHP Debian maintainers to add to what I propose there... and also add according documentation for non-CGI php, mainly this: #Note: The following is a security measure to remove any possible mappings that would also apply on “middle extensions” (for example “test.php.png”). RemoveType php Files ?*.php AddType application/x-httpd-php php /Files wihtout the ScriptAlias and Action. See that bug which explains the motivation behind the Remove Type and the Files section Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#674089: mime-support: removed application/x-httpd-* can lead to immense security problems
On Fri, 2012-06-01 at 16:16 +0200, Stefan Fritsch wrote: I would vote for the release notes plus Release notes is a good idea, Stefan, Brian... can anyone of you take care of this or should I (but I'm on vacation starting next Tue, so that would take some time). either apache2 or mod_php NEWS file. It seems exessive to have it in the mime-support NEWS file since it is just noise to all non-apache2 users. I'm not sure whether I can agree... At least mod_php is not enough,... people seem to always forget that it's totally ok (and IMHO from a security point of view even much better) to run PHP as CGI. Neither am I sure, whether Apache is enough, there may be other webservers in Debian that could use mime.types (though I haven't checked this). In principle, as mime-types is the canonical location of the change, the safest place to put it, would be there. see below. Stefan, you haven't commented on this... I've already opened #674205, where I ask the php people to include what I'd consider the safest/best way to handle PHP mime-type in Apache. IF mime.types will really ship no further definitions for PHP AND if that change is accordingly documented in release-notes/NEWS file(s) than I think there should be no definitions for PHP in Apache's default configs at all. The x-httpd- types are really historic ballast from the time there was no separate way to configure the handler (Apache 1.3.x or even 1.2.x). Because of their special properties, they are called magic MIME types in apache httpd. Therefore I think they should be considered an internal (and deprecated) implementation detail of apache httpd and should not be used as real MIME types anywhere else. If we see it from that point, and given that the types are */httpd-* then I'm in principle ok with your interpretation and dropping it from mime.types. But we should perhaps check (how?) whether any other packages have started to use that mime type (things like nautilus/file/etc.) As #589384 explained, declaring them globally is bad for security. And it would be really strange to set these magic types globally just to remove them with RemoveType php again in the default apache2 configuration. Agreed upon. I've added this just a s safety measure to remove any definitions for .php that are potentially already in place and are prone to the foo.php.jpeg problem. But adding a different type for .php to /etc/mime.types is fine with me. There is some discussion at http://cweiske.de/tagebuch/php- mimetype.htm which type may be best. Both text/x-php and application/x-php seem ok to me. As outlined before, I wouldn't use text/ anymore... and further... I'd strongly recommend against any type that is not and */x-* type... (unless there was an official delegation). OTOH,... there's no need to discuss such a type now, right? As soon as someone needs it, he will step up. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#605123: apache2.2-common: incorrect definitions of Common Log Format and Combined Log Format
On Sat, 2012-04-14 at 21:26 +0200, Stefan Fritsch wrote: We had that in the past. The problem with %b is that it gives no indication if the request was a partial request but always logs the size of the complete document. I think that the inaccuracies because of the headers are smaller than inaccuracies because of partial requests, and that %O is more useful in general. Therefore, I close this bug as wontfix. Well than simply rename them? Or at least add a comment that this is not what people (or 3rd party products) may expect. Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#654545: apache2-suexec: some possible security improvements for suexec/suexec-custom
Package: apache2-suexec Severity: normal Hi. Currently suexec is compiled with: -D AP_GID_MIN=100 -D AP_UID_MIN=100 -D AP_SAFE_PATH=/usr/local/bin:/usr/bin:/bin Some things that are perhaps worth to think about: 1) Is there a specific security reason not to include /sbin and /usr/sbin ? I mean any CGI script can just manually call any binary in there. Is it just to avoid accidental invocations of stuff in there? And admittedly,.. most CGI-scripts should have probably no need for programs from there. 2) /usr/local/bin In Debian this is writable by members from the staff group. Of course,... if root adds any user to this group he should know what he does. But perhaps it would make also sense to drop it? If a script really needs it, it can still just use the full path. 3) minimal UID and GID In Debian the UIDs/GIDs are classified as follows: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 It would probably break many setups,.. but perhaps it's worth thinkg about increasing this to 1000. Otherwise suexec can su to most system daemons... OTO I'm of course well aware that this is in many cases what's wanted. Have a look at bug #654543 for a possible even better solution (at least for suexec -custom). Cheers, Chris. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104020749.29168.53472.report...@heisenberg.scientia.net
Bug#605535: apache2.2-common: a2dissite bash completion cannot cope with 000-default/default site
Package: apache2.2-common Version: 2.2.16-4 Severity: minor Hi. It seems that you've added code to a2dissite/a2ensite to nicely handle the special(?) sites default to be added automatically as 000-default. Both tools also provide bash-completion, but a2dissite only identifies the 000-default site, not the default original name. Perhaps (but not sure whether it's really worth it) this might be added. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101130231251.12260.38024.report...@heisenberg.scientia.net
Bug#605123: apache2.2-common: incorrect definitions of Common Log Format and Combined Log Format
Package: apache2.2-common Version: 2.2.16-4 Severity: minor Hi. In the apache2.conf you make some predefined log-formats, including one for the Common Log Format and one for the Combined Log Format. Those are defined there using %O for the number of bytes. Most other resources I could find (e.g. Apache documentation and W3C) use %b however or defined this to be the size of the document being transmitted (therefore without the Header stuff). Althoug I personally also prefer the total raw size (and therfore %O) I'd suggest to use %b here, to be _absolutely_ compatible to everything else. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101127163157.901.74131.report...@heisenberg.scientia.net
Bug#605123: apache2.2-common: incorrect definitions of Common Log Format and Combined Log Format
btw: This applies als to the other vhost combined version. Another reason to really use the _same_ definition of CLF as apache does is, that this format is already hardcoded in case no LogFormat Directive is given and TransferLog is used. smime.p7s Description: S/MIME cryptographic signature
Bug#605125: apache2.2-common: the last LogFormat entry in apache2.conf should be CLF
Package: apache2.2-common
Version: 2.2.16-4
Severity: wishlist
Hi.
Currently the last LogFormat in apache2.conf is (per default):
LogFormat %{User-agent}i agent
For the TransferLog directive, the most recent LogFormat directive
specifies the format.
So may I suggest, to put the combined definition last (which is also
what would have been hardcoded).
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101127164918.1360.93318.report...@heisenberg.scientia.net
Bug#605149: apache2.2-common: mod_authn_default should be enabled by default
Package: apache2.2-common Version: 2.2.16-4 Severity: wishlist Hi. IMHO, mod_authn_default should be enabled in the default config, just as mod_authz_default already is. It probides a fall-back (denying) authorisation provider. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101127221229.12742.11678.report...@heisenberg.scientia.net
Bug#604980: remove/disable /etc/apache2/conf.d/apache2-doc per default
Package: apache2-doc Version: 2.2.16-4 Severity: wishlist Hi. May I suggest to disable or even better remove /etc/apache2/conf.d/apache2-doc per default? I guess most people _don't_ want their servers to the apache documentation provided to the web. IMHO the file should go to some /u/s/d/apache2-doc/example directory. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101125224825.11201.6192.report...@heisenberg.scientia.net
Bug#603586: apache2.2-common: README.Debian claims /etc/apache2/magic would be empty
Package: apache2.2-common Version: 2.2.16-4 Severity: minor Hi. The documentation in /usr/share/doc/apache2.2-common/README.Debian.gz must be wrong, as it claims /etc/apache2/magic would be empty, which is not the case. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101115160932.11418.75515.report...@heisenberg.scientia.net
