Slashdot Mirror
Red Hat, Fedora Servers Compromised
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."
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.
"When the president does it, that means it's not illegal." - Richard M. Nixon
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.
Ita erat quando hic adveni.
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.
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.
God invented whiskey so the Irish would not rule the world.
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.
Palm trees and 8
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.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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.
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).
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.
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.
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)."
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.
http://www.awe.com/mark/blog/200701300906.html
Watch out! That joke's coming straight for your cranium! ...Whew, it missed and flew completely over your head.
You are still innocent until proven guilty. What's changed is what they do to innocent people. - notnAP, #26891325
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.
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.
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.
Give me Classic Slashdot or give me death!
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.
--fatboy
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
This is why they don't need new keys: http://www.awe.com/mark/blog/200701300906.html (keys are secure in a hardware device)
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.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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).
Finally! A year of moderation! Ready for 2019?