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."
Is this bug in OpenSSH related to the one that was found in Debian-related distros back about April? Maybe I'm reading the article summary incorrectly.
There are plenty things that can be done.
Mounting /home with noexec
Using the grsecurity patch, which can deny execution of files not in directories owned by root, as well as usage of network sockets.
Using SELinux
The tools are there. All that's needed is to use them.
The need to download random binaries to your home directory and run them is infrequent in Linux. The most frequent case is application installers, but many of those need root access anyway (nvidia drivers for instance), and most come with the distribution. A way to fix the occasional need to do this would be a sudo-like tool that needs to be used to execute a file, but doesn't grant root privileges.
God, I seriously hope they don't have the passphrase saved so that you don't need to type it in to sign a package. If that is the case their security is very lax. Also, if it's saved, it almost certainly is compromised, because it's stored on disk somewhere. It would be trivial for the attacker to pull it out of whatever script or text file it's saved in.
"When the president does it, that means it's not illegal." - Richard M. Nixon
What surprises me about this the most is that the system was connected to the network/Internet at all. I had always been of the understanding that to prevent this, the signing server was a stand-alone system accessible only by sneaker-net with physical media. You take your package on CD/DVD/USB key to the server, sign it, then take the signed package back via physical media and distribute it. One Federal Gov.t agency in my home town does this and the server is behind three locked doors too, with three different people needed to get physical access. Why didn't RedHat/Fedora do something like this? It really isn't that much of a pain in the ass when you think about it...
God, I seriously hope they don't have the passphrase saved so that you don't need to type it in to sign a package. If that is the case their security is very lax.
I don't know about anyone else, but I am surprised that their package signing machine is connected via a network to other machines.
Our code signing machine is locked in a cage and powered up only for purposes of code signing. Executables to be signed are written to a previously wiped USB drive which is attached to the signing machine only when packages are to be signed. The signing machine has not been connected to a network since before the keys were generated. The private key only exists on that machine and in a single separately encrypted backup.
I've always considered that to be a minimally paranoid means of keeping private keys private. Really paranoid would be "signed on one machine, checked and signed again on another machine."
Support SETI@home
Our RHEL5/x86_64 system has been affected by this problem: I have ran the script from Red Hat openssh blacklist page, and found that all four openssh packages (openssh, openssh-clients, openssh-askpass, openssh-server) had their checksum on the blacklist. I took the server down, created a backup snapshot of the root disk, and I am currently reinstalling it, while checking other volumes and the root volume snapshot for any signs of intrusion.
The most annoying thing is that Red Hat remains silent on the main problem: what the compromised packages contained, how to determine whether the possible attacker exploited the access offered by those packages or not, when exactly were the packages signed, what other precautions to do on other servers (notify users which use the same password as on a compromised server, check for other modified binaries, etc.). I have verified that I had a trojanized binaries on my system, but apart from that, it is not clear what else the possible attacker managed to do.
Red Hat says the packages were not distributed over RHN, so I wonder how I got them. I had another repository in my yum.conf: rpmforge. Maybe this was the source of the malware. My syslog (even a copy on a syslog server) did not say anything about upgrading openssh in the last month or so. However, on Aug 15 it upgraded the YUM RHN plugin. On the same day our dovecot stopped responding, saying the time went backwards (and yes, there was time move several weeks back and then forward, according to dovecot log). Also the rpm -qi said the package was built on Aug 13 13:13:03, and signed five minutes later. However, the install time reported by rpm on my system was July 25 (which would corelate with the time slip reported by dovecot).
Did anybody else met the trojanized openssh mentioned in the advisory? Please share your findings.
Posting as AC for obvious reasons, sorry.
Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.
They don't need your relay. If they're running on your machine, they can fetch their payload and then start sending it out through your local MTA or configured SMTP server. If you can send e-mail, so can they.
Yes, but without access to the system FF folder, that plugin will go in your per-user plugin directory, and will only run for you. So only your passwords will be stolen, and not those of anyone else on the computer.
Given that most computers running Firefox these days are single-user systems, whether running Linux, OS X, or Windows 98.
Then consider Linux systems. Most systems these days are set up with sudo access, as is OS X. All the bug has to do is watch to see when you run sudo yourself, and then bam, it has a (usually) five-minute window to run itself as root and infect the rest of your system.
It can also grab your ~/.ssh/known_hosts and then reach out to those to see which ones accept your private key; install itself there, and, again, watch for sudo access. It's not hard for someone to go from there out to infecting every machine you have access to, and root on every machine you have root on, and potentially every system that every user on that system has access to, and so on, and so on.