[gentoo-security] #342619 RESOLVED WONTFIX

[gentoo-security] #342619 RESOLVED WONTFIX

[dev-random]

#342619 [http://bugs.gentoo.org/342619]
RESOLVED WONTFIX

Are you intentionally leaving security hole in system?

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Kirktis]

and people wonder why gentoo is not taken seriously by the enterprise.

On 10/27/10, dev-random@mail.ru <dev-random@mail.ru> wrote:
> #342619 [http://bugs.gentoo.org/342619]
> RESOLVED WONTFIX
>
> Are you intentionally leaving security hole in system?
>
>
>

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Volker Armin Hemmann]

On Wednesday 27 October 2010, Kirktis wrote:
> and people wonder why gentoo is not taken seriously by the enterprise.
> 
> On 10/27/10, dev-random@mail.ru <dev-random@mail.ru> wrote:
> > #342619 [http://bugs.gentoo.org/342619]
> > RESOLVED WONTFIX
> > 
> > Are you intentionally leaving security hole in system?

please show me some enterprise distros incorporating that patch.

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Mateusz Arkadiusz Mierzwinski]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

2010/10/27 Volker Armin Hemmann <volkerarmin@googlemail.com>

> On Wednesday 27 October 2010, Kirktis wrote:
> > and people wonder why gentoo is not taken seriously by the enterprise.
> >
> > On 10/27/10, dev-random@mail.ru <dev-random@mail.ru> wrote:
> > > #342619 [http://bugs.gentoo.org/342619]
> > > RESOLVED WONTFIX
> > >
> > > Are you intentionally leaving security hole in system?
>
> please show me some enterprise distros incorporating that patch.
>
>
This is not usable issue of one or another patch. This is something
un-serious to the companies. Should we upgrade our servers or not? I'ts like
ticking bomb! Upgrading... Block! Removing, upgrading... Compilation fail
because of some strange thing happen - maybe sun eruption or something else.
Now collection is expanded to patches that will not be mainstreamed :> This
is GOOD PRACTICE :). Thinking about Debian on servers - tell me why? - after
4 years with Gentoo :>

-- 
Mateusz Mierzwiński

Bluebox Software [PL]
Neural Networks, Artificial Perception and Artificial Intelligence projects
coordinator

[-- Attachment #2: Type: text/html, Size: 1594 bytes --]

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[dev-random]

On Wed, Oct 27, 2010 at 08:33:56PM +0200, Volker Armin Hemmann wrote:
> please show me some enterprise distros incorporating that patch.

I didn't test that patch; even if it's incorrect, bugreport is not about
a patch. It's about a security issue.

For example, look here:
http://seclists.org/fulldisclosure/2010/Oct/344

This proof-of-concept exploit still works in gentoo (amd64 stable at least,
even hardened!), because some dangerous variables are not filtered out.

(note if you want to test it: vixie-cron won't execute created file
because it's not executable. Either use another crond, or use exploit to
create e.g. udev rule instead of crontab entry).


Another similar vulunerability caused by not filtering some variables was
found about a week ago. I don't know if it still works in Gentoo, because
hardened is not affected by that one.
http://seclists.org/fulldisclosure/2010/Oct/257

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Pavel Labushev]

> eruption or something else. Now collection is expanded to patches that
> will not be mainstreamed :> This is GOOD PRACTICE :). Thinking about

Another distros do include patches for glibc not accepted by mainstream.

In this particular case the patch is pretty trivial. And how many users
actually need those LD_* vars to be handled for setuid/setgid binaries?
My bet it's less than 1% of them, and even less than 0.1% of Hardened users.

And what's the problem with including the patch only for glibc[hardened]
and/or glibc[-debug]? I guess that's what at least Hardened users want:
to proactively secure their system, even at the expense of some
debugging facilities (PIE vs <gdb-7.1 as an example).

To reject the patch without any explaination was one man's decision I do
not agree personally, especially after Gentoo security team failed to
fix the recent glibc vulns in a timely manner.

On another point, if some users want this particular patch to be
included, they should speak for themselves. By now I don't see much
interest even among #gentoo-hardened people.

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Pavel Labushev]

> I didn't test that patch; even if it's incorrect, bugreport is not about
> a patch. It's about a security issue.

Well, the bug report is about the patch. There's another bug about the
issues with LD_AUDIT: https://bugs.gentoo.org/show_bug.cgi?id=341755

> This proof-of-concept exploit still works in gentoo (amd64 stable at least,
> even hardened!), because some dangerous variables are not filtered out.

It still works because glibc-2.11.2-r2 with the fix is still keyworded
(yeah, epic fail goes on).

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Mateusz Arkadiusz Mierzwinski]

[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]

2010/10/28 Pavel Labushev <p.labushev@gmail.com>

> > I didn't test that patch; even if it's incorrect, bugreport is not about
> > a patch. It's about a security issue.
>
> Well, the bug report is about the patch. There's another bug about the
> issues with LD_AUDIT: https://bugs.gentoo.org/show_bug.cgi?id=341755
>

"The beat goes on! Nothings wrong!...". Tell me - If app have bug - like
"calc" ;) app in KDE - who uses it? Developers will not patch app because
it's less then 1% users that use it in KDE? I don't think so. Even if it's
lower priority patch i think it should be included in mainstream. It's like
buying a car, that closes by remote but 1% of users will still use key for
central lock - ups! None included? Service: "Sorry! That's not mainstream
;). You must install it by Yourself"  :].


>
> > This proof-of-concept exploit still works in gentoo (amd64 stable at
> least,
> > even hardened!), because some dangerous variables are not filtered out.
>
> It still works because glibc-2.11.2-r2 with the fix is still keyworded
> (yeah, epic fail goes on).
>
>
Let's keyword everything, push "da blocks, man!" on every package and this
will be most secured distro :>. Great Job! :)

I think, that Gentoo Devs forget about something more important in today's
world - USABILITY. The "normal" user without "extra abilities" will not
Patch anything because he don't even know what PATCH is. Developers have
those users TOO on Gentoo. This is strenght of Mandriva, Debian-like distros
(Ubuntu line specialy). Users click and software works, it upgrades and if
bug is get the patch is downloaded with latest update. Tell mister "Marian"
from accounting that he must PATCH something. I like that kind of face look
of that people after saying that Junk -> :] "Yeah! Sure... What icon should
I press in My "K" Menu?".

Devs should include patches in mainstream even if it's less prior patch.
Why? Because it takes about 2-10 (knowledge level) minutes extra and drops
discussions like this one. 10 Minutes extra VS silence - i think it's fair
:).



-- 
Mateusz Mierzwiński

Bluebox Software [PL]
Neural Networks, Artificial Perception and Artificial Intelligence projects
coordinator

[-- Attachment #2: Type: text/html, Size: 3010 bytes --]

Re: [gentoo-security] #342619 RESOLVED WONTFIX

[Kfir Lavi]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

2010/10/28 Mateusz Arkadiusz Mierzwinski <mateuszmierzwinski@gmail.com>

> 2010/10/28 Pavel Labushev <p.labushev@gmail.com>
>
> > I didn't test that patch; even if it's incorrect, bugreport is not about
>> > a patch. It's about a security issue.
>>
>> Well, the bug report is about the patch. There's another bug about the
>> issues with LD_AUDIT: https://bugs.gentoo.org/show_bug.cgi?id=341755
>>
>
> "The beat goes on! Nothings wrong!...". Tell me - If app have bug - like
> "calc" ;) app in KDE - who uses it? Developers will not patch app because
> it's less then 1% users that use it in KDE? I don't think so. Even if it's
> lower priority patch i think it should be included in mainstream. It's like
> buying a car, that closes by remote but 1% of users will still use key for
> central lock - ups! None included? Service: "Sorry! That's not mainstream
> ;). You must install it by Yourself"  :].
>
>
>>
>> > This proof-of-concept exploit still works in gentoo (amd64 stable at
>> least,
>> > even hardened!), because some dangerous variables are not filtered out.
>>
>> It still works because glibc-2.11.2-r2 with the fix is still keyworded
>> (yeah, epic fail goes on).
>>
>>
> Let's keyword everything, push "da blocks, man!" on every package and this
> will be most secured distro :>. Great Job! :)
>
> I think, that Gentoo Devs forget about something more important in today's
> world - USABILITY. The "normal" user without "extra abilities" will not
> Patch anything because he don't even know what PATCH is. Developers have
> those users TOO on Gentoo. This is strenght of Mandriva, Debian-like distros
> (Ubuntu line specialy). Users click and software works, it upgrades and if
> bug is get the patch is downloaded with latest update. Tell mister "Marian"
> from accounting that he must PATCH something. I like that kind of face look
> of that people after saying that Junk -> :] "Yeah! Sure... What icon should
> I press in My "K" Menu?".
>
LOL, I would like to know "Marian" in person and his habbits of upgrading
OOcalc.
I wonder how he edit his /etc/make.conf, hehe, with windows edit?! :-P
Seriously, Gentoo is a system for "Marian" if and only if his friend
"SuperUser" keep his system running.
And by the same token, go to your next desk friend who is a computer
scientist and ask him to install gentoo. (GENGOO WHAT???!!! SOUNDS LIKE A
GOOD BUNGEE CORD ;-)
Gentoo is for us, not for them...

>

Devs should include patches in mainstream even if it's less prior patch.
> Why? Because it takes about 2-10 (knowledge level) minutes extra and drops
> discussions like this one. 10 Minutes extra VS silence - i think it's fair
> :).
>
>
>
>
> --
> Mateusz Mierzwiński
>
> Bluebox Software [PL]
> Neural Networks, Artificial Perception and Artificial Intelligence projects
> coordinator
>

[-- Attachment #2: Type: text/html, Size: 4271 bytes --]