[Gluster-infra] download.gluster.org was rooted

[Justin Clift]

On 4 Jun 2015, at 10:32, Michael Scherer <mscherer at redhat.com> wrote:
> Le jeudi 04 juin 2015 à 00:49 +0200, Michael Scherer a écrit :
>> Le jeudi 04 juin 2015 à 00:01 +0200, Michael Scherer a écrit :
>>> Le mercredi 03 juin 2015 à 17:09 -0400, Kaleb Keithley a écrit :
>>>> I just deleted an suid-root /tmp/usr/bin/suexec script from download.gluster.org
>>> 
>>> We need to investigate a bit more...
>> 
>> And by that, I mean "we shouldn't remove clues". So it turn out that
>> supercolony has the same issue :
>> 
>> [root at supercolony tmp]# ls -l usr/sbin/suexec 
>> -r-s--x---. 1 root root 13984 Dec 19 16:05 usr/sbin/suexec
>> 
>> Looking at the log, I was connected at the same time, but the ip look
>> like the one of the coworking space I work from, so I do think either
>> the log have been tempered with, or this didn't came from ssh.
>> 
>> It look furiously similar to a regular suexec, same size of the binary,
>> and dissambly do not so obvious difference ( I am not good enough to
>> spot issue in the 3 lines of asm ).
> 
> So after sleeping on it and drinking, I found out the only difference is
> the build-id and some debug related stuff.
> 
> suexec is also hardly exploitable as is, due to a ton of restrictions.
> 
> In fact, i cannot find any scenario where this would be a attacker. This
> binary cannot be used to elevate privilege, and given the permission, it
> was placed here by root or a root owned process, so if there was a hack,
> it was not here. 
> 
> So I suspect some cronjob running somewhere that created it, or a bug in
> some script.
> 
> Anyway, we should reinforce security.
> 
> Like selinux set to enforcing, and the noexec on /tmp is also a good
> suggestion, having key only ssh, etc, etc.
> 
> Of course, we cannot get too aggressive on security as this might break
> production. And not all servers are in salt (yet), so it is hard to
> enforce a policy. 
> 
> But for me, this is case closed for now, unless someone has something
> new.

Yeah, it kind of sounds like someone/something (not me) did a build with
--prefix=/tmp, and forgot to remove it afterwards.  Or they were in the
wrong ssh window when they did this. eg: thought they were on a different
box.

Using --prefix=/tmp is definitely something I've done before when doing
test builds of code, which is why the above is sounding pretty likely
to me. ;)

+ Justin

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift