headers
Solar Designer | 1 Feb 01:42
Favicon

Fwd: Apache HTTP Server 2.2.22 Released

I think that only posting to oss-security when there's not yet a CVE ID
assigned (to request one) is weird.  I think it may be more beneficial
to post in here about all security issues in Open Source software -
well, or at least in widely used pieces of software.  As a special case,
when an issue that was first discussed on the private linux-distros or
distros lists is made public, I think this should include a posting to
oss-security (and not only vendor advisories sent via their usual
channels, which vary by vendor).  (No, the Apache issues below were not
on the distros lists.)

----- Forwarded message from "William A. Rowe Jr." <wrowe@...> -----

Date: Tue, 31 Jan 2012 16:34:24 -0600
From: "William A. Rowe Jr." <wrowe@...>
To: announce@...
Subject: Apache HTTP Server 2.2.22 Released

                       Apache HTTP Server 2.2.22 Released

   The Apache Software Foundation and the Apache HTTP Server Project are
   pleased to announce the release of version 2.2.22 of the Apache HTTP
   Server ("Apache").  This version of Apache is principally a security
   and bug fix release, including the following significant security fixes:

   * SECURITY: CVE-2011-3368 (cve.mitre.org)
     Reject requests where the request-URI does not match the HTTP
     specification, preventing unexpected expansion of target URLs in
     some reverse proxy configurations.

   * SECURITY: CVE-2011-3607 (cve.mitre.org)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kurt Seifried | 1 Feb 03:49
Picon
Favicon

Re: Fwd: Apache HTTP Server 2.2.22 Released

On 01/31/2012 05:42 PM, Solar Designer wrote:
> I think that only posting to oss-security when there's not yet a CVE ID
> assigned (to request one) is weird.  I think it may be more beneficial
> to post in here about all security issues in Open Source software -
> well, or at least in widely used pieces of software.  As a special case,
> when an issue that was first discussed on the private linux-distros or
> distros lists is made public, I think this should include a posting to
> oss-security (and not only vendor advisories sent via their usual
> channels, which vary by vendor).  (No, the Apache issues below were not
> on the distros lists.)

Agreed, one thing that would be helpful is to start all CVE requests
with "CVE Request" in the subject line which will make it easy for me to
spot them. Anything informational can be whatever title (like what Solar
Designer sent).

On the other hand how much overlap do we want with full-disclosure/bugzilla?

--

-- 
Kurt Seifried Red Hat Security Response Team (SRT)
Permalink | Reply | 1 comment |
headers
Solar Designer | 1 Feb 05:12
Favicon

Re: Fwd: Apache HTTP Server 2.2.22 Released

On Tue, Jan 31, 2012 at 07:49:05PM -0700, Kurt Seifried wrote:
> On the other hand how much overlap do we want with full-disclosure/bugzilla?

You mean with full-disclosure/Bugtraq (not Bugzilla)?

I think there will be quite little overlap.  Neither of these lists has
anything resembling the full set of security issues even in popular Open
Source projects posted to it - they receive small and arbitrary subsets
instead (plus lots of other stuff that would be offtopic here).  With
mostly CVE requests in here, we also have an arbitrary subset (albeit I
think a larger one).  If we expand that to have good coverage of at
least popular projects that many of us use, that would actually make
this list more unique.

Alexander
Permalink | Reply | 0 comments |
headers
Jan Lieskovsky | 1 Feb 11:55
Picon
Favicon

CVE Request (two ids) -- Xchat-WDK (prior 1499-4 [2012-01-18]) and Xchat-v2.8.6 on Maemo architecture -- Heap-based buffer overflow by processing UTF-8 line from server containing characters outside BMP

Hello Kurt, Steve, Viktor, vendors,

   a heap-based buffer overflow flaw was found in the way xchat, graphical IRC
chat client, processed one line of text received from the server, when the text
contained Unicode characters and some of the characters were outside of the
Basic Multilingual Plane (BMP). A remote attacker could provide a
specially-crafted Unicode string as a xchat channel or private message, which
once processed would lead to denial of service (xchat client crash), or,
potentially arbitrary code execution with the privileges of the user running
xchat client.

This issue has been successfully reproduced on Xchat-WDK versions prior to:
* 1499-4 (2012-01-18)

     add Non-BMP plugin to avoid client crashes

version. Also Joerg Reisenweber reports, this deficiency to have been exploited
in the past on Xchat-v2.8.6 versions, as being used on Maemo architecture.

The following Linux based xchat versions have been investigated against presence
of this issue:
* xchat-v2.6.6,
* xchat-v2.8.6,
* xchat-v2.8.8

on various architectures (i386, x86_64, ppc64) with various versions of gtk2 library:
* gtk-v2.10.4,
* gtk-v2.18.9,
* gtk-v2.24.7,
* gtk-v2.14.7
(Continue reading)

Permalink | Reply | 3 comments |
headers
Berke Viktor | 1 Feb 13:53
Picon
Favicon

Re: CVE Request (two ids) -- Xchat-WDK (prior 1499-4 [2012-01-18]) and Xchat-v2.8.6 on Maemo architecture -- Heap-based buffer overflow by processing UTF-8 line from server containing characters outside BMP

Hello,

Here are my notes:

- Apparently only Windows versions are affected, no Linux ones. I 
haven't tested Maemo but I'd be suprised if it would crash.
- Not all non-BMP characters crash, only a specific range. See the patch 
you linked for details.

if ((suspect >= 0x1D173 && suspect <= 0x1D17A)
			|| (suspect >= 0xE0001 && suspect <= 0xE007F))

- As for your assumption that private messages would still crash, I 
already made a correction in the bug tracker, but for your reference:

"ANY received text will be filtered correctly, be it private or public 
message or anything else. XChat-WDK will ONLY crash if you paste the 
malicious characters into your own client's input box, for which the 
only reason could be to intentionally crash yourself. This obviously 
can't be prevented in XChat-WDK, only if GTK+ fixes it."

That is, current versions of XChat-WDK are immune to these kinds of attacks.

Regards,

Viktor

On 2012.02.01. 11:55, Jan Lieskovsky wrote:
> Hello Kurt, Steve, Viktor, vendors,
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yves-Alexis Perez | 1 Feb 18:30
Picon
Favicon

Re: Re: CVE Request (two ids) -- Xchat-WDK (prior 1499-4 [2012-01-18]) and Xchat-v2.8.6 on Maemo architecture -- Heap-based buffer overflow by processing UTF-8 line from server containing characters outside BMP

On mer., 2012-02-01 at 13:53 +0100, Berke Viktor wrote:
> Hello,
> 
> Here are my notes:
> 
> - Apparently only Windows versions are affected, no Linux ones. I 
> haven't tested Maemo but I'd be suprised if it would crash.
> - Not all non-BMP characters crash, only a specific range. See the
> patch 
> you linked for details. 

It did crash Maemo clients, that's where the report came from.
--

-- 
Yves-Alexis
Permalink | Reply | 0 comments |
headers
Solar Designer | 1 Feb 21:54
Favicon

Re: distros & linux-distros embargo period and message format

On Fri, Jan 20, 2012 at 01:44:45PM +0400, Solar Designer wrote:
> http://oss-security.openwall.org/wiki/mailing-lists/distros
> 
> to state the following:
> 
> "Please note that the maximum acceptable embargo period for issues
> disclosed to these lists is 14 to 19 days, with embargoes longer than 14
> days (up to 19) allowed in case the issue is reported on a Thursday or a
> Friday and the proposed coordinated disclosure date is thus adjusted to
> fall on a Monday or (preferably) a Tuesday.  Please do not ask for a
> longer embargo.  In fact, embargoes shorter than 14 days are preferable."

I've just revised the last sentence above to say "In fact, embargo
periods shorter than 7 days are preferable."

Can we possibly afford to change the maximum to 7 to 11 days (depending
on day of week)?  That is, 7 days is the standard maximum, up to 11 days
is possible if the issue is reported on a Thursday or a Friday (only in
these two cases).  I am for this change (in both my list member for
Openwall and my list admin capacity).  What about others?

(In fact, I'd prefer an even shorter maximum, but I am proposing what I
think has a chance to be approved by others without making the list a
lot less useful to them.)

Also, I added the following to the wiki page:

"Please note that any/all list postings may be made public once the
corresponding security issue is publicly disclosed, so please do not
post information that you want to stay private forever."
(Continue reading)

Permalink | Reply | 17 comments |
headers
Marc Deslauriers | 1 Feb 22:02
Favicon

Re: distros & linux-distros embargo period and message format

On Thu, 2012-02-02 at 00:54 +0400, Solar Designer wrote:
> On Fri, Jan 20, 2012 at 01:44:45PM +0400, Solar Designer wrote:
> > http://oss-security.openwall.org/wiki/mailing-lists/distros
> > 
> > to state the following:
> > 
> > "Please note that the maximum acceptable embargo period for issues
> > disclosed to these lists is 14 to 19 days, with embargoes longer than 14
> > days (up to 19) allowed in case the issue is reported on a Thursday or a
> > Friday and the proposed coordinated disclosure date is thus adjusted to
> > fall on a Monday or (preferably) a Tuesday.  Please do not ask for a
> > longer embargo.  In fact, embargoes shorter than 14 days are preferable."
> 
> I've just revised the last sentence above to say "In fact, embargo
> periods shorter than 7 days are preferable."
> 
> Can we possibly afford to change the maximum to 7 to 11 days (depending
> on day of week)?  That is, 7 days is the standard maximum, up to 11 days
> is possible if the issue is reported on a Thursday or a Friday (only in
> these two cases).  I am for this change (in both my list member for
> Openwall and my list admin capacity).  What about others?

A week is a pretty short delay to prepare updates and perform the
necessary QA to get an issue out on time. Why are you pushing to get the
maximum reduced?

> (In fact, I'd prefer an even shorter maximum, but I am proposing what I
> think has a chance to be approved by others without making the list a
> lot less useful to them.)
(Continue reading)

Permalink | Reply | 14 comments |
headers
Kurt Seifried | 1 Feb 22:34
Picon
Favicon

Re: CVE Request (two ids) -- Xchat-WDK (prior 1499-4 [2012-01-18]) and Xchat-v2.8.6 on Maemo architecture -- Heap-based buffer overflow by processing UTF-8 line from server containing characters outside BMP

On 02/01/2012 03:55 AM, Jan Lieskovsky wrote:
> Hello Kurt, Steve, Viktor, vendors,
> 
>   a heap-based buffer overflow flaw was found in the way xchat,
> graphical IRC
> chat client, processed one line of text received from the server, when
> the text
> contained Unicode characters and some of the characters were outside of the
> Basic Multilingual Plane (BMP). A remote attacker could provide a
> specially-crafted Unicode string as a xchat channel or private message,
> which
> once processed would lead to denial of service (xchat client crash), or,
> potentially arbitrary code execution with the privileges of the user
> running
> xchat client.
> 
> This issue has been successfully reproduced on Xchat-WDK versions prior to:
> * 1499-4 (2012-01-18)
> 
>     add Non-BMP plugin to avoid client crashes
> 
> version. Also Joerg Reisenweber reports, this deficiency to have been
> exploited
> in the past on Xchat-v2.8.6 versions, as being used on Maemo architecture.
> 
> The following Linux based xchat versions have been investigated against
> presence
> of this issue:
> * xchat-v2.6.6,
> * xchat-v2.8.6,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kurt Seifried | 1 Feb 22:45
Picon
Favicon

Re: Mibew messenger multiple XSS

On 01/31/2012 08:22 AM, Henri Salo wrote:
> This seems to need 2012 CVE-identifier.
> 
> Advisory: http://seclists.org/bugtraq/2012/Jan/177
> Codseq own advisory: http://www.codseq.it/advisories/mibew_messenger_multiple_xss
> OSVDB: http://osvdb.org/show/osvdb/78663
> Secunia: http://secunia.com/advisories/47787/
> 
> At the moment http://mibew.org/ does not work for me.
> 
> - Henri Salo

Please use CVE-2012-0829 for this issue.

P.S. for some reason OSVDB lists this as a CSRF issue (?) which is
mentioned in the advisory but not really shown.

--

-- 
Kurt Seifried Red Hat Security Response Team (SRT)
Permalink | Reply | 3 comments |

Gmane