CentOS - Feb 2017 - Serious attack vector on pkcheck ignored by Red Hat

Hello Johnny,

On Wed, 2017-02-15 at 09:47 -0600, Johnny Hughes wrote:
> 2.  They already have shell access on the machine in question and they
> can already run anything in that shell that they can run via what you
> are pointing out.
No, assuming noexec /home mounts all they can run is system binaries.
> 3.  If they have access to a zeroday issue that give them root .. they
> can just use that via their shell that they already have (that you gave
> them, which they are using) to get root .. they therefore don't need to
> use this issue at all.
No, assuming noexec /home mounts all they have to leverage a zero day
are system binaries. pkcheck to the rescue.

Regards,
Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research

Once upon a time, Leonard den Ottolander <leonard at den.ottolander.nl>
said:
> On Wed, 2017-02-15 at 09:47 -0600, Johnny Hughes wrote:
> > 2.  They already have shell access on the machine in question and they
> > can already run anything in that shell that they can run via what you
> > are pointing out.
> 
> No, assuming noexec /home mounts all they can run is system binaries.
noexec is not that big of a protection.  On a normal CentOS system, you
almost certainly have python installed (as well as likely other
scripting languages such as perl), and they can be used to do just about
anything compiled code can do.

Plus there's /tmp, /var/tmp, and other directories (depending on
software installed) that are writable by users, so unless you mount
something noexec on all of them, you haven't gained much.

noexec is largely a legacy option at this point.
-- 
Chris Adams <linux at cmadams.net>

On Wed, February 15, 2017 10:22 am, Chris Adams wrote:
> Once upon a time, Leonard den Ottolander <leonard at
den.ottolander.nl> said:
>> On Wed, 2017-02-15 at 09:47 -0600, Johnny Hughes wrote:
>> > 2.  They already have shell access on the machine in question and
they
>> > can already run anything in that shell that they can run via what
you
>> > are pointing out.
>>
>> No, assuming noexec /home mounts all they can run is system binaries.
>
> noexec is not that big of a protection.  On a normal CentOS system, you
> almost certainly have python installed (as well as likely other
> scripting languages such as perl), and they can be used to do just about
> anything compiled code can do.
Indeed, perl and often python are installed on most of servers I run. Not
considering myself security expert, I would like to ask: could you point
to some elevation of privileges exploit written in perl or python? All
I've seen were c/c++, but again I'm just a humble sysadmin.
>
> Plus there's /tmp, /var/tmp, and other directories (depending on
> software installed) that are writable by users, so unless you mount
> something noexec on all of them, you haven't gained much.
And yes, ALL user writable places (including often overlooked /dev/shm)
are mounted with nosuid, nosgid, nodev, noexec options on servers where
users are allowed to have shell. Or you should be able to do something
like jail on FreeBSD which you dedicate to user shell login, and restrict
it the way you need - don't know off hand how you do it on Linux box,
experts will definitely name several ways.

Valeri
>
> noexec is largely a legacy option at this point.
> --
> Chris Adams <linux at cmadams.net>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

On 02/15/2017 08:22 AM, Chris Adams wrote:
> noexec is not that big of a protection.  On a normal CentOS system, you
> almost certainly have python installed (as well as likely other
> scripting languages such as perl), and they can be used to do just about
> anything compiled code can do.

Exactly.  Since python is required by yum (and gettext, and 
systemd-sysv), it's nearly impossible to have a CentOS system without 
python.

Python, of course, includes the "ctypes" module, which allows you to 
load a shared object and call a C function with whatever arguments you 
choose.

You *absolutely* do not need a heap spraying attack in order to make 
arbitrary library or kernel calls.

Leonard, man... you've got let this go.  Users with shell access already 
have fairly broad permission to execute arbitrary code on the system 
they log in to.  The memory leak in pkcheck is *not* a security issue.  
It's just a bug.  *Everyone* is trying to tell you this, including the 
maintainers of CentOS, and (in your original bug report) the maintainers 
of RHEL.  The security bug you've used as a foundation for all of this 
was built on a SUID binary, which pkcheck is not.  What's it going to 
take for you to accept this?  Do you honestly think that you are better 
qualified than all of the maintainers and developers that are telling 
you that this isn't a security bug?

I really want to encourage you to stay involved as a community member.  
Free Software is a participation culture, and every contributor has the 
potential to make the entire system better, but participation is a 
two-way conversation.  You've got to learn to listen, as well.