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

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:47 AM, Valeri Galtsev wrote:
> 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.

How sure are you?  On the system I'm looking at right now, any user can 
write to:

/dev/mqueue
/dev/shm
/run/user/<uid>
/run/screen/S-<user>
/var/spool/samba
/home/<user>
/tmp
/var/tmp

Notably, the "screen" and "samba" locations only appear when
the
respective packages are installed, so the places users can write may 
vary from system to system.

Once upon a time, Valeri Galtsev <galtsev at kicp.uchicago.edu>
said:
> 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.
That wasn't the point; the point was that users can only run system
binaries so they can only do what is "permitted".  I don't know
about
python, but perl can make arbitrary kernel system calls (even if they
aren't actually supported by perl), so having perl installed allows
users to do anything a compiled program can do.  Trying to control what
users can do by mounting "noexec" is not particularly limiting, at
least
to somebody determined.

So it may be harder/more cumbersome/etc., but I believe that you could
write exploits in perl or python; it just isn't commonly done in
examples because of the extra work (it's also probably harder to read).

-- 
Chris Adams <linux at cmadams.net>

On Wed, February 15, 2017 1:29 pm, Chris Adams wrote:
> Once upon a time, Valeri Galtsev <galtsev at kicp.uchicago.edu> said:
>> 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.
>
> That wasn't the point; the point was that users can only run system
> binaries so they can only do what is "permitted".  I don't
know about
> python, but perl can make arbitrary kernel system calls (even if they
> aren't actually supported by perl), so having perl installed allows
> users to do anything a compiled program can do.  Trying to control what
> users can do by mounting "noexec" is not particularly limiting,
at least
> to somebody determined.
Thanks for answering. Well, I have seen attempts on my systems, more than
once, and they were unsuccessful, as all user writable on these two
machines was mounted noexec (and also nosuid, nosgid, nodev). Of course,
systems didn't have unpatched known exploits, here we are on the same
page: you have to keep your system updated. So they shouldn't be
successful even if they were executed. Still, noexec is like yet one more
line of defense. Pretty much like we lock front doors of our buildings,
even though we do lock doors of our apartments. Or the same as having
firewall, even though you don't have anything listening to some ports
which is not supposed to. I kind of was repeated too many times by many
people in my life that there is no overdoing when the security is
concerned.

Valeri
>
> So it may be harder/more cumbersome/etc., but I believe that you could
> write exploits in perl or python; it just isn't commonly done in
> examples because of the extra work (it's also probably harder to read).
>
> --
> 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 Wed, February 15, 2017 12:23 pm, Gordon Messmer
wrote:
> On 02/15/2017 08:47 AM, Valeri Galtsev wrote:
>> 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.
>
>
> How sure are you?
I just run a bunch of find commands before rolling out system to find what
I might not like, e.g. finding all world writable files...:

find / -perm -2 ! -type l -ls
...
> On the system I'm looking at right now
Oh, yes, I must confess, I do not tighten up latest Linuxes, my machines
that do need this level of attitude to users are FreeBSD since long ago.
The last Linuxes that needed that were CentOS 5, so logically, you are
right again. And on CentOS 5, as far as the following list is concerned (I
am just marking those that did not exists there on my boxes):
>, any user can
> write to:
>
/dev/mqueue - NOT on CentOS 5
/dev/shm    - there and was mounted with noexec (and others)
/run/user/<uid> - NOT on CentOS 5
/run/screen/S-<user> - NOT on CentOS 5
/var/spool/samba - NOT on CentOS 5 that needs extra security - in our shop;

but there is /var/spool/mail (needs to be writable for locks if it is mbox
format, not maildir)

/home/<user> - mounted with noexec and friends
/tmp - mounted with noexec and friends
/var/tmp - mounted with noexec and friends

And you are right again, there is a lot of hassle (and using separate
partitions to have them noexec). I guess, I was not too lazy with respect
to security back then (and now too, hopefully ;-)

Valeri
>
> Notably, the "screen" and "samba" locations only appear
when the
> respective packages are installed, so the places users can write may
> vary from system to system.
>
> _______________________________________________
> 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
++++++++++++++++++++++++++++++++++++++++