Jump to content
Compatible Support Forums

spunz

Members
  • Content count

    10
  • Joined

  • Last visited

    Never

Posts posted by spunz


  1. http://rsync.samba.org/

     

     

     

    December 4th 2003

     

    Background

     

    The rsync team has received evidence that a vulnerability in rsync was recently used in combination with a Linux kernel vulnerability to compromise the security of a public rsync server. While the forensic evidence we have is incomplete, we have pieced together the most likely way that this attack was conducted and we are releasing this advisory as a result of our investigations to date.

     

    Our conclusions are that:

     

    rsync version 2.5.6 and earlier contains a heap overflow vulnerability that can be used to remotely run arbitrary code.

    While this heap overflow vulnerability could not be used by itself to obtain root access on a rsync server, it could be used in combination with the recently announced brk vulnerability in the Linux kernel to produce a full remote compromise.

    The server that was compromised was using a non-default rsyncd.conf option "use chroot = no". The use of this option made the attack on the compromised server considerably easier. A successful attack is almost certainly still possible without this option, but it would be much more difficult.


  2. -------------------------------------------------------------------------------

    GENTOO LINUX SECURITY ANNOUNCEMENT 200312-01

    -------------------------------------------------------------------------------

    Summary : rsync.gentoo.org rotation server compromised

    Date : 2003-12-02

    Exploit : remote

    CVE : - None -

    Priority : Normal

    -------------------------------------------------------------------------------

     

    SUMMARY:

    ========

     

    On December 2nd at approximately 03:45 UTC, one of the servers that makes up

    the rsync.gentoo.org rotation was compromised via a remote exploit. At this

    point, we are still performing forensic analysis. However, the compromised

    system had both an IDS and a file integrity checker installed and we have a

    very detailed forensic trail of what happened once the box was breached, so we

    are reasonably confident that the portage tree stored on that box was

    unaffected. The attacker appears to have installed a rootkit and

    modified/deleted some files to cover their tracks, but left the server

    otherwise untouched.

     

    The box was in a compromised state for approximately one hour before it was

    discovered and shut down. During this time, approximately 20 users

    synchronized against the portage mirror stored on this box. The method used

    to gain access to the box remotely is still under investigation. We will

    release more details once we have ascertained the cause of the remote exploit.

     

    This box is not an official Gentoo infrastructure box and is instead donated

    by a sponsor. The box provides other services not related to Gentoo Linux as

    well and the sponsor has requested that we not publicly identify the box at

    this time. Because the Gentoo part of this box appears to be unaffected by

    this exploit, we are currently honoring the sponsor's request. That said, if

    at any point, we determine that any file in the portage tree was

    inappropriately modified, we will release full details about the compromised

    server.

     

    SOLUTION

    ========

    Again, based on the forensic analysis done so far, we are reasonably confident

    that no files within the Portage tree on the box were affected. However, the

    server has been removed from all rsync.*.gentoo.org rotations and will remain

    so until the forensic analysis has been completed and the box has been wiped

    and rebuilt. Thus, users preferring an extra level of security may ensure

    that they have a correct and accurate portage tree by running:

     

    emerge sync

     

    Which will perform a sync against another server, thus ensuring that all files

    are up to date.


  3. first, lock for the "usb-storage" modul with "lsmod". if you can't find the modul, probe with "modprobe usb-storage"

     

    when the modul loadet, you can mount the usbdevice with "mount /dev/sdaX /mnt"

×