Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Bug Upgrades

New rsync Released to Fix Vulnerability 226

Posted by CowboyNeal from the better-safe-than-sorry dept.
cshields2 writes "Today the rsync developers have released a new version that fixes an exploitable security vulnerability when running rsync as an 'rsync server.' Any server out there running rsync should check this out and upgrade if necessary. (which is every open source mirror server out there, and many mirrors themselves)"
This discussion has been archived. No new comments can be posted.

New rsync Released to Fix Vulnerability More

New rsync Released to Fix Vulnerability

Comments Filter:

  • Gentoo (Score:5, Informative)

    by lisany ( 700361 ) <slashdotNO@SPAMthedoh.com> on Thursday December 04, 2003 @09:32PM (#7635471)
    This is what got the cracker in (plus the brk kernel thing) into the Gentoo Rsync server. All fixed now tho!

    • Re:Gentoo (Score:5, Insightful)

      by keesh ( 202812 ) on Thursday December 04, 2003 @09:34PM (#7635488) Homepage
      That's, what, 24 hours or so from the attack to a full patch to a previously unknown exploit being released? Gotta give those Gentoo guys some credit, that's damned impressive...

      • Re:Gentoo (Score:1, Interesting)

        by Anonymous Coward
        what would have been more impressive is, if it wouldn't have happened in the first place. I could understand maybe if a port slipped by someone, but shoddy security it's rather sad. Don't take this as a troll post my coworker is a Gentoo devel, and we've spoken about this back and forth.

        What would be nice, would be if some of the developers focused on security from the jump, sort of OpenBSD'ish, and no I'm not making a comparison, sort of throwing an idea for devels to use preemptive strikes, assessing a s

        • Re:Gentoo (Score:5, Insightful)

          by TheIzzy ( 615852 ) on Thursday December 04, 2003 @10:44PM (#7635813)
          Hello?

          Security breaches happen. Even on OpenBSD and other "secure" systems. If you looked into the event at all, you would see that Gentoo did indeed have excellent security counter measures in place. No amount of firewalling is going to stop an *unknown* vulnerability from being exploited. No amount of security auditing is going to find *every* exploit in code as complex as gentoo's. The fact that the compromised server could be restored, and the compromising code be analysed and fixed within twenty-four hours is very impressive. If anything, this is a testiment to the security at gentoo.

          If I were a CTO or someone who was checking to make a switch, this would be very impressive. I don't, however, think this is gentoo's target audience. But I do know that Microsoft definitely does not have turn-around times that impressive.

          • Security breaches happen.

            That's why I wrote Ostiary [homeunix.org], because I can't afford to keep up with all the latest patches the instant they come out. It can be used to remotely enable and disable services (by starting/stopping, them, altering the hosts.allow/deny files, etc.)

            The protocol it uses is so brick stupid it's effectively unhackable. It can still be DOSed, of course, but nobody's come up with a way to directly subvert it. It's very small and light, there's even a Palm client for it. No, it's not the an

        • I'd have to agree to this "trollish" post. Fedora Core 1 came out of the box with a kernel that was patched against this hole. The patch was out, Gentoo and Debian just didn't apply it. Though, the rsync hole did require an apt-get under Fedora to upgrade it.
          • again! It was not Gentoo's server or anything ... it was a third-party rsync server mirror (there are many). Gentoo has told all their mirrors to update to rsync 2.5.7, but they cannot know how every machine is setup around the world. They can make some guidelines to the mirror-hosts, but it is up to them to comply to it, to be a official mirror-site.
            • Ahh, ok. This story is a little trollish by making it sound as if it was a "official" Gentoo server. Though, one of the Gentoo guys should check the "official" rsync mirrors and pull them from the DNS round robin if they are not patched correctly. Of course if there are tons of rsync servers, that could be a little bit too much work.
      • ...a full patch to a previously unknown exploit...

        It certainly wasn't unknown to the cracker.

    • Credits (Score:4, Informative)

      by Anonymous Coward on Thursday December 04, 2003 @09:41PM (#7635518)
      Credits
      -------

      The rsync team would like to thank the following individuals for their
      assistance in investigating this vulnerability and producing this
      response:

      * Timo Sirainen

      * Mike Warfield

      * Paul Russell

      * Andrea Barisani

      Regards,

      The rsync team

      http://lwn.net/Articles/61541/
    • Oddly, i never saw the word "gentoo" mentioned in ANYTHING i read about this update. They only said "a public rsync server".

      It must have been this exploit, though.

  • chroot (Score:4, Insightful)

    by larry bagina ( 561269 ) on Thursday December 04, 2003 @09:36PM (#7635494) Journal
    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.

    Maybe I can't see the forest for the trees, but why would you NOT want to be chrooted?

    • Re:chroot (Score:4, Insightful)

      by syntax ( 2932 ) on Thursday December 04, 2003 @09:37PM (#7635499) Homepage
      How about complete remote backups of the root file system?
      • Agreed. That's exactly what i use it for. (just updated to a patched version too; thank you security.debian.org!)

        The only problem I have is that file permissions are not preserved. My solution is to run:

        ls -Rl / | /usr/bin/bzip2 > /root/perms.txt.bz2

        prior to each backup so that there is at least a record of the permissions. Does anyone know a better way?

        • Re:chroot (Score:4, Informative)

          by toast0 ( 63707 ) <slashdotinducedspam@enslaves.us> on Thursday December 04, 2003 @10:14PM (#7635688)
          use the --perms option to rsync

          from the manpage:

          "This option causes rsync to update the remote permissions to be the same as the local permissions."

          RTFM

        • Re:chroot (Score:3, Informative)

          by Saganaga ( 167162 )
          rsync --help

          Options
          ...
          -a, --archive archive mode, equivalent to -rlptgoD
          ...
          -r, --recursive recurse into directories
          -l, --links copy symlinks as symlinks
          -p, --perms preserve permissions
          -o, --owner preserve owner (root only)
          -g, --group preserve group
          -D, --devices preserve devices (root only)
          -t, --times preserve times
          -S, --sparse handle sparse files efficiently
          ...

          So in other words, you want to use option -p. Or why not just use -a

        • You might want to take a look at Easy Automated Snapshot-Style Backups with Linux and Rsync [mikerubel.org] posted by Mike Rubel. I think this is mentioned in the book Linux Server Hacks [oreilly.com] by O'Reilly (hack #42 [oreilly.com]), although I don't have the book so I'm not sure.

          Basically it uses rsync and cp to create a backup, but only changed files are actually copied; unchanged files are simply linked to. This saves a lot of disk space, and allows you to keep many backups on the system at one time, assuming most of your files don't chang
        • Have a look at rdiff-backup. It uses ssh to login and to run the server on the other side, and runs through the SSH tunnel. Nice from a security perspective. I use it for all of my backup needs. Along with careful use of ssh and private/public key pairs, you can automate it and still keep it fairly secure.

      • While your response is correct, you probably don't want to see the contents of your /etc/passwd or /etc/httpd/ssl.pem to be potentially advertised. A better bet would be to run a chrooted rsync mirror server (if that's your bag), and use a command-restricted public key to rsync over ssh for backups.

    • Re:chroot (Score:2, Funny)

      by Anonymous Coward
      perhaps they were saving themselves for chmarriage

      *boomtish*

      *ducks flying rotten fruit*

  • Workaround (Score:3, Informative)

    by elvum ( 9344 ) on Thursday December 04, 2003 @09:36PM (#7635498) Journal
    ...or just don't run rsync as a server. There's no need to for most uses anyway - just install the client at both ends and connect with the "-e ssh" flag and you're laughing.
    • Duh. There's no work-around if you want to connect anonymously.
      • Other than, of course, a well-known public username and password, such as 'anonymous' and 'anonymous'. Or an anonymous account with no password but who is still permitted to login.

    • Re:Workaround (Score:2, Insightful)

      by morelife ( 213920 )

      don't run rsync as a server

      is not a workaround -- it's throwing the baby and the server out with the bathwater!

    • Re:Workaround (Score:3, Insightful)

      by brassman ( 112558 )
      ...connect with the "-e ssh" flag

      That's how I use it, but I'm not running a site like Gentoo's.

      If I were, I'd rather run an rsync server than give shell logins to every Tom Dick and Mary.

    • Re:Workaround (Score:5, Interesting)

      by pHDNgell ( 410691 ) on Thursday December 04, 2003 @10:04PM (#7635630)
      or just don't run rsync as a server. There's no need to for most uses anyway - just install the client at both ends and connect with the "-e ssh" flag and you're laughing

      What if I don't want system users for every rsync user? What if I need to run my connections through an http proxy server (yes, I really, really do)? What if I want standard mechanisms for listing available modules? What if I want to limit the number of simultaneous connections for a specific area? What if I want to limit the files available in a specific area? What if I want to transfer sensitive files on a system periodically from cron, but I don't want to have an ssh key that grants access to do this without a password on the recipient machine?

      I think that pretty much sums up the ways I most commonly use rsync around the house. I do use it with the -e ssh option for one-off things sometimes as well, but not running a server is certainly no workaround for me.

  • rsync (Score:5, Funny)

    by Anonymous Coward on Thursday December 04, 2003 @09:39PM (#7635511)
    News Flash:

    rsync releases a patch and changes its name to r'sync. The change is noted to increase its name recognition in the teenybopper script kiddie market. At this point, no pimply-faced l337 d00dz will dare deface r'sync for fear that they will be further alienated by the female species.

    Unfortunately, timberlake and FatOne continue to be backdoored.

  • this is why i dont use any package management (Score:3, Funny)

    by n0k14 ( 719810 ) on Thursday December 04, 2003 @09:59PM (#7635604)
    i do it the slack way.
    • This is why I use package management. Hours before I read about this vulnerability on slashdot (read it just now) my redhat monitor had gone red and I had updated the rsync vulnerability without even a thought to when it was discovered. Its interesting that Redhat had the update so quickly though... good to know.
      • Please, do not think I intend to start any distro war, or whatever.

        But since you mentioned RedHat already had a patch, I'd like to say that the updated Mandrake package is also avalilable. And yes, it works for everybody, not just for mandrake club subscribers.

        The main reason I am posting this is for people to see that there are options among the "big distros" to remain with a secure system without having to worry about having an expensive subscription contract signed.

  • arg. (Score:5, Funny)

    by mikeee ( 137160 ) on Thursday December 04, 2003 @10:00PM (#7635606)
    Of course, to patch this, you should go to your local mirror, which will be down until they patch the rsync vulnerablity...

    Doh!

  • Package Download (Score:3, Interesting)

    by Hal The Computer ( 674045 ) on Thursday December 04, 2003 @10:03PM (#7635623)
    Instructions on how to update Slackware to the latest and greatest rsync are at:
    http://slackware.com/security/viewer.php?l=slackwa re-security&y=2003&m=slackware-security.399741 [slackware.com]
    Of course if you're running a server you should theoretically be subscribing to the security mailing list. Right?

  • Fortunately... (Score:1, Informative)

    by Anonymous Coward
    It doesn't look like ersync is open to this particular vulnerability. Although to my knowledge that doesn't run without chroot.

  • FSF Savannah Server Compromised (Score:5, Informative)

    by molo ( 94384 ) on Thursday December 04, 2003 @10:05PM (#7635636) Journal
    The FSF Savannah server has been hacked. The statement indicates a similar attack vector as the exploit against the Debian systems. However, it had been hacked nearly a month ago and was not detected until December 1st. For those that are not familar with it, Savannah is the FSF [fsf.org] version of Sourceforge [sourceforge.net], hosting both GNU and non-GNU Free Software projects. It has not yet been determined whether any of the projects' source code has been modified. Read the full statement [gnu.org] for details. One thing is certain though, with Debian [debian.org], Gentoo [gentoo.org] and now the FSF being exploited in the same month, the open source/free software community is clearly under attack.
    • One thing is certain though, with Debian, Gentoo and now the FSF being exploited in the same month, the open source/free software community is clearly under attack.

      While it can be somewhat distressing, these attacks can only make us stronger.

      It's kinda sad, really. I mean, we're just a big happy group of people who write code for the fun of it, and then share it with everybody else. We're a decent bunch. What did we do to deserve all this hostility?

      • What makes you think the people that do this sort of thing care about what we 'deserve'?

        They could do it for many motivations. On one extreme, there's the profit motivation of an attacker from a competing project (profit in money or recognition - whatever). On the other extreme there's the idiots who do this sort of thing for the hell of it.

        There's any number of reasons people do this sort of thing, and some of them don't even involve a motivation!

    • PGP-sign everything (Score:5, Insightful)

      by Meat Blaster ( 578650 ) on Thursday December 04, 2003 @10:22PM (#7635724)
      I see too many packages out there that have no meaningful way to verify their contents. I've felt for a long time that this was something that was going to come back to haunt us.

      I hope that this will provide more incentive for Open Source programmers and Linux distributors to properly secure their releases. This entails ensuring that from the time a package leaves a maintainer to the time it reaches a user there should be no possibility of tampering.

      Authors/maintainers need to generate PGP keypairs and start signing their archives. MD5 checksum distributed alongside the package does not cut it -- how are we to know the package wasn't tampered with and a fresh checksum generated? No, the only way we can really feel secure is to have authors use PGP on a regular basis to verify their work, and to integrate public key/private key into CVS in order to have submitters automatically sign their changes to the source.

      Then things like the Savannah hack and the various mirror compromises will only be a black eye instead of a serious threat to the Open Source methodology.

      • Re:PGP-sign everything (Score:5, Insightful)

        by giminy ( 94188 ) on Friday December 05, 2003 @01:32AM (#7636649) Homepage Journal
        Hear, Hear. Along the same lines, it's pretty important that they sign with a key in the strongly connected set. I've seen a lot of projects that actually provide PGP sigs, but the keys used to generate the sigs don't have any signatures, or are part of closed (2-3 key) set! This is about as useless as MD5 checksums, imho. It's very easy to generate a key with Linus Torvalds as the name, but very difficult to get people in the strongly connected set to actually sign it...
        • Along the same lines, it's pretty important that they sign with a key in the strongly connected set. I've seen a lot of projects that actually provide PGP sigs, but the keys used to generate the sigs don't have any signatures, or are part of closed (2-3 key) set!

          I agree that would be ideal, but it's easier said than done. I've got no other signatures on my GPG key now. I want to get some, but I don't know anyone else around here who does that sort of thing. How would I go about getting some? I know they h

          • I just took them from linux kernel mailing lists..

            sure they could be wrong, but you'd think the real author would notice someone posting technical messages in his name....
          • I agree that would be ideal, but it's easier said than done. I've got no other signatures on my GPG key now. I want to get some, but I don't know anyone else around here who does that sort of thing. How would I go about getting some? I know they have key signing parties at conventions and such, but I'm a college student, which means I have no money or time to attend such things.

            People take advantage of conventions to organize key-signing parties because diverse groups of people from many geographic locale
            • Organize a local key-signing party. Surely there are many other computer geeks at your college interested in using PGP/GPG. Start getting the geeks together and sign each other's keys. If you can, try to get someone to join the party who is already connected to the worldwide web of trust that most well-known PGP keys are part of. If you can't get anyone well-connected to your key-signing party, don't worry! Creating a local web of trust at your college is a good start, and all it takes isone person who sign
          • I'd suggesting hitting up Big Lumber [biglumber.com]. You can search for local keysigning parties or start your own. I live in the middle of nowhere (Syracuse, NY) and there are even a few people registered around here. Pretty much any college town is going to have some biglumber people in or near it.

            Whenever you travel to a big city, it can be useful to check the site, too. There's nothing like getting a cup of coffee with a crypto nerd to keep you from meeting women in a new city.
        • It's very easy to generate a key with Linus Torvalds as the name, but very difficult to get people in the strongly connected set to actually sign it...

          So wouldn't it make more sense to go to a PKI system and use user certificates issued by a trusted name like Verisign? (giggle).

    • I hope whoever did this was stupid enough to leave some tracks on at least one of the servers. It would be interesting to know who was behind all this.

      OSS has pissed off a lot of very rich and powerful people and those people could pay top dollar for a good cracker so they may never get caught.

  • SSR#4 (Score:2, Funny)

    by Anonymous Coward
    This calls for Standard Slashdot Response #4:
    Yay! This was so fast. Even when we suck we don't suck!

  • I would just like to say... (Score:5, Informative)

    by LnxAddct ( 679316 ) <sgk25@drexel.edu> on Thursday December 04, 2003 @10:28PM (#7635745)
    For all you naysayers who always talk trash about Fedora, I run fedora and debian and fedora alerted me this morning about the problem and patched it in seconds. I updated debian too, but I usually dont update on a daily basis, usually like once a week or something, unless I see something in the news. I would have had no clue about this for about a 3 days if i hadn't read slashdot and didn't have Fedora to alert me. I personally like Debian better for other reasons, but I'm just saying dont bang on Fedora, its a damn good product.

  • Some history.. (Score:5, Interesting)

    by cras ( 91254 ) on Thursday December 04, 2003 @10:55PM (#7635864) Homepage
    Two months ago I found the problem [mail-archive.com] and gave a patch [mail-archive.com] to fix it. Looks like the bad guys were smarter than I thought and figured out a way to exploit it. Lesson: release fixes for even potential security holes immediately :)

  • Only affects Rsync servers (Score:3, Informative)

    by Blue Booger ( 223698 ) on Thursday December 04, 2003 @11:12PM (#7635951)
    (which is every open source mirror server out there, and many mirrors themselves)

    No. This does not affect all the open source mirrors. It only affects rsync SERVERS. If you are not running rsync as a server, you are OK. If you are not accepting connections on 873 you are not running an rsync server. (Well, you could be, but you are probably running it over SSH, in which case you are still OK.)

  • RedHat RPMs for fix (Score:5, Informative)

    by DDumitru ( 692803 ) <`moc.ocysae' `ta' `guod'> on Thursday December 04, 2003 @11:13PM (#7635956) Homepage
    RedHat has also released 2.5.7 RPMs for the fix.

    When updating an older server (7.1, I think), the RH RPM failed with a GLIBC dependency. The updates for RH are identical for 7.1 - 9, so you might have a problem here.

    My easiest workaround was to rebuild the rpm from source with:

    Get the rsync-2.5.7-0.9.src.rpm from RedHat ftp server updates.redhat.com

    Install the source rpm with:

    rpm -ivh /tmp/rsync-2.5.7-0.9.src.rpm

    Build a new complete, clean set of RPMs with:

    cd /usr/src/redhat/SPECS
    rpm -bb rsync.spec

    The new installable binary for your current lib versions is in /usr/src/redhat/RPMS/i386, so you can install it with:

    rpm -Fvh /usr/src/redhat/RPMS/i386/rsync-2.5.7-0.9.i386.rpm

    ---

    For those that don't use rsync, this is easily one of the most useful utilities on the box. I particularily like "modules" mode over ssh. Setup an ssh key and have the key auto-run rynnc --daemon. You get modules and ssh. Really cool.

  • Advisory from the rsync team (Score:3, Informative)

    by gfilion ( 80497 ) on Friday December 05, 2003 @07:22AM (#7637614) Homepage
    here the security advisory of rsync.samba.org:

    rsync 2.5.6 security advisory
    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.
    Please note that this vulnerability only affects the use of rsync as a "rsync
    server". To see if you are running a rsync server you should use the netstat
    command to see if you are listening on TCP port 873. If you are not listening
    on TCP port 873 then you are not running a rsync server.

    New rsync release
    In response we have released a new version of rsync, version 2.5.7. This is
    based on the current stable 2.5.6 release with only the changes necessary to
    prevent this heap overflow vulnerability. There are no new features in this
    release.

    We recommend that anyone running a rsync server take the following steps:

    Update to rsync version 2.5.7 immediately.
    If you are running a Linux kernel prior to version 2.4.23 then you should
    upgrade your kernel immediately. Note that some distribution vendors may have
    patched versions of the 2.4.x series kernel that fix the brk vulnerability in
    versions before 2.4.23. Check with your vendor security site to ensure that
    you are not vulnerable to the brk problem.
    Review your /etc/rsyncd.conf configuration file. If you are using the option
    "use chroot = no" then remove that line or change it to "use chroot = yes".
    If you find that you need that option for your rsync service then you should
    disable your rsync service until you have discussed a workaround with the
    rsync maintainers on the rsync mailing list. The disabling of the chroot
    option should not be needed for any normal rsync server.
    The patches and full source for rsync version 2.5.7 are available from http://
    rsync.samba.org/ and mirror sites. We expect that vendors will produce
    updated packages for their distributions shortly.

    Credits
    The rsync team would like to thank the following individuals for their
    assistance in investigating this vulnerability and producing this response:

    Timo Sirainen
    Mike Warfield
    Paul Russell
    Andrea Barisani
    The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
    the name CAN-2003-0962 to this issue.

    Regards,

    The rsync team

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close