Re: [VOTE] Release httpd-2.4.51-rc1 as httpd-2.4.51
+1 on Fedora 34 On 2021/10/07 13:17:36, "ste...@eissing.org" wrote: > Hi all, > > due to found security weaknesses in our 2.4.50 release, the security team > feels it is necessary to do a new release on very short notice. We will skip > the usual 3 day voting period and close the vote once we feel comfortable > with our testing. > > Please find below the proposed release tarball and signatures: > > https://dist.apache.org/repos/dist/dev/httpd/ > > I would like to call a VOTE over the next few days^h^h^h^hhours to release > this candidate tarball httpd-2.4.51-rc1 as 2.4.51: > [ ] +1: It's not just good, it's hopefully good enough! > [ ] +0: Let's have a talk. > [ ] -1: There's trouble in paradise. Here's what's wrong. > > The computed digests of the tarball up for vote are: > sha1: 516128e5acb7311e6e4d32d600664deb0d12e61f *httpd-2.4.51-rc1.tar.gz > sha256: c2cedb0b47666bea633b44d5b3a2ebf3c466e0506955fbc3012a5a9b078ca8b4 > *httpd-2.4.51-rc1.tar.gz > sha512: > 507fd2bbc420e8a1f0a90737d253f1aa31000a948f7a840fdd4797a78f7a4f1bd39250b33087485213a3bed4d11221e98eabfaf4ff17c7d0380236f8a52ee157 > *httpd-2.4.51-rc1.tar.gz > > The SVN candidate source is found at tags/candidate-2.4.51-rc1. > > Kind Regards, > Stefan
Re: [httpd-site] branch main updated: publishing release httpd-2.4.49
Hi; at the moment the ASF customisation to the tool is tracked in my github fork along with issues. There's no specific place to discuss it other than secur...@apache.org. That's all just because there's only me having worked on it. There are going to be some big changes needed to the tool and running instance in the coming months to support the new CVE Project v5.0 JSON schema, as that is required for more of the future CVE project automation (such as live submission to their database), so that will likely take up all the time I can personally spend updating the tool in the near future. Issues: https://github.com/iamamoose/Vulnogram/issues ASF changes from the upstream Vulnogram code: https://github.com/Vulnogram/Vulnogram/compare/master...iamamoose:asfmaster Regards, Mark J Cox ASF Security On Thu, Sep 16, 2021 at 4:57 PM Ruediger Pluem wrote: > > > On 9/16/21 3:16 PM, Eric Covener wrote: > > On Thu, Sep 16, 2021 at 9:07 AM ste...@eissing.org > wrote: > >> > >> > >> > >>> Am 16.09.2021 um 15:01 schrieb Ruediger Pluem : > >>> > >>> > >>> > >>> On 9/16/21 2:59 PM, ste...@eissing.org wrote: > >>>> And thanks, Rüdiger, for noticing and the quick fixes.\o/ > >>> > >>> And thanks to you for all the release and scripting work. > >> > >> I think we should request some download url feature from the > cveprocess, so that we can automate that part as well. The timeline entry > should be added automatically. The "affected_by" we can at least check and > report. > > > > I'm not sure we have Mark watching here, best to take it to the two > > I fear that as well, but I wanted to avoid crosposts on dev@ and security@ > at the same time due to their different visibility. > In general I think improvements to the CVE tool can be discussed in > public, but I am not sure what the correct venue aka list is > for this topic. > @Mark: Can you give us a hint what is the correct forum to talk about > improvements of the CVE tool? > > > security lists. > > > > Regards > > Rüdiger >
Re: Changing the httpd security process
> > This roughly reverts the httpd process to what we used prior to adopting > > the Tomcat-esque policy for the whole ASF. We would have to document > > this and possibly need it approved by the ASF security team. > > Not sure if we need to have it approved, but at least we should discuss with > the ASF security team. https://s.apache.org/cveprocess allows projects to deviate from the default policy with "review" from the ASF security team. So once you have agreement have the PMC present the proposed policy. This is not an uncommon plan, outside of ASF projects such as OpenSSL have similar policies where lower severity issues (low/moderate) are committed as security fixes prior to and independently of releases. Dealing with security issues in private is a pain in both the process and getting the right fix with limited reviewers. It's worth that pain when the issue is an actual risk to users, less so for the low risk issues. Mark
Re: [Fwd: iDefense Final Notice [IDEF1445]]
For reference, Mitre assigned: CVE-2007-1741 - Path Checking Race Condition Vulnerability CVE-2007-1742 - Path Checking Design Error Vulnerability CVE-2007-1743 - Arbitrary GID Input Validation Vulnerability We can supply statements to Mitre for any we dispute. Mark -- Mark J Cox | www.awe.com/mark
CGI Script Source Code Disclosure Vulnerability in Apache for Windows
See http://marc.theaimsgroup.com/?l=bugtraq&m=115527423727441&w=2 which basically reports "if you put cgi-bin under docroot then you can view cgi scripts on OS which have case insensitive filesystems" Joe replied: http://marc.theaimsgroup.com/?l=bugtraq&m=115574424402976&w=2 and I submitted that as an "DISPUTED" to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraq&m=115583509231594&w=2 I think the right response here is to make it more explicit in the documentation that putting a ScriptAlias cgi-bin inside document root is bad. Mark -- Mark J Cox | www.awe.com/mark
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
[+1] apache_1.3.37 Was easy to compile and test this and a source diff shows only the only code changes is the vulnerability fix. Mark
Re: [Fwd: 2.2+ security page empty?]
>There is nothing on the security page any more for 2.2, is there a bug > with the report you use to populate it? Fixed Cheers, Mark
Re: svn commit: r398494 - in /httpd/site/trunk: docs/security/vulnerabilities_13.html docs/security/vulnerabilities_20.html docs/security/vulnerabilities_22.html xdocs/security/vulnerabilities_22.xml
> This killed the list of vulnerabilities for all versions. Was this intended? > And if yes, where can they be found now? Must be someone with bad java foo, fixing. Mark -- Mark J Cox | www.awe.com/mark
Re: svn commit: r392230 - in /httpd/site/trunk: docs/security/vulnerabilities_13.html xdocs/security/vulnerabilities-httpd.xml
> 1.3 was UNAFFECTED Yes, indeed it was me that insisted that this didn't affect 1.3, I'll revert it :) Cheers, Mark
Security release needed for 2.0
We've a few security issues fixed recently that haven't made it out into releases from the ASF, but have made it out into releases from the various OS vendors. One issue is "important" severity, and public now for 10 days. I don't watch this list much, are there other things holding up a release? If so we ought to consider doing a 2.0.55 with just fixes for these issues over 2.0.54: CAN-2005-2700 important: SSLVerifyClient bypass A flaw in the mod_ssl handling of the "SSLVerifyClient" directive. This flaw would occur if a virtual host has been configured using "SSLVerifyClient optional" and further a directive "SSLVerifyClient required" is set for a specific location. For servers configured in this fashion, an attacker may be able to access resources that should otherwise be protected, by not supplying a client certificate when connecting. public=20050830 [*** needs committing] CAN-2005-2728 moderate: Byterange filter DoS A flaw in the byterange filter would cause some responses to be buffered into memory. If a server has a dynamic resource such as a CGI script or PHP script which generates a large amount of data, an attacker could send carefully crafted requests in order to consume resources, potentially leading to a Denial of Service. public=20050707 [committed] CAN-2005-2088 moderate: HTTP Request Spoofing A flaw occured when using the Apache server as a HTTP proxy. A remote attacker could send a HTTP request with both a "Transfer-Encoding: chunked" header and a Content-Length header, causing Apache to incorrectly handle and forward the body of the request in a way that causes the receiving server to process it as a separate HTTP request. This could allow the bypass of web application firewall protection or lead to cross-site scripting (XSS) attacks. public=20050611 [committed] CAN-2005-1268 low: Malicious CRL off-by-one An off-by-one stack overflow was discovered in the mod_ssl CRL verification callback. In order to exploit this issue the Apache server would need to be configured to use a malicious certificate revocation list (CRL) public=200506085~ [committed] CAN-2005-2491 low: PCRE overflow An integer overflow flaw was found in PCRE, a Perl-compatible regular expression library included within httpd. A local user who has the ability to create .htaccess files could create a maliciously crafted regular expression in such as way that they could gain the privileges of a httpd child. public=20050801 [*** needs committing]
Re: 2.1.6 is available for veto^H^H^H^Hvoting
> I'm obtaining a CVE name for this issue -- (as the issue is already public > it requires co-ordination with Mitre) CAN-2005-2088 Has anyone looked to make sure this doesn't apply to later 1.3 releases? Cheers, Mark
Re: 2.1.6 is available for veto^H^H^H^Hvoting
> Do we have an incident number for this report as it pertains > to the Apache HTTP Server? I'm obtaining a CVE name for this issue -- (as the issue is already public it requires co-ordination with Mitre) Cheers, Mark
Proposed addition to httpd.apache.org
A while ago I promised that we'd give the database of security issues used to generate the Apache Week security pages to the ASF. Yesterday I worked on integrating these pages with httpd-site repos; but since it involves a non-trivial change I wanted to propose it here for an ack or two before actually committing it. The database is just a big XML file and we used XSLT to extract and sort the vulnerabilities relevant to the page for the particular httpd version we're generating. I've created a modified version of the XSLT which extracts the data for the pages and pops it into the velocity format the site uses. So the commit would: Add lib/ant-trax.jar (needed for the xslt) Add security/ directory Add security/vulnerabilities-httpd.xml (database) Add security/impact_levels.xml (http://www.apacheweek.com/features/security-levels) Add stylesheets/securitydb.xsl Add stylesheets/securitydates.xsl Modify build.xsl to run XSLT on vulnerabilities-httpd.xml which creates /security/vulnerabilities_13.xml, an equivalent to http://www.apacheweek.com/features/security-13, and /security/vulnerabilities_20.xml, an equivalent to http://www.apacheweek.com/features/security-30). Diff (minus ant-trax and the resultant /docs/ changes) at http://esoom.com/add-apacheweek-stuff.diff Once this is running I intend to remove this data from Apache Week and redirect the duplicate Apache Week pages to httpd.apache.org, so httpd.apache.org is the master source of this info. Cheers, Mark
CAN-2004-0492 mod_proxy security issue
A security issue has been reported in mod_proxy. See http://www.guninski.com/modproxy1.html The flaw affects Apache httpd 1.3.25 to 1.3.31 that have mod_proxy enabled and configured. Apache httpd 2.0 is unaffected. The security issue is a buffer overflow which can be triggered by getting mod_proxy to connect to a remote server which returns an invalid (negative) Content-Length. This results in a memcpy to the heap with a large length value, which will in most cases cause the Apache child to crash. This does not represent a significant Denial of Service attack as requests will continue to be handled by other Apache child processes. Under some circumstances it may be possible to exploit this issue to cause arbitrary code execution. However an attacker would need to get an Apache installation that was configured as a proxy to connect to a malicious site. 1. On older OpenBSD/FreeBSD distributions it is easily exploitable because of the internal implementation of memcpy which rereads it's length from the stack. 2. On newer BSD distributions it may be exploitable because the implementation of memcpy will write three arbitrary bytes to an attacker controlled location. 3. It may be exploitable on any platform if the optional (and not default) define AP_ENABLE_EXCEPTION_HOOK is enabled. This is used for example by the experimental mod_whatkilledus module. In all other circumstances this issue looks to be unexploitable other than to crash the Apache child that is processing the proxy request. A patch to correct this issue is attached. Note that the reporter of this issue contacted [EMAIL PROTECTED] on June 8th but was unwilling to keep the issue private until the investigation was completed or a new Apache release was available. He published his advisory on June 10th. Mark -- Mark J Cox ... www.awe.com/mark Apache Software Foundation . OpenSSL Group . Apache Week editor Index: src/CHANGES === RCS file: /home/cvs/apache-1.3/src/CHANGES,v retrieving revision 1.1942 diff -u -p -u -r1.1942 CHANGES --- src/CHANGES 2 Jun 2004 22:49:03 - 1.1942 +++ src/CHANGES 9 Jun 2004 15:58:44 - @@ -1,5 +1,9 @@ Changes with Apache 1.3.32 + *) SECURITY: CAN-2004-0492 (cve.mitre.org) + Reject responses from a remote server if sent an invalid (negative) + Content-Length. [Mark Cox] + *) Fix a bunch of cases where the return code of the regex compiler was not checked properly. This affects mod_usertrack and core. PR 28218. [André Malo] Index: src/modules/proxy/proxy_http.c === RCS file: /home/cvs/apache-1.3/src/modules/proxy/proxy_http.c,v retrieving revision 1.106 diff -u -p -u -r1.106 proxy_http.c --- src/modules/proxy/proxy_http.c 29 Mar 2004 17:47:15 - 1.106 +++ src/modules/proxy/proxy_http.c 8 Jun 2004 14:23:05 - @@ -485,6 +485,13 @@ int ap_proxy_http_handler(request_rec *r content_length = ap_table_get(resp_hdrs, "Content-Length"); if (content_length != NULL) { c->len = ap_strtol(content_length, NULL, 10); + + if (c->len < 0) { + ap_kill_timeout(r); + return ap_proxyerror(r, HTTP_BAD_GATEWAY, ap_pstrcat(r->pool, +"Invalid Content-Length from remote server", + NULL)); + } } }
Re: [patch] - digest nonce including MM bump, doc and changes.
> + *) SECURITY - verification as to wether the nonce returned in the > + client response is one we issued ourselves by means of a > + AuthNonce secret exposed as an md5(). See mod_digest documentation > + for more details. The experimental/mod_auth_digest.c does not > + have this issue. [Dirk-Willem van Gulik] > + Use CAN-2003-0987 for this issue Mark -- Mark J Cox ... www.awe.com/mark Apache Software Foundation . OpenSSL Group . Apache Week editor
Re: Why Redhat 8.0 / 9.0 still use 2.0.40 (+ security fixes)
> For those who wonder why Redhat didn't update Apache 2.0 in distro > 8.0 and 9.0, just read : > > http://www.redhat.com/advice/speaks_backport.html Apache httpd was an example that I happened to remember when writing that explanation - Apache is far from the worst offender to mix security updates with other changes in a new release ;) Mark -- Mark J Cox ... www.awe.com/mark Apache Software Foundation . OpenSSL Group . Apache Week editor
Re: cvs commit: httpd-site/xdocs/info security_bulletin_20020809a.txt
On Fri, 9 Aug 2002, Joshua Slive wrote: > [EMAIL PROTECTED] wrote: > > > Revision ChangesPath > > 1.1 httpd-site/docs/info/security_bulletin_20020809a.txt > > > Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt I put in a symlink for now security_bulletin_20020908a.txt -> security_bulletin_20020809a.txt what is the right fix (redirect?) Mark
Re: Apache 2.0 vulnerability affects non-Unix platforms
> Incidentally, I didn't see this get sent to users@httpd and > announce@httpd (it was sent to [EMAIL PROTECTED]). Did I miss it? Doh. So thats two mistakes, where is the third? Mark
Re: cvs commit: httpd-site/xdocs/info security_bulletin_20020809a.txt
> > Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt Hmmm, actually it really ought to be 20020809a.txt like the files I commited, the text that went out was wrong due to too many us-uk conversions ;). A cunning redirect rule in the server config would fix it so 20020908a redirects to 20020809a Cheers, Mark
Apache 2.0 vulnerability affects non-Unix platforms
-BEGIN PGP SIGNED MESSAGE- For Immediate Disclosure === SUMMARY Title: Apache 2.0 vulnerability affects non-Unix platforms Date: 9th August 2002 Version: 1 Product Name: Apache web server 2.0 OS/Platform: Windows, OS2, Netware Permanent URL: http://httpd.apache.org/info/security_bulletin_20020908a.txt Vendor Name: Apache Software Foundation Vendor URL: http://www.apache.org/ Affects: All Released versions of 2.0 through 2.0.39 Fixed in: 2.0.40 Identifiers: CAN-2002-0661 === BACKGROUND Apache is a powerful, full-featured, efficient, and freely-available Web server. On the 7th August 2002, The Apache Software Foundation was notified of the discovery of a significant vulnerability, identified by Auriemma Luigi <[EMAIL PROTECTED]>. This vulnerability has the potential to allow an attacker to inflict serious damage to a server, and reveal sensitive data. This vulnerability affects default installations of the Apache web server. Unix and other variant platforms appear unaffected. Cygwin users are likely to be affected. A simple one line workaround in the httpd.conf file will close the vulnerability. Prior to the first 'Alias' or 'Redirect' directive, add the following directive to the global server configuration: RedirectMatch 400 "\\\.\." Fixes for this vulnerability are also included in Apache version 2.0.40. Apache 2.0.40 also contains some less serious security fixes. More information will be made available by the Apache Software Foundation and Auriemma Luigi <[EMAIL PROTECTED]> in the coming weeks. === REFERENCES The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0661 to this issue. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0661 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBPVQBxu6tTP1JpWPZAQHCwAP9HVzSAMMrXadmRdPfEe9eFUKOxpQA4v8d mKrLciDXnVpPlaKc7/1OHUcCwPu0IucHGUN5sF93Dw3X2BKoAjJFHnmS123r/CP6 WnHAaM+Hl17pPVxI3dXJXbiDvmpBB6b9SNCrsmf0RLykLHVZqoekOh2902Y7+Fts NpKuwE7xzdA= =mEuL -END PGP SIGNATURE-
Re: New httpd.apache.org website...
> http://httpd.ucf.ics.uci.edu/ Looks great. I couldn't few of the links currently on httpd.apache.org (awards, in the news, search, security bug reporting). It would seem that the first two could go in the Miscellaneous section (although it wasn't obvious to me that the section contained more than the bullet points below it). I think it's essential the the home page has a link to security bug reporting; this needs to be prominent and very easy for people to find. [The "in the news" is currently generated from a raw XML feed that I haven't updated in a few months - it's generated out of "in the news" we run in Apache Week; if the build system supports it you could get it to grab the raw feed on some frequent basis] Cheers, Mark -- Mark J Cox ... www.awe.com/mark Apache Software Foundation . OpenSSL Group . Apache Week editor
Re: cvs commit: apache-1.3 Announcement
> Justified fixed courier is the single hardest format in the world to > read. Having generated in excess of a billion documents in my former > life, I will play authority on that ;) Actually I'd not noticed lynx -dump was defaulting to -justify=on :) Mark
Re: Apache 1.3.21 tag this evening....
I've written an "Announcement" file for 1.3.21 and will commit within the hour (just got back from dentist) Mark
Re: [PATCH] adding xml output to mod_status -- [REPOST]
> - on Linux and NetWare I only get the data unformated back, looks as > there are problems with the scoreboard.xsl or so. Any ideas what's Yeah, Mozilla isn't very stable at doing the rendering. Most of the problems you mention are due to the XSLT being done inside the browser. I'm not real worried about problems with the XSL because most of the time you'll want the raw XML data instead, and these browsers will only get better at XSLT over time. > 6.29982236431605997495353221893310546875kB If you look in the XSLT I wanted to use xsl:format-number to round to one decimal place, but Mozilla doesn't support format-number yet. You could probably negotiate the xsl file returned based on user-agent and have several. > you should really change the TZ to numerous expression as Sander > already suggested: Good plan. I wanted to avoid timestamps that are offsets though so the XML data is consistant (and can be compared) across platforms. Cheers, Mark
Re: [PATCH] adding xml output to mod_status -- [REPOST]
> I had a patch which added a '?xml' option > to mod_status. > It's a large (>400 lines) patch, but most of it is puts. > does anyone have any objections to it? At the last ApacheCon I mentioned to a few people that I had written some patches to 1.3 mod_status for XML output but not cleaned them up. After playing with them internally for a while we thought that it made more sense to have a mod_status_xml module: - mod_status is already getting quite convulted having to check for table support and minimal (?auto). - I needed to add a directive, and allow optional commands to tailor the XML output (less output for example) - I wanted some of the output in a different format (dates for example) so the amount of shared code was minimal - Because recent browsers can render the XML into HTML internally (and it involves less bytes transferred) I could see mod_status_xml being used without mod_status I wrote an example sometime in July/Aug but didn't get around to porting it to 2.0. Here is what we have so far http://www.awe.com/mark/dev/mod_status_xml/ Ian's patch is also good; although we've chosen different ways of representing the data (different combinations of attributes too). What we ought to do is to first decide what the XML output is going to look like (it'll be a pain to change this later), then it doesn't really matter if it's a patch to mod_status or a new module. Heres what the module produces (you might have to view source if you get a rendered version) http://www.awe.com/mark/dev/mod_status_xml/example.xml Mark -- Mark J Cox ... www.awe.com/mark Apache Software Foundation . OpenSSL Group . Apache Week editor
[PATCH] add .xsl file extension
Any objections to this patch? Mozilla is quite strict about only parsing stylesheets in text/xml. And according to http://www.w3.org/TR/xslt .xsl is common extension and "The MIME media types text/xml and application/xml [RFC2376] should be used for XSLT stylesheets. It is possible that a media type will be registered specifically for XSLT stylesheets; if and when it is, that media type may also be used." I wanted to add the SVG mime-type too, but it's not in the IANA list yet :( Index: conf/mime.types === RCS file: /home/cvs/apache-1.3/conf/mime.types,v retrieving revision 1.30 diff -u -r1.30 mime.types --- mime.types 2000/10/19 01:02:41 1.30 +++ mime.types 2001/09/24 18:18:08 @@ -415,7 +415,7 @@ text/vnd.wap.wml wml text/vnd.wap.wmlscript wmls text/x-setext etx -text/xml xml +text/xml xml xsl video/mpeg mpeg mpg mpe video/pointer video/quicktimeqt mov