Gentoo rsync server compromised (not exactly)

In regards to the recent compromise of the a server that was hosting a
Gentoo portage tree.

It should be noted that the rsync mirror server is not a direct part of
Gentoo's own infrastructure but a rsync mirror that was in the the main
rotation list. Gentoo has 105 mirrors world wide many of which do not
Gentoo or even Linux.

In no way shape or form can Gentoo Linux guarantee the security of any
mirror.  In an effort to reduce the impact of any potential compromises
that could happen to the end users if they were to sync with an insecure
rsync server hosting a Gentoo portage tree we have pulled every server
out of our rsync round robin dns rotation list and made it a requirement
that all mirrors be running an up2date rsync daemon version [2.5.7] to
be precise.

When they have successfully reported back into us they they have updated
code we will add them back to the rotation. Obviously we/gentoo can not
log into these hosts and preform any type of file system checking to
ensure they to were not compromised. But we have shared with them the
details of what we discovered and asked each and every one of them the
preform some file system checks of there own.

Currently it's still unknown if rsync itself was the root problem of the
compromise of the mirror in question, but evidence thus far seems to
pointing towards it coupled with the recent do_brk() vuln found in the
kernel.

Gentoo's own infrastructure uses and supports PaX for it's memory
protections. If it were not for PaX being used on our own servers
something worse like the our master server could of been compromised.
http://pageexec.virtualave.net/docs/index.html

Plans are currently underway now which attempt to address how end users
could verify that local checksums match remote checksums on ebuild
Manifest's

-------------------------------------------------------------------
Notes for your news about what was found on the compromised mirror.
-------------------------------------------------------------------

- Dec  2 2003 - solar@gentoo
chfgk - binary backdoor.

creation time Dec 02 5:26

chfgk: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped

c81a2d951dffa1f8bfb68b9b9c6ff7d9  chfgk

chfgk* (Intel 386)
Program header table entries: 6 (34 - F4)
 0 T r-x    34    C0 08048034     3 P rw-   720   540 08049720 +4
 1 I "/lib/ld-linux.so.2"         4 L rw-   B54    C8 08049B54
 2 P r-s     0   715 08048000     5 N "GNU"

If your HOME=/etc and CWD=/var/tmp you will get a root shell via this
backdoor otherwise a fake kerberos error msg will be printed.

If the environment SHELL is set, that will be executed instead of
/bin/sh
also this code was compiled using a debian machine.
GCC: (GNU) 3.3.2 20030831 (Debian prerelease) to be precise.

The elf section header table offset is invalid so any binary that using
libbfd such as readelf, objdump, gdb are nearly useless on this binary.
So any debugging begins with ndisasm or IDA. So far I have been unable
to "dress/undress" the binary.

solar@gentoo contacted a member from the PaX team to help with the
initial binary analysis.

Our initial guess is it was left behind as a quick backdoor into the
system, for latter abuse.

chfgk binaries and other various logs are available upon request. -solar

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux Developer/Security Team