Slashdot Mirror

← Back to Stories (view on slashdot.org)

Details of the PCWeek Securelinux Crack

Posted by Hemos on from the cracking-the-nut-open dept.

gleam writes "The guy who cracked the secure Linux box has posted how he did it. It's a rather interesting read, and it does use a crontab exploit that is present in all versions of RH. " Much more detail then the original story had.

8 of 216 comments (clear)

  1. For Christ's sake by Skyshadow · · Score: 4
    FUD? What the hell are you talking about?

    Look, it may be a "well known bug", but it's still a gaping security hole that got installed with the default RedHat distro. I can foresee a *lot* of situations where this sort of thing would bite a company on the ass. Maybe I'm a new admin. Maybe I'm busy and don't keep up on the latest bug reports. Maybe I just forgot or didn't know how to work around it. The point is, this isn't something I should have to deal with.

    I am so sick of the whining wannabes who seem to be pervading the Linux community lately. It used to be that when someone pointed out a flaw, it was put on a TODO list someplace and fixed; now we just post it up to Slashdot and have everyone yell "This is FUD! PCWeek Sux! I'm 3L337".

    The facts stand as they are: PCWeek installed a default RedHat system and it got cracked. No matter how many times you yell "FUD", this is still a Very Bad Thing(tm). Much like the Mindcraft tests (the second round, anyhow), this shows weaknesses in Linux (or in this case, the most popular distro). These things should be addressed, not spun. Spinning probems or denying their existance is not what makes OSS great.

    ----

    --
    Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
    1. Re:For Christ's sake by bmetzler · · Score: 4
      Look, it may be a "well known bug", but it's still a gaping security hole that got installed with the default RedHat distro. I can foresee a *lot* of situations where this sort of thing would bite a company on the ass. Maybe I'm a new admin. Maybe I'm busy and don't keep up on the latest bug reports. Maybe I just forgot or didn't know how to work around it. The point is, this isn't something I should have to deal with.

      You don't do much work with NT, do you? If you did, you'd realize that patches were an important part of the Administrative Responsibilities. You see, it's just not Linux where vulnerabilities are found and have to be patched. And it's not just OS's. Come ON! I now had to apply a patch to fix a vulnerability in Office 97.

      These things should be addressed, not spun.

      They were addressed. And the page to keep up to date with these issues is well documented.

      -Brent
      --
  2. You are all right... And you are all wrong... by alsta · · Score: 4
    I don't mean to disrespect the professionals that post comments here. Neither do I have any intent of pissing anybody off. But I do believe I have a point.


    1. Somebody pointed out that the Linux distribution used is more secure than the boxed set NT distribution. Paranoid as I am, no system is stronger than it's weakest flaw. NT may have many, but frankly, so does Red Hat. They might not be too many, but they are there.


    2. I agree totally with the people saying that PC Week had done more work with the NT box, than with the Linux one. In fact, this kind of press coverage is only looking bad on PC Week. I remember I saw a full page with documentation on how they set up the NT box. Steps on how they applied the service packs and all. I couldn't find one note on how the Linux box was configured. I think that one that knows how to do so much research on NT, should be able to read webpages and mailinglists for Linux issues.


    3. The most important issue. What did this teach us? PC Week actually brought to light that too many Linux users are ignorant about their security. I remember reading an article in a major PC magazine about firewalls. They brought up different products. Linux based solutions got good security remarks, just because, they were Linux. And NT based ones got bad, because they were NT based. This is not good journalism. Perhaps it is all time that we do more extensive security auditing on our boxes...



    Sincerely,

    Alexander

    --
    Wealth is the product of man's capacity to think. -Ayn Rand
  3. Re:cope? by bmetzler · · Score: 4
    And I am not aware of Red Hat having carried out anything like the level of effort which GM goes through in product recalls. Just saying "a good network admin would have kept up with this" doesn't make it. Your product, your liability.

    Red Hat has an Errata page, they have 2 mailing lists, and for registered users, they have a priority access site. They seem to have the level of effort needed in their case. Now, you show me where I can get on Microsoft's e-mail lists, where their web page is listing their patches, and where they put the patches on their FTP server, and how do I get priority service? They *probably* have all that, but I looked for about 10 minutes and didn't find it. Only took me about 2 minutes to find all I needed on Red Hat's site.

    Second, if Red Hat's effort *isn't* enough, then *you* tell me what it is you are looking for.

    Unless the take-over-the-world faction among Linux advocates want to plaster every commercial distribution with disclaimers shouting "THIS PRODUCT MAY HAVE SERIOUS SECURITY HOLES -- IT IS YOUR RESPONSIBILITY AND YOURS ALONE TO KEEP UP TO DATE WITH THEM"

    That's Microsoft license agreement, isn't it? I *knew* it looked familiar.

    -Brent
    --
  4. Re:How available was this information? by Black+Parrot · · Score: 4

    > How available was this information?

    Real available if you subscribe to Red Hat's update announcement list.

    > How easy is this to fix?

    RH 6.0:

    ncftpget ftp://url/whatever.rpm
    rpm -Uhv whatever.rpm
    /etc/rc.d/init.d/crond restart

    > Is there an updated package to fix this exploit, and where can we get it?

    Visit http://www.redhat.com/corp/support/errata/index.ht ml. You may find some more you want to fetch while you're at it. Be sure to browse the instructions, because some of them require a bit more work than this one did.

    Other distributions have similar arrangements.

    --
    Sheesh, evil *and* a jerk. -- Jade
  5. Re:How available was this information? by scumdamn · · Score: 4

    To reply to my own post (I actually did some research) there is a buffer overflow in chron. Here's the info:
    Package vixie-cron

    Synopsis Buffer overflow in cron daemon

    Advisory ID RHSA-1999:030-02

    Issue Date 1999-08-25

    Updated on 1999-08-27

    Keywords vixie-cron crond MAILTO

    Chron buffer overflow errata page at RedHat

  6. RedHat is NOT Linux! by law · · Score: 5

    I posted this originaly on their forum but it should work here too.

    Look I am rather upset with this continued premise that "Redhat is Linux". It is not.
    I use Debian, it works well and is generally more secure then RedHat.

    On http://www.hackpcweek.com/learned.html
    You state

    "During these tests many people have criticized us for not applying the twenty-one security patches that currently exist for Red Hat 6.0. However, their omission serves to illustrate our
    point. We only installed shipping software available from the vendors for this test (other than the applications of course). No hot fixes were applied to the NT server. We did however install
    service pack five. This was much easier because it was a single file."

    Using Debian and deselect (deselect is the standard package manipulation tool) getting security updates is EASIER than getting and installing a Service Pack, Hell you dont even have to reboot.
    This still would of not of fixed the CGI exploit, it just would of made it that much harder to be rooted.
    Remember Red Hat is NOT Linux.

    --
    "Think of it as evolution in action."
  7. crontab by Signal+11 · · Score: 5

    That was posted to bugtraq almost a month ago - complete with fix. Now... who's at fault - Redhat, or the people who put this contest on with a box stock system with known vulnerabilies? Check it out:

    ------------------------------------------------ ---------------------
    Red Hat, Inc. Security Advisory

    Synopsis: Buffer overflow in cron daemon
    Advisory ID: RHSA-1999:030-01
    Issue date: 1999-08-25
    Updated on:
    Keywords: vixie-cron crond MAILTO
    Cross references:
    ------------------------------------------------ ---------------------

    1. Topic:

    A buffer overflow exists in crond, the cron daemon. This
    could allow local users to gain privilege.

    2. Bug IDs fixed (http://developer.redhat.com/bugzilla/):

    4706

    3. Relevant releases/architectures:

    Red Hat Linux 4.2, 5.2, 6.0, all architectures

    4. Obsoleted by:

    5. Conflicts with:

    6. RPMs required:

    Red Hat Linux 4.2:

    Intel:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/i386/vixie -cron-3.0.1-36.4.2.i386.rpm

    Alpha:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/alpha/vixi e-cron-3.0.1-36.4.2.alpha.rpm

    Sparc:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/sparc/vixi e-cron-3.0.1-36.4.2.sparc.rpm

    Source packages:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/4.2/SRPMS/vixi e-cron-3.0.1-36.4.2.src.rpm

    Red Hat Linux 5.2:

    Intel:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/i386/vixie -cron-3.0.1-36.5.2.i386.rpm

    Alpha:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/alpha/vixi e-cron-3.0.1-36.5.2.alpha.rpm

    Sparc:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/sparc/vixi e-cron-3.0.1-36.5.2.sparc.rpm

    Source packages:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/5.2/SRPMS/vixi e-cron-3.0.1-36.5.2.src.rpm

    Red Hat Linux 6.0:

    Intel:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/i386/vixie -cron-3.0.1-37.i386.rpm

    Alpha:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/alpha/vixi e-cron-3.0.1-37.alpha.rpm

    Sparc:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/sparc/vixi e-cron-3.0.1-37.sparc.rpm

    Source packages:
    rpm -Uvh ftp://ftp.redhat.com/redhat/updates/6.0/SRPMS/vixi e-cron-3.0.1-37.src.rpm

    7. Problem description:

    By creating a crontab that runs with a specially formatted
    'MAILTO' environment variable, it is possible for local users
    to overflow a fixed-length buffer in the cron daemon's
    cron_popen() function. Since the cron daemon runs as root,
    it would be theoretcially possible for local users to use
    this buffer overflow to gain root privilege.

    To the best of our knowledge, no known exploits exist
    at this time.

    Also, it was possible to use specially formatted 'MAILTO'
    environment variables to send commands to sendmail.

    8. Solution:

    For each RPM for your particular architecture, run:

    rpm -Uvh

    where filename is the name of the RPM.

    9. Verification:

    MD5 sum Package Name
    ------------------------------------------------ --------------------------
    a90bf7adbc719fdb5a8ed335fda32a3c i386/vixie-cron-3.0.1-36.4.2.i386.rpm
    2b6b0b00cdeca0381ab2893ddf2f2bd1 alpha/vixie-cron-3.0.1-36.4.2.alpha.rpm
    02d183979b594a7e7a9c1bc8566b2f16 sparc/vixie-cron-3.0.1-36.4.2.sparc.rpm
    b8ac0c21e108ebd67925c224f7a0b82b SRPMS/vixie-cron-3.0.1-36.4.2.src.rpm

    7df6884f0709b078d19f390db2a7e304 i386/vixie-cron-3.0.1-36.5.2.i386.rpm
    b51b4ea612c4f5a59c1bb4e76af95eeb alpha/vixie-cron-3.0.1-36.5.2.alpha.rpm
    5ceeb614442bd4d4ce8a9680664d77e4 sparc/vixie-cron-3.0.1-36.5.2.sparc.rpm
    9f411cb3c7c1c53423eebc9d5f64619a SRPMS/vixie-cron-3.0.1-36.5.2.src.rpm

    39bbedeade7dc6da6f0ab5acfb3af6da i386/vixie-cron-3.0.1-37.i386.rpm
    addec82afbd131aef14fadf8cfb8ddcf alpha/vixie-cron-3.0.1-37.alpha.rpm
    b56db77c411f72825efbffed43780213 sparc/vixie-cron-3.0.1-37.sparc.rpm
    243d9099bdb94bd0d075de4da4dbba12 SRPMS/vixie-cron-3.0.1-37.src.rpm


    These packages are PGP signed by Red Hat Inc. for security. Our key
    is available at:

    http://www.redhat.com/corp/contact.html

    You can verify each package with the following command:

    rpm --checksig

    If you only wish to verify that each package has not been corrupted or
    tampered with, examine only the md5sum with the following command:

    rpm --checksig --nopgp

    10. References:




    --
    To unsubscribe: mail redhat-watch-list-request@redhat.com with
    "unsubscribe" as the Subject.

    --
    To unsubscribe:
    mail -s unsubscribe redhat-announce-list-request@redhat.com /dev/null

    --