Secure testing team - May 2009 - r11940 - data/CVE

Author: gilbert-guest
Date: 2009-05-20 15:16:19 +0000 (Wed, 20 May 2009)
New Revision: 11940

Modified:
   data/CVE/list
Log:
is disregard the best course of action for weaknesses in security hardening
features (e.g. memcached issue)?


Modified: data/CVE/list
==================================================================---
data/CVE/list	2009-05-20 15:04:06 UTC (rev 11939)
+++ data/CVE/list	2009-05-20 15:16:19 UTC (rev 11940)
@@ -1325,6 +1325,9 @@
 	[etch] - memcachedb <no-dsa> (Minor issue)
 	[lenny] - memcachedb <no-dsa> (Minor issue)
 	[squeeze] - memcachedb <no-dsa> (Minor issue)
+	NOTE: why are weaknesses in security hardening features like ASLR considered
minor?
+	NOTE: even though this is not directly a vulnerability itself, part of this
application''s armor is now missing; making it easier for unknown
vulnerabilities to be effective.
+	TODO: reevaluate debian''s position on weaknesses in security
hardening features
 CVE-2008-6679 (Buffer overflow in the BaseFont writer module in Ghostscript
8.62, and ...)
 	- ghostscript 8.64~dfsg-1 (medium; bug #524803)
 CVE-2008-6678 (SQL injection vulnerability in asp/includes/contact.asp in
QuickerSite ...)

Hi,
* Michael Gilbert <gilbert-guest at alioth.debian.org> [2009-05-20
17:21]:
> Author: gilbert-guest
> Date: 2009-05-20 15:16:19 +0000 (Wed, 20 May 2009)
> New Revision: 11940
> 
> Modified:
>    data/CVE/list
> Log:
> is disregard the best course of action for weaknesses in security hardening
features (e.g. memcached issue)?
> 
> 
> Modified: data/CVE/list
> ==================================================================> ---
data/CVE/list	2009-05-20 15:04:06 UTC (rev 11939)
> +++ data/CVE/list	2009-05-20 15:16:19 UTC (rev 11940)
> @@ -1325,6 +1325,9 @@
>  	[etch] - memcachedb <no-dsa> (Minor issue)
>  	[lenny] - memcachedb <no-dsa> (Minor issue)
>  	[squeeze] - memcachedb <no-dsa> (Minor issue)
> +	NOTE: why are weaknesses in security hardening features like ASLR
considered minor?
> +	NOTE: even though this is not directly a vulnerability itself, part of
this application''s armor is now missing; making it easier for unknown
vulnerabilities to be effective.
> +	TODO: reevaluate debian''s position on weaknesses in security
hardening features
Do you honestly think anyone is starting a discussion with 
you via NOTEs? If you want to discuss things, start a thread 
on the mailing list rather than putting notes in the CVE 
list. Besides that I guess whoever tagged that as a minor 
issue didn''t do so because of defeating ASLR with this bug 
but because it''s a bad idea to run memcached in untrusted 
environments with the port open to the outside world.

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090520/a6286532/attachment.pgp>

On Wed, 20 May 2009 17:29:54 +0200, Nico Golde wrote:
> Hi,
> * Michael Gilbert <gilbert-guest at alioth.debian.org> [2009-05-20
17:21]:
> > Author: gilbert-guest
> > Date: 2009-05-20 15:16:19 +0000 (Wed, 20 May 2009)
> > New Revision: 11940
> > 
> > Modified:
> >    data/CVE/list
> > Log:
> > is disregard the best course of action for weaknesses in security
hardening features (e.g. memcached issue)?
> > 
> > 
> > Modified: data/CVE/list
> > ==================================================================>
> --- data/CVE/list	2009-05-20 15:04:06 UTC (rev 11939)
> > +++ data/CVE/list	2009-05-20 15:16:19 UTC (rev 11940)
> > @@ -1325,6 +1325,9 @@
> >  	[etch] - memcachedb <no-dsa> (Minor issue)
> >  	[lenny] - memcachedb <no-dsa> (Minor issue)
> >  	[squeeze] - memcachedb <no-dsa> (Minor issue)
> > +	NOTE: why are weaknesses in security hardening features like ASLR
considered minor?
> > +	NOTE: even though this is not directly a vulnerability itself, part
of this application''s armor is now missing; making it easier for
unknown vulnerabilities to be effective.
> > +	TODO: reevaluate debian''s position on weaknesses in
security hardening features
> 
> Do you honestly think anyone is starting a discussion with 
> you via NOTEs? If you want to discuss things, start a thread 
> on the mailing list rather than putting notes in the CVE 
> list. Besides that I guess whoever tagged that as a minor 
> issue didn''t do so because of defeating ASLR with this bug 
> but because it''s a bad idea to run memcached in untrusted 
> environments with the port open to the outside world.
ok

Nico Golde wrote:
> Besides that I guess whoever tagged that as a minor 
> issue didn''t do so because of defeating ASLR with this bug 
> but because it''s a bad idea to run memcached in untrusted 
> environments with the port open to the outside world.
i don''t want to get into an argument, but i completely disagree.  the
core of this CVE is the fact that ASLR is bypassed.  and if the tcp
port is open by default (and i don''t know if it is because i
haven''t
checked), then that is how 99.9% of users are going to run it.  of
course most sites will have a firewall to the external world, but you
can''t assume that this is the case (in fact, you should always assume
that the user that you are trying to protect is in the worst-case
scenario), and it''s possible for an intruder to be inside the firewall
either via another vulnerability on another system, a misconnected
cable, or by physical presence.

i think NOTEs are a somewhat reasonable place to discuss conflicts of
opinion because it is centralized, connected to the issue at hand, and
the people that triage security issues will come across the
discussion/philosophy, have to think about it, and make a decision.
and finally, it''s easy enough to change the text once that decision
is made.  

however, if the consensus is that this is bad, then i will stop.

ultimately, perhaps the core problem here is that the security tracker
provides no means to allow dissenting/conflicting opinion. note that
dissenting opinions in US Supreme Court decisions are just as important
as the confirming opinions, and are used as the bases for decisions in
all future cases in US courts.

best regards,
mike

Let''s just split this discussion, and continue with the
discussion-in-NOTE
issue here.
> i think NOTEs are a somewhat reasonable place to discuss conflicts of
> opinion because it is centralized, connected to the issue at hand, and
> the people that triage security issues will come across the
> discussion/philosophy, have to think about it, and make a decision.
> and finally, it''s easy enough to change the text once that
decision
> is made. ?
>
> however, if the consensus is that this is bad, then i will stop.
> ultimately, perhaps the core problem here is that the security tracker
> provides no means to allow dissenting/conflicting opinion.
I don''t think this is a problem. The security tracker is indeed not the
place
to have discussions, or to register dissenting opinions. It''s intended
to
document the outcome of the discussions (if any): what is the current state 
and what action needs to be taken?

Taking the ''no-dsa'' issue: either there''s going to be
a DSA, or there''s not
going to be a DSA. That fact can be debated just fine on our mailinglists or 
in a relevant bug. Those means provide much better overviews and space for 
who thinks what, to respond to arguments etc. In the end there has to be a 
conclusion, we do either this or that. That conclusion/decision will be 
documented in the tracker.
> note that 
> dissenting opinions in US Supreme Court decisions are just as important
I cannot envision any security issue that would be comparable to a supreme 
court case, nor can I even begin to think that we are operating even remotely 
like a "supreme court".


Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090520/3d7cb7c7/attachment-0001.pgp>

On Wed, 20 May 2009 18:43:15 +0200, Thijs Kinkhorst
wrote:
> Let''s just split this discussion, and continue with the
discussion-in-NOTE
> issue here.
> 
> > i think NOTEs are a somewhat reasonable place to discuss conflicts of
> > opinion because it is centralized, connected to the issue at hand, and
> > the people that triage security issues will come across the
> > discussion/philosophy, have to think about it, and make a decision.
> > and finally, it''s easy enough to change the text once that
decision
> > is made. ?
> >
> > however, if the consensus is that this is bad, then i will stop.
> 
> > ultimately, perhaps the core problem here is that the security tracker
> > provides no means to allow dissenting/conflicting opinion.
> 
> I don''t think this is a problem. The security tracker is indeed
not the place
> to have discussions, or to register dissenting opinions. It''s
intended to
> document the outcome of the discussions (if any): what is the current state
> and what action needs to be taken?
> 
> Taking the ''no-dsa'' issue: either there''s going
to be a DSA, or there''s not
> going to be a DSA. That fact can be debated just fine on our mailinglists
or
> in a relevant bug. Those means provide much better overviews and space for 
> who thinks what, to respond to arguments etc. In the end there has to be a 
> conclusion, we do either this or that. That conclusion/decision will be 
> documented in the tracker.
ok, i agree with this philosophy in intent.  however, in practice i
see some problems:

1. if discussion happens in the relevant bug, then the security team
will not automatically be made aware of that discussion (solution
would be to forward all discussion on bugs marked security to
secure-testing-team list).

2. if discussion happens on the security mailing list, the maintainer
will not be aware, and there is no link to the discussion from the
tracker for posterity.
> > note that 
> > dissenting opinions in US Supreme Court decisions are just as
important
> 
> I cannot envision any security issue that would be comparable to a supreme 
> court case, nor can I even begin to think that we are operating even
remotely
> like a "supreme court".
just making a light-hearted analogy of the importance of giving everyone
a voice and the importance of recording that voice for future posterity
(specifically for anyone who does research using the tracker).

mike

Hi,
* Michael S. Gilbert <michael.s.gilbert at gmail.com> [2009-05-21
10:23]:
> On Wed, 20 May 2009 18:43:15 +0200, Thijs Kinkhorst wrote:
[...] 
> > Taking the ''no-dsa'' issue: either there''s
going to be a DSA, or there''s not
> > going to be a DSA. That fact can be debated just fine on our
mailinglists or
> > in a relevant bug. Those means provide much better overviews and space
for
> > who thinks what, to respond to arguments etc. In the end there has to
be a
> > conclusion, we do either this or that. That conclusion/decision will
be
> > documented in the tracker.
> 
> ok, i agree with this philosophy in intent.  however, in practice i
> see some problems:
> 
> 1. if discussion happens in the relevant bug, then the security team
> will not automatically be made aware of that discussion (solution
> would be to forward all discussion on bugs marked security to
> secure-testing-team list).
I see no problem with that in practice, the security team 
gets Cced on all security bugs and it''s our job to keep 
track of the important ones then and follow the bug reports. 
Besides that there are people like me following 
debian-bugs-dist.
> 2. if discussion happens on the security mailing list, the maintainer
> will not be aware, and there is no link to the discussion from the
> tracker for posterity.
Also rather a workflow problem than a technical one. If 
people forget to Cc the relevant people, change that.
> > > note that 
> > > dissenting opinions in US Supreme Court decisions are just as
important
> > 
> > I cannot envision any security issue that would be comparable to a
supreme
> > court case, nor can I even begin to think that we are operating even
remotely
> > like a "supreme court".
> 
> just making a light-hearted analogy of the importance of giving everyone
> a voice and the importance of recording that voice for future posterity
> (specifically for anyone who does research using the tracker).
You have a voice ;)

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20090521/40262945/attachment.pgp>