What happened with Fedora - and Red Hat too

Read for content, and Don't Panic.

The Red Hat statements say that the packages are being replaced as a precaution. 

They do not state that the package contents have been altered in any fashion.

I think they're saying that someone built some bad ssh packages and managed to get the system
to sign them before they got shut out. I don't think they're saying those packages got
distributed via Red Hat.

So, unless you're getting your RPMs from some dodgy place, it's not a problem. I guess the
main worry would be people cracking a system and installing those RPMs - they'd be difficult
to tell apart from the real thing without those check scripts Red Hat put up.

It sounds like the Fedora systems stood up to the attack pretty well, though. 

"Channels" may have been a poor choice of terminology, given its usage in an RHN context.

Essentially, what this means is:

"We are issuing this alert primarily for those who obtain Red Hat binary packages from sources
other than Red Hat Network."

I assume that some people run RHEL but don't want to pay Red Hat. Red Hat don't provide
binaries to such people, but nothing stops you (a Red Hat subscriber) from taking most RHEL
packages and uploading them to a public FTP server, this isn't even illegal, at least for the
vast majority of packages. People who download those packages have only the RPM signature to
rely on to prove that they're authentic rather than being trojan code you uploaded to exploit
them. Whereas you, as a subscriber have the additional protection of Red Hat's site security.

There's no good reason to do this sort of thing when CentOS exists (and when RHEL
subscriptions are comparatively cheap), but then there's no good reason to climb Everest and
plenty of people do that too.

It will probably take a bit of time. A breach of a publically traded company will be
investigated by various US Federal law enforcement and possibly other agencies(not sure if the
stock people have to look).. those agencies will put a legal clamp on releasing any
information until their investigation is done and they are sure that releasing the information
will not damage their investigation or possible future court case. 

That basically means that Red Hat/Fedora can't say anything without getting an ok from their
legal who has to get an ok from the various investigating groups who will have to co-ordinate
with each other to give an ok. 

[phew...]

It isn't uncommon for large organisations to have shared authentication systems distributed via LDAP or similar, so having the same password on multiple boxes is not that surprising.

Also, it isn't uncommon for people to use the same SSH key pair to log into multiple servers, so that is another possible explanation for both RH and Fedora infrastructure being breached in a single attack.

Create user SSH private keys only on machines you have physical control over, or where local policy prohibits such caution, on a few machines where you have the most confidence of their integrity.

Use a passphrase to protect the keys. Use SSH agent software. The agent software uses the passphrase to unlock a key and hold it in memory temporarily. If the key files (stored on disk) are obtained by malicious third parties (e.g. by accessing backups, old drives mistakenly sold without being wiped) they are useless without the passphrase to decrypt them.

You can then use the key to log into machines without presenting a password at all, if the target machine is compromised you reveal only the relatively worthless public key identity of your user. An attacker witnessing hundreds of logins of this sort with full root access on the target machine learns nothing except the identities of frequent users. Contrast this to the situation with passwords, where he learns hundreds of valuable passwords.

Where convenience (or e.g. firewall policy) dictates that you SSH into one security pivot machine A and from there into others (B ... Z), you have two choices which reflect different security beliefs about the machines.

1. SSH to machine A, separate key on that machine for SSH to B ... Z. This keeps security of the set A ... Z separate from security for any other machines you have access to. An attacker in full control of A can authenticate (using the key stored on A) to other alphabetic machines at will but not elsewhere.

2. SSH agent tunnel. Local machine SSH agent is tunnelled to A for authenticating connections from A to other alphabetic machines. This limits power of attacker in full control of A to hijacking your authentication capability when you are logged into A. They can authenticate to any system for which your key validates, not just A ... Z, but the key and its passphrase remain inviolate on your local system.

In either case attackers who somehow have privileges on other alphabetic machines (B ... Z) learn nothing helpful and cannot leverage their privileges to attack other systems via SSH.