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=bugtraqm=115527423727441w=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=bugtraqm=115574424402976w=2 and I submitted that as an DISPUTED to CVE But the original reporter disagrees: http://marc.theaimsgroup.com/?l=bugtraqm=115583509231594w=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: [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
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
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
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
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: 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
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: [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: 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
