Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Red Hat Software Businesses Security

Red Hat, Fedora Servers Compromised 278

An anonymous reader writes "In an email sent to the fedora-announce mailing list, it has been revealed that both Fedora and Red Hat servers have been compromised. As a result Fedora is changing their package signing key. Red Hat has released a security advisory and a script to detect potentially compromised openssh packages."
This discussion has been archived. No new comments can be posted.

Red Hat, Fedora Servers Compromised

Comments Filter:
  • by illumin8 ( 148082 ) on Friday August 22, 2008 @10:14AM (#24705065) Journal

    They have taken all the reasonable precautions, and if their passphrase was strong, then the danger of my servers being compromised by meteor strike is a much greater worry.

    The only thing that concerns me is this: In the Fedora announcement, they said with a high level of confidence, they don't believe the passphrase for their signing key was compromised, because they hadn't signed any packages during the period of time the box was compromised. They are going to change the signing key anyway just in case. This is a good thing.

    In the Redhat announcement, we can infer the passphrase and signing key were compromised, because the attacker signed invalid openssh packages. Even though the official RHN distribution channel was not compromised, the attacker most likely still has their private key and passphrase and can continue signing packages and attempting to distribute them. Redhat needs to step up and reissue a new signing key. There was no announcement of this.

  • Re:OpenSSH bug? (Score:2, Informative)

    by tuffy ( 10202 ) on Friday August 22, 2008 @10:22AM (#24705203) Homepage Journal

    Red Hat's OpenSSH bug involves X11 forwarding. As I recall, Debian's OpenSSH bug was a "fix" that dramatically reduced the entropy available for randomizing. I don't believe the two are related.

  • Re:Goes to show (Score:4, Informative)

    by Goaway ( 82658 ) on Friday August 22, 2008 @10:27AM (#24705299) Homepage

    There's absolutely nothing to stop anybody from installing an executable that runs automatically under a user account, without ever needing root. And that executable can do a lot of the things it may want to do without ever needing root access, either.

  • Re:"Compromised?" (Score:5, Informative)

    by corbettw ( 214229 ) <corbettw@ y a h o o . com> on Friday August 22, 2008 @10:45AM (#24705603) Journal

    On a related note, you should not use Fedora in a production environment anyway. That's what RHEL is for. Fedora = Testing. RHEL = Stable. At least in theory.

    I thought it was, RHEL == RedHat Support, Fedora == Community Support. Fedora might have some bleeding edge stuff in it, if you upgrade often, but it seems about as stable as the corresponding RHEL release. The difference is the support you can count on.

  • Re:"Compromised?" (Score:3, Informative)

    by betterunixthanunix ( 980855 ) on Friday August 22, 2008 @10:48AM (#24705665)
    Fedora is not as stable as RHEL. If you want "community support" with RHEL's stability, you should use CentOS. In Fedora 9, we have a beta X server, a bleeding edge kernel, and the disastrous KDE 4.0.
  • by pembo13 ( 770295 ) on Friday August 22, 2008 @10:50AM (#24705699) Homepage
    Targeted mode is actually the weaker of the two modes. The other mode, whose title I've forgotten, checks everything. While targeted mode only does... targeted apps.
  • Re:Goes to show (Score:1, Informative)

    by Anonymous Coward on Friday August 22, 2008 @10:55AM (#24705773)
    Actually, there is a possibility that it can do all of these privileged things, and more.

    Not natively, but there have even been some recent exploits where processes, run without admin privs, can do various things that get it root. Check out vmsplice for instance.

    You ALWAYS want to do everything you can to keep unauthorized people off your system. Once they are in, they can exploit known and unpatched, or not yet widely known issues.

    Privileges are a great way of stopping some compromises but it doesn't stop everything. It's what defense in depth is all about.
  • Re:OpenSSH bug? (Score:2, Informative)

    by xsuchy ( 963813 ) on Friday August 22, 2008 @11:09AM (#24706027)

    I'm from RH...
    No, they are not related. Offical OpenSSH from Fedora or RH repositories do not contain bug (but the low priority X11 forwarding).

    As a precautionary measure, we are releasing an updated version of these SSH packages, if you happend to install previous package from untrusted source (i.e. not RHN).

  • by uslinux.net ( 152591 ) on Friday August 22, 2008 @11:10AM (#24706031) Homepage

    Our RedHat TAM tells us that "the signing infrastructure is completely different between fedora and RHEL" and that RHEL uses "a submit to be signed" method. So essentially, someone submitted packages and the system automatically signed them.

  • by Anonymous Coward on Friday August 22, 2008 @11:12AM (#24706093)

    In the Redhat announcement, we can infer the passphrase and signing key were compromised, because the attacker signed invalid openssh packages.

    Incorrect. The signing key used by Red Hat is inside a hardware security token.

    So even though it was possible to use the token to sign packages as soon as access to the token has been removed for the intruder, he is unable to sign any more packages.

    Mark Cox of the Red Hat security team explained this setup in a blog post some time ago at http://www.awe.com/mark/blog/200701300906.html [awe.com].

  • Re:"Compromised?" (Score:3, Informative)

    by assassinator42 ( 844848 ) on Friday August 22, 2008 @11:19AM (#24706195)
    I'd suggest reading both advisories again. But I'll be nice and spell it out. It seems neither OS's repositories were compromised.
    From the Fedora advisory: "Among our other analyses, we have also done numerous checks of the Fedora package collection, and a significant amount of source verification as well, and have found no discrepancies that would indicate any loss of package integrity."
    From the RHEL advisory: "Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk.".
    Fedora is changing their key as a precaution "because Fedora packages are distributed via multiple third-party mirrors and repositories". While it seems Red Hat doesn't care as much about people getting packages from non-RHN sources, so they just issued an advisory.
    It seems pretty much the same thing happened to each. However, "In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only)."
  • by Anonymous Coward on Friday August 22, 2008 @11:30AM (#24706369)

    They are fairly open and no. unless you know how to break the hardware sigining device the hacker does not control the key, even if they were able to sign malicious packages while in control of the signing system.

  • by adam.dorsey ( 957024 ) on Friday August 22, 2008 @11:33AM (#24706415)

    Watch out! That joke's coming straight for your cranium! ...Whew, it missed and flew completely over your head.

  • Re:"Compromised?" (Score:2, Informative)

    by dstech ( 807139 ) <darksidex3@gmail.com> on Friday August 22, 2008 @11:33AM (#24706421)

    Well, RHEL also mantains a stable kABI within the entire major release, and only rebases packages when absolutely necessary (maintaining most library ABIs as well). For example, RHEL 4 ships apache 2.0.52, and has since launch. Security and bug fixes are backported, but the fundamental behavior remains the same for any instance of RHEL 4. This is also true of libraries.

    This means that a given piece of 3rd-party software is more likely to keep working after an update in RHEL than in Fedora.

  • by Anonymous Coward on Friday August 22, 2008 @11:34AM (#24706443)

    That's not quite correct. First off the "strict" and "targeted" policies have been merged.
    Second SELinux enforces access restrictions on all processes, its just that a number of them have very wide open access. These are loosely referred to as unconfined, but there are a few restrictions even for unconfined processes.

  • by Hatta ( 162192 ) on Friday August 22, 2008 @11:35AM (#24706461) Journal

    the most likely attack was probably from those lame SSH dictionary scans on port 22. This is usually just an extreme annoyance to admins who must provide port 22 service and haven't heard of 'SSHguard'.

    Or just use SSH key authentication, this is what it's for. Anyone clever enough to use SSH on a redhat project server should be able to manage key authentication.

  • Re:Goes to show (Score:3, Informative)

    by fatboy ( 6851 ) on Friday August 22, 2008 @12:00PM (#24706893)

    Mac and Linux are based on UNIX, which was developed for mainframes.
    No, Unix was developed for the PDP-7 and PDP-11. Those were minicomputers, not mainframes.

  • Re:Goes to show (Score:4, Informative)

    by Maznio ( 137785 ) on Friday August 22, 2008 @12:24PM (#24707289) Journal

    Thankfully we have the noexec mounting option available.

    That's no good. Scripts can be run by invoking the interpreter first, like so:
    /usr/bin/perl /home/user/proggie

    and binaries by starting them like so:
    /lib/ld-linux.so.2 /home/user/proggie

  • by Trahald ( 698493 ) on Friday August 22, 2008 @12:55PM (#24707749)
    This is why they don't need new keys: http://www.awe.com/mark/blog/200701300906.html [awe.com] (keys are secure in a hardware device)
  • Re:Goes to show (Score:5, Informative)

    by Wee ( 17189 ) on Friday August 22, 2008 @01:54PM (#24708937)

    If you're going to mount /home noexec, you should also mount /tmp as noexec as well. In fact, I'd wager you should do that well before you bother with /home. A lot of wormy/trojany stuff wants to write, unpack, build and execute in /tmp. In fact, while you're at it, make sure only root can run make and gcc, or get at any of the libs. All command line network tools (wget, ftp, etc) should also only be run by root. Now go through and get rid of most (all?) of the setuid root stuff. Then crank down the firewall to only allow incoming 22 and 80 (or whatever). That will take care of a wide range of automated stuff.


  • Re:Goes to show (Score:3, Informative)

    by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Saturday August 23, 2008 @10:34AM (#24718465)

    I believe /lib/ld-linux.so.2 actually checks that the partition isn't mounted noexec. That doesn't make relying on noexec safe, of course.

    However, selinux can do it securely (even if it could be a pain to define the policy).

egrep -n '^[a-z].*\(' $ | sort -t':' +2.0