On 4 Jun 2015, at 10:32, Michael Scherer <[email protected]> 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@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 _______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
