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."

Comments

Nothing to see here.

[Art Popp]

These are the guys, to the annoyance of nearly everyone, who turned on SELinux on Fedora Core by default.

These are the guys who noticed they annoyed everyone, and turned on targeted-mode by default.

Coming from someone with many systems, completely exposed to the Internet, with thousand day uptimes, these RedHat folk are in fact sufficiently paranoid.

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.

Re:Nothing to see here.

[illumin8]

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:Nothing to see here.

[quitte]

Or we could infer that the system was used for its purpose by the attacker. He signed those packages. Redhat looked at the logs, no other packages were signed. So the passphrase is still very likely to be save.

Re:Nothing to see here.

[Chang]

Red Hat needs to offer more info before you can make a solid judgement about this.

If the attacker gained access to the actual system where signing takes place then Red Hat needs to change the key.

But from the announcement wording - they are suggesting that the attacker was able to submit packages to be signed but the actual signing server was not compromised.

They should not have been so vague about this because it is a crucial distinction to make for their customer to make a security judgement.

As a customer I'm not happy with the vague details on what was compromised. I'm sure they did it because they have concerns about describing their package signing systems in detail but they need to open the kimono and give us the detail we need to make a decision about reloading our systems.

Merely saying, "trust us - anything that came from the official channel is safe" doesn't fly. You let an attacker gain unauthorized access - you need to re-earn trust at this point by giving us some detailed info.

Re:Nothing to see here.

[JustKidding]

Yes, that is what surprised me, too. However, I'd think they would know what they are doing, and are acting in good faith, because they could have tried to keep the whole incident secret instead.

I don't see why an attacker would sign the packages one that server, instead of just taking the key and signing them elsewhere. Because of this, Red Hat now has the signatures of the tampered OpenSSH packages. If the attacker had signed them elsewhere, they wouldn't, making the packages more valuable.

Is there a technical reason for this?

Also, I assume this means any historic packages, signed with the old key, not already in your possession at the time of the intrusion cannot be trusted. With this I mean any old versions of packages downloaded after the time the attacker got his hands on the passphrase.

Re:Nothing to see here.

[Anonymous Coward]

Coming from someone with many systems, completely exposed to the Internet, with thousand day uptimes, these RedHat folk are in fact sufficiently paranoid.

Ummm, I'm quite curious, how do you keep your system up for 3 years? Do you not update your kernel? Or is there some way to update a running kernel without rebooting that I don't know about...

Re:Nothing to see here.

[Anonymous Coward]

These are the guys who have very little competence with regards to security development. The grsecurity developers have been whistleblowing on their poor attempts for years. The linux kernel has been getting worse and worse in terms of security. The development rate is far too high for any attempt to iron out holes. There is no way you could have 1000 day uptimes and be anywhere near "secure". There is a new kernel nearly every week, and with linus' cavalier approach to security issues, one has to assume that every single release contains fixes for security issues. IMO the only real security inhancements for linux (and practically every other OS for that matter) have come from the Grsecurity and PaX projects.

Re:Nothing to see here.

[pembo13]

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:Nothing to see here.

[Anonymous Coward]

Yea I guess they don't care that a kernel compromise completely negates any security benefit from SELinux.

Re:Nothing to see here.

[illumin8]

Or we could infer that the system was used for its purpose by the attacker. He signed those packages. Redhat looked at the logs, no other packages were signed. So the passphrase is still very likely to be save.

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.

Re:Nothing to see here.

[calmond]

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...

Re:Nothing to see here.

[Anonymous Coward]

There were some cool methods by which to update a running kernel by loading a module and having it hijack the old kernel and switch to the new. I never tried this. Never cared enough.

I only have two exposed services. Basic web functions and open ssh. I've updated Apache and OpenSSH twice in the last 1014 days as new security announcements, Nessus and other security tools suggested. None of the kernel security issues between 2.6.9-1.667 and now has seemed worth the effort. I may have missed an issue, but so too have all the script kiddies who waste their time lengthening my Logwatch e-mails to no avail.

Re:Nothing to see here.

[uslinux.net]

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.

Re:Nothing to see here.

[armanox]

That would be enforcing mode, which can be quite troublesome, but is useful for the paranoid..

Re:Nothing to see here.

[Anonymous Coward]

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.

Re:Nothing to see here.

[illumin8]

Also, I assume this means any historic packages, signed with the old key, not already in your possession at the time of the intrusion cannot be trusted. With this I mean any old versions of packages downloaded after the time the attacker got his hands on the passphrase.

Good point. If the attacker still has the private key and passphrase, he can trivially repackage any older RPMs and sign them again.

Re:Nothing to see here.

[Anonymous Coward]

I suppose it's a matter of what you want to be secure against.

My servers are not a place where a sane person would store classified documents. I wouldn't even put sensitive documents there. But if you're looking for the "Golden Lock" it doesn't exist. Good security is about keeping the important stuff out of the hands of the bad people, not about making the perfectly invulnerable server. This is why firewalls and DMZs and SELinux are good things. And in fact, for our needs: Good enough.

I do not in any way want to dismiss the pursuit of perfection, any more than a physicist would dismiss the value of mathematics. Sometimes a risk, painstakingly calculated to 10 decimal places of accuracy is still, "Small enough."

Re:Nothing to see here.

[Anonymous Coward]

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

Re:Nothing to see here.

[Timothy Brownawell]

How well does that work if you can trick someone into loading the wrong package onto that USB key?

Re:Nothing to see here.

[Anonymous Coward]

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.

Re:Nothing to see here.

[EvilRyry]

The targeted POLICY is the weaker of the two most common policy. The other is strict which is a bit too harsh for most.

SELinux also has modes. The only one worth using in production is enforcing which actually enforces the rules. There's also permissive which logs when rules are violated but lets them happen anyway; this is good for development but obviously won't save you from a real attack.

Re:Nothing to see here.

[moderatorrater]

You're missing the most interesting possibility in my mind: employee sabotage. Why should open source be immune to a bad apple attempting to subvert the system for their own gain? A mid-level employee signs a package and distributes it, a customer running a rootkit checker or clamav on their system notices that the copy they have is suspicious, reports it, and suddenly you have a situation where the key itself may or may not be compromised and some checking needs to be done everywhere.

Re:Nothing to see here.

[Trahald]

This is why they don't need new keys: http://www.awe.com/mark/blog/200701300906.html (keys are secure in a hardware device)

Re:Nothing to see here.

[Trahald]

I need to refresh more often, and read faster.

Re:Nothing to see here.

[Anonymous Coward]

Did Ballmer visit Red Hat recently? Maybe they should look for chair damage.

Re:Nothing to see here.

[SETIGuy]

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."

Re:Nothing to see here.

[SETIGuy]

A mid-level employee signs a package and distributes it

What is a midlevel employee doing with the keys to the locked cage where the signing machine is kept? The signing machine should only be physically accessible to two people: the CEO and the one employee authorized to sign packages.

There's a reason you use cages for this purpose. It's so you don't even have to open the lock if there's a fire INSIDE the cage.

Re:Nothing to see here.

[Limburgher]

It's Targeted vs. Strict policies. The modes are Disabled, Permissive and Enforcing. Current default is Enforcing Targeted.

Re:Nothing to see here.

[harlows_monkeys]

Coming from someone with many systems, completely exposed to the Internet, with thousand day uptimes, these RedHat folk are in fact sufficiently paranoid

Anyone with a system that is exposed to the internet, with a thousand day uptime, is NOT sufficiently paranoid. A thousand days is far longer than the interval between kernel patchs for remotely exploitable kernel bugs.

Re:Nothing to see here.

[darkpixel2k]

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.

Meh!
Well my code signing machine is more secure. We don't put USB sticks directly into the signing machine. We copy the package to a USB stick and then to the 'transfer' machine. The code signing machine is then 'connected' to the transfer machine by infared link which is unblocked by lifting a large steel slab out of the way. The transfer happens via zmodem, and it scanned on both the transfer machine and the code signing machine. Finally we sign the package and transfer it back just before the poor intern's strength gives out and the steel slab slams back down, killing the connection and the intern...(just in case he saw me type in the 42-character passphrase to the private key).

Beat that security...

Re:Nothing to see here.

[smoker2]

The other mode, whose title I've forgotten, checks everything.

? strict ?

Re:Nothing to see here.

[Hucko]

I don't network any of my computers.

Re:Nothing to see here.

[James Cape]

From the Cox article:

At the same time we also introduced an extra layer of abstraction to the signing software, so we can authorize signers using their existing internal kerberos credentials.

So then you're able to go get a ticket authorizing you to access the "signing software" and sign a package. Possibly using LDAP attributes to control what tickets you are authorized to have granted?

Possibly a poorly secured LDAP system (or frontend)?

Re:Nothing to see here.

[Anonymous Coward]

There are going to be potential holes in ANY system. But leaving the signing server online where it can get nailed is silly if you are running something of any real importance.

Re:Nothing to see here.

[amorsen]

Targeted is a form of enforcing. The opposite of targeted is strict, the opposite of enforcing is permissive. Any combination is possible, including strict permissive (which won't actually do anything except write a lot to your logs).

Re:Nothing to see here.

[drinkypoo]

These are the guys, to the annoyance of nearly everyone, who turned on SELinux on Fedora Core by default.

Nearly everyone except their customers.

Which is to say, the Red Hat Enterprise Linux development team.

If you don't want to serve as an alpha tester for RHEL, don't run Fedora.

Re:Nothing to see here.

[Anonymous Coward]

Are these the guys who wrecked the buffet at the Harrow Club this morning?

Re:Nothing to see here.

[Anonymous Coward]

smart ass cat...being an admin means you can never ever be paranoid enough.

Re:Nothing to see here.

[Ignacio]

Don't feed the trolls - when an AC says something stupid, let it slide.

How about when someone logged in says something stupid?

Do they run linux?

[mulvane]

They should have ran a secure OS like vista.

Re:Do they run linux?

[GXTi]

Don't worry, whatever this "linux" thing is, it can't possibly run without an Operating System to support it, e.g. Microsoft Windows®. All applications require an Operating System to run, including "linux".

Re:Do they run linux?

[obergfellja]

That's not Red Hat Server... It is Vista in Disguise!

Re:Do they run linux?

[Anonymous Coward]

Your both wrong. Linux in general has a much better security record and problems tend to be fixed much quicker aswell (plus microsoft have a history of just denying blatant security holes).

Also linux *IS* an operating system. It does not in any way rely on windows and most certainly does not run *ON* windows. It is completely seperate to windows and will run on computers even if they have never had windows on them.

Re:Do they run linux?

[initdeep]

***Whoosh***

Re:Do they run linux?

[adam.dorsey]

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

Re:Do they run linux?

[Anonymous Coward]

*please* tell me you're not being serious.

Re:Do they run linux?

[Anonymous Coward]

Are you saying that this linux can run on a computer without windows underneath it, at all ? As in, without a boot disk, without any drivers, and without any services ?

That sounds preposterous to me.

If it were true (and I doubt it), then companies would be selling computers without a windows. This clearly is not happening, so there must be some error in your calculations. I hope you realise that windows is more than just Office ? Its a whole system that runs the computer from start to finish, and that is a very difficult thing to acheive. A lot of people dont realise this.

Microsoft just spent $9 billion and many years to create Vista, so it does not sound reasonable that some new alternative could just snap into existence overnight like that. It would take billions of dollars and a massive effort to achieve. IBM tried, and spent a huge amount of money developing OS/2 but could never keep up with Windows. Apple tried to create their own system for years, but finally gave up recently and moved to Intel and Microsoft.

Its just not possible that a freeware like the Linux could be extended to the point where it runs the entire computer fron start to finish, without using some of the more critical parts of windows. Not possible.

I think you need to re-examine your assumptions.

Re:Do they run linux?

[Anonymous Coward]

Thanks Mr. Data.

Re:Do they run linux?

[Anonymous Coward]

I second that woosh, welcome to /. though anon

Re:Do they run linux?

[WeeLad]

To be fair, sometimes jokes go so far overhead that the whoosh would be imperceptible

Re:Do they run linux?

[bigredradio]

That's no moon it's a ....ah nevermind...

Re:Do they run linux?

[ins0m]

Yeah, but this is as bad as striking out at a tee-ball game.

Re:Do they run linux?

[Anonymous Coward]

Hey look! Someone's CIO is reading the Slashdot!

Re:Do they run linux?

[witherstaff]

Be careful, bad jokes can get you punched. Although this is /. so I'd assume bad jokes probably would get you hacked, Denial of serviced, spammed, or fragged before we'd bother to haul our butts out of a basement and physically exert ourselves.

Re:Do they run linux?

[init100]

Look up Jerry Lee Cooper, especially on ZDNet Talkback.

Goes to show

[BadAnalogyGuy]

Given enough time and energy, even Linux servers can be hacked.

With the growing interest in Linux, I wonder if we'll see more parity of viruses between Windows and Linux.

Re:Goes to show

[dword]

Not unless Linux gains 50+% of the end-user market share.

Re:Goes to show

[jessedorland]

As a Linux user I would like to think this is not going to be easy. Giving the nature of Linux. Installing a software require root account, and as far as I know no Linux user will be surfing the internet with full admin. Building viruses for Unix base operating system including OS X is not very easy, yes it can be done but it will not have Windows' like affect.

Re:Goes to show

[illumin8]

Given enough time and energy, even Linux servers can be hacked.

With the growing interest in Linux, I wonder if we'll see more parity of viruses between Windows and Linux.

It also goes to show that the human side is usually where compromises come in to play. Most likely some admin had a weak password that was hacked, and that admin had permission to signing packages or things he should not have had.

I don't care how secure your OS is. If you don't follow proper security procedures, including using strong passwords and giving users only the permissions they need to do their job, you will be hacked.

Re:Goes to show

[TorKlingberg]

The virus can install itself in the user home directory instead.

Re:Goes to show

[__aamnbm3774]

and dont forget OS X.

as 'stable' and 'secure' as that is marketed, all it takes is a few dollar signs and someone will find an exploit somewhere.

Re:Goes to show

[Goaway]

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:Goes to show

[JeffSchwab]

I wonder what % Linux already has, if we count embedded systems and devices that aren't ordinarily considered "computers." Cars, ATMs, portable media players, DVRs, household appliances...

MIT students hacking the T notwithstanding, it seems virus authors are still mainly interested in desktop systems. Maybe because financial data are more likely stored on desktops than on portable devices? Are there PDA viruses?

Re:Goes to show

[bconway]

Like change system files? Nope. How about bind to privileged ports? Nope. So... it can mess up my documents? Darn.

Re:Goes to show

[jambox]

A keylogger wouldn't need root access. All it has to do is monitor the keyboard and send out packets. I'm sure there are more examples.

Re:Goes to show

[Goaway]

The point is, there's no need to change system files or bind to privileged ports.

Your documents contains LOTS of yummy personal information for people to steal. Identity thieves and credit card thieves will love all that stuff.

Spammers need relays to send their spam through. You can run a relay just fine as a normal user. Same thing with the DDoS bot for exortotionists and script kiddies.

You can mess with the internals of Firefox without root access too, through plugins. Easy to put a password stealer in there. Or you could mess with your desktop settings so that when you try to launch a browser, you get a compromised version instead.

I'd say I've covered all the major reasons somebody would want to infect your machine here, and not a single system file or privileged port was needed for it.

Re:Goes to show

[__aamnbm3774]

No, you are wrong, and this is the mindset that scares me in the computing world.

If a custom box running JoeOS contains something extremely financially valuable, you can bet people will start trying to hack it.

Security through Obscurity is not only wrong, but terrifying that people buy into the concept.

Re:Goes to show

[Shados]

Thats correct. And as much as there are many issues with Windows security that -could- be exploited, usually, even there, the human side is easier to exploit... So those "skills" are portable... Will be interesting to see how the ecosystem reacts when it starts happening more and more... technological fixes won't do...

Re:Goes to show

[Alwin Henseler]

Given enough time and energy, practically any network-connected system can be hacked. That is because security is *hard*, and there are few people who have the means to create chains that contain only strong links, and put those strong chains in the hands of a big audience.

But given workable tools, I think security comes down more to procedures, and a competent sysadmin than anything else. I'd put more faith in a well-managed Windows server than a Linux server with an idiot as admin. With all factors equal, I'd put more faith in a Unix-like system than anything coming from Redmond. For starters, because Unix systems (and clones) were built from the ground up as networked, multi-user systems.

Re:Goes to show

[frodo from middle ea]

Like tryout various local exploits to gain root access...

Re:Goes to show

[betterunixthanunix]

I wouldn't even assume it was an admin. My guess is that a HR person of some sort had a weak password, and that from there the attacker was able to sneak into Red Hat's internal network. Within that network, the attacker would have had a much easier time getting into higher security systems, and eventually start getting those packages signed. Whoever it was probably spent several weeks working on this, especially given the sophistication of the attack (targeting the signing server to apparently compromise Red Hat's customers).

Re:Goes to show

[Anonymous Coward]

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:Goes to show

[coryking]

The virus can install itself in the user home directory instead.

And then use one of the many local exploits to get root.

The most scary and amusing thing is how quick some people on this site and others are to dismiss local exploits. They all think "you have to be on the console, so fuck it, this isn't important and doesn't affect me". They are wrong. These days, a remote exploit is just a human operator and a local exploit.

Re:Goes to show

[Clairvoyant]

I'd much rather think this data is stored on servers that are more secure than the average desktop (how was the market share of Linux/Windows on Desktop/Servers again?)

Re:Goes to show

[Anonymous Coward]

Users though will gladly give away their bank account information to anybody just asking for it. People have been proven to click on a link saying "Get Infected Here!"

most of your current Linux crop are techies who don't run admin on Windows either (I don't run admin nor do I allow my users to run as admin, my home PC is vista and it does not run as admin either).

People still send out spam because people will click on it.

Re:Goes to show

[vadim_t]

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.

Re:Goes to show

[Anonymous Coward]

Hypothetical situation:
User: Oh my god I have been infected by a Linux virus!
Me: do you have backups of your documents and important files?
User: yes but it is messing with my programs...
Me: rm -R /home/$user && mkdir /home/$user
Me: Login and restore your backups sir, the threat has been eliminated.
(not even going on with "here use this shell script it'll remove the virus automagically")

Now compare this to MS Windows: Your system has been infected. Internet explorer can no longer view sites(curious virus/bot/worm, but I saw it more than once), you cannot search for help online, the virus exists system-wide, the USER can affect the administrator.

I know which I prefer, do you?

Re:Goes to show

[ebuck]

Before you go harping about parity of viruses between Linux and Windows. Show me evidence of parity of viruses between Macintosh and Windows.

Nobody has proven their case that any operating system can achieve virus parity with windows. Everything I've learned about operating system design implies that Windows might be secured, but has a design that makes it much, much, much harder to achieve.

While it is true that more viruses could exist for Linux, asserting that with Linux acceptance comes virus parity with windows is FUD. I mean Windows beats Linux by three orders of magnitude. Windows beats Macintosh by three orders of magnitude. It beats commercial Unix by five orders of magnitude.

Sure my data is a little old, but here's the source: http://www.theregister.co.uk/2003/10/06/linux_vs_windows_viruses/

You'd better provide some exceptional evidence for making the exceptional claim that Linux virus proliferation is going to grow 50000%. More recent data will be appreciated.

Re:Goes to show

[gnuman99]

The point is, they want root access or effective root access to install root kits so their network sockets and processes are hidden from the user.

With user account their virus is visible. Their network traffic is visible.

Re:Goes to show

[Goaway]

So cleanup is easier. But the damage may already be done, as criminals may now have your passwords, your credit card numbers, and your personal information. Plus you were probably sending spam up until the moment you noticed the infection.

Re:Goes to show

[Goaway]

PS: It's pretty disingenuous to make a point of that the Windows virus doesn't let you "search for help online", when your Linux scenario was all about asking help from a friend in the first place.

The Windows cleanup is a merely a little longer, as it requires an OS re-install and backup restore (also, that is what most people would do on Linux anyway). The vast majority of systems out there are single-user, you know.

Re:Goes to show

[Karellen]

"Spammers need relays to send their spam through. You can run a relay just fine as a normal user"

Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.

"You can mess with the internals of Firefox without root access too, through plugins. Easy to put a password stealer in there."

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.

"Or you could mess with your desktop settings so that when you try to launch a browser, you get a compromised version instead."

Again, only works for one user.

Of course, the "only works for one user" argument is better if presented in reverse. If your less-computer-literate kid/spouse/parent can't accidentally run code that sets up a visible relay, or installs a system-wide password sniffer, or messes with your desktop, then your desktop/browsing experience will not be fucked with no matter what they accidentally do.

Furthermore, you'll be in a position to be able to clean their account up for them without having to wipe and reinstall the whole machine (including all your precious stuff) which you would have to do if system files had been cracked.

Re:Goes to show

[Anonymous Coward]

Uh, neither? Anyone that has gained access to your machine may have used some kernel or other exploit and gained privileges. Maybe they just dictionary attacked the root password.

Blowing away and recreating a user's directory won't do squat if you have already been rooted. If anything, it destroys forensic evidence of what might have been done to get privs, if root privs were indeed achieved.

Even in Linux, the user can affect the administrator.

The best defense is keeping unauthorized people off of a machine in the first place and then watching logs and files like a hawk for any evidence of intrusion. Once someone has made it inside, you have a lot of work to do to make sure your system has not been compromised.

Re:Goes to show

[AdamWill]

"Me: do you have backups of your documents and important files?
User: yes"

Ahahahaha! Hahahahahaha! Hahahahahahahahahahah!

*rolls in aisles*
*holds sides*
*wipes tears of laughter from eyes*

Re:Goes to show

[Anonymous Coward]

Afaik Xorg runs as root, so you can't do a keylogger so easily without root privileges.

Re:Goes to show

[sm62704]

No, Windows' popularity is only a small part of the reason it is the only OS with viruses in the wild. The biggest reason is that it uses the discredited "security through obscurity", but it, too isn't the only reason Windows is insecure.

Mac and Linux are based on UNIX, which was developed for mainframes; mainframes have always needed security. Windows was developed before the wide popularity of the internet for stand alone computers. Stuff like Active-X is fine on a computer until you network it.

There are millions of Macs sold every quarter. If you could write a Mac virus you could have a huge botnet, but so far there has been no evidence that anyone has been able to.

Re:Goes to show

[drsmithy]

Like change system files? Nope. How about bind to privileged ports? Nope.

It can send spam, participate in DDoS attacks, act as a repository for kiddy porn, or just wait to take advantage of the next 0-day local privilege exploit.

In short, lack of root-level access is a minor annoyance to malware, not a critical problem.

So... it can mess up my documents? Darn.

Yes. It can mess what are most likely the most important and least-replaceable data on your machine. This doesn't bother you ?

Re:Goes to show

[Kjella]

Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.

Unless you happen to run one of the desktop distros which usually have a default policy of ACCEPT.

Of course, the "only works for one user" argument is better if presented in reverse. If your less-computer-literate kid/spouse/parent can't accidentally run code that (...)

Read all my documents through the world-readable home folders? Another convienience feature.

My experience is that people don't keep the accounts truly separate, that's just for convienience. "Hey, can I just check my webmail for a sec?" "Sure" and your email's compromised.

Furthermore, you'll be in a position to be able to clean their account up for them without having to wipe and reinstall the whole machine

in theory. In practise, I expect the malware authors to find so many ways of hiding (or just when you "rescue" his documents) that it won't practicly happen. Least not without someone more experienced than the average guy.

Re:Goes to show

[grayn0de]

Linux has been getting hacked since it started. Literally, considering it was a hacker who made the kernel. Just like M$ whatever, *nix, Novell, Apple OS X... they've all been hacked before and will be hacked again.

There is always someone willing and knowledgeable enough to own your box. Especially if the attacker can compromise a critical system, say one that is integrated into the distribution process of an entire operating system.

I would like to see the number of compromised Fedora/Red Hat downloads there have been before remediation, though.

Re:Goes to show

[drsmithy]

Everything I've learned about operating system design implies that Windows might be secured, but has a design that makes it much, much, much harder to achieve.

Please elaborate.

Re:Goes to show

[_Sprocket_]

With the growing interest in Linux, I wonder if we'll see more parity of viruses between Windows and Linux.

This should sound familiar to most readers here. We've heard it before:

http://www.simson.net/clips/2000/2000.SecurityFocus.Linux_Viruses.html

http://web.archive.org/web/20000304004534/http://www.zdnet.co.uk/news/2000/3/ns-12862.html

http://www.vnunet.com/vnunet/news/2120227/honeymoon-linux-users

And the same general theme has even been fitted for the MacOS crowd:

http://www.linuxinsider.com/story/mac%C2%AD-security/57811.html

It's not that the concept is all that unlikely. Oddly enough, WinNT set a historical precedence for adoption and exploitation. Yet Linux / Unix has yet to pan out the same way.

What we've got to keep in mind is that Linux (and Unix variants) have been in this arena for some time. They have had exposure and faced scrutiny. In fact, the hay-day so far for Unix and Linux malware was probably around 2002 - 2004.

Whether that is the last chapter for Linux malware is yet to be seen. I would expect it isn't. Linux users must remember that it is no silver bullet. But history has shown that it appears to be fairly resilient.

Re:Goes to show

[grayn0de]

There are millions of Macs sold every quarter. If you could write a Mac virus you could have a huge botnet, but so far there has been no evidence that anyone has been able to.

I agree... especially considering the amount of Mac users who believe that OS X is immune to viruses and malware. We've all seen/heard it before... The infamous ignorance of the vast majority of Mac fanbois: "Problems with viruses? Get a Mac! The can't get viruses!"

I use a Mac daily and, though I have only seen (caught) 2 trojans, I have caught plenty of Mac/Unix targeted malware. It's only a matter of time...

Re:Goes to show

[Goaway]

Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.

The program can just make the initial connection to the spammer server itself. This is the same on Windows and Linux, and these programs operate just fine under Windows.

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.

How many computers do you honestly think there are out there that have more than a single user?

Re:Goes to show

[GreatBunzinni]

Thankfully we have the noexec mounting option available.

Re:Goes to show

[fatboy]

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

[Anonymous Coward]

You mean just like in vista(or NT in general)?

Re:Goes to show

[FooBarWidget]

What do you mean, "even Linux server"? How about "even every single computer in the world"?

Whoemever told you that Linux, Windows, OS X, OpenBSD or whatever is 100% invulnerable to authorized accesses is either ignorant or lying. Nothing is perfect, and there is no reason why Linux advocates should deny that fact. Saying "haha, look, Linux IS insecure after all!!!!1111" is not any more useful than "haha, look, you're a human being and you made a mistake after all!".

As for viruses, this compromise has got nothing to do with viruses. Your statement is still blank and meaningless.

Re:Goes to show

[moderatorrater]

Given that Linux has a lot of market share in the server department, I would imagine that the reward for compromising a system would be greater for linux right now than windows. After all, would you rather hack into 1000 home desktops or get a server from EBay, Slashdot, or any major to medium site that gets credit card numbers at some point?

However, since infecting a server is lower profile than infecting 1000 home computers, people looking for notoriety won't be doing it. I imagine that if someone finds a linux server exploit, they will exploit it as widely as possible without letting anyone know. Until very recently, hacking windows was something you did because you could, and letting people know they had a virus wasn't an issue. With linux, I imagine it's a different game entirely, and the tipping point is already there.

Re:Goes to show

[qwertphobia]

You'll sooner see phone viruses, methinks.

The advantage (for the virus distributers) is that Windows and OSX and iPhones have is that they share a common denominator of services and applications. It is much easier to target a system if you know what services are available.

For the most part Linux systems are custom builds with a variety of applications and services (and versions of) enabled. Someone could target a specific distribution or sets of distributions, and this has happened several times (slapper, for example) but such an attempt cannot target linux systems in general.

For those who need to spread their realm of conotrol, targeting individual Linux installations will be much more successful than attempting to spread a virus.

Re:Goes to show

[sm62704]

Your documents contains LOTS of yummy personal information for people to steal

No they don't. I'm paranoid and don't keep that kind of documents on the computer.

Re:Goes to show

[Maznio]

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

Re:Goes to show

[gzipped_tar]

> 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.

This is the whole point of SELinux. Not saying SELinux is uncrackable, but it is designed to counter such attacks. Although properly setting up a fully protected SELinux environment may be tedious and frustrating, it does work.

Fedora has been working on deploying SELinux on desktop machines and there seems to be a whole lot of work remaining to be done so far. Well, Do they have SELinux disabled on their servers?

Re:Goes to show

[tepples]

How many computers do you honestly think there are out there that have more than a single user?

Mom, dad, two kids, that makes four users.

Re:Goes to show

[jedidiah]

The Atari ST had plenty of viruses without 50% of the end-user marketshare.

The notion that "obscurity" protects Linux is beyond preposterous.

Re:Goes to show

[Anonymous Coward]

xev much?

Re:Goes to show

[DA-MAN]

Synergy, a keyboard sharing app, must run as the user. I use this to use one keyboard between an Windows laptop and Linux desktop at work. As the keyboard is only hooked up to my Linux box, and synergy runs as me I must assume that user level access is all that is needed for a keylogger.

Re:Goes to show

[jedidiah]

Windows?

A shell and applications that like to blur the boundary between
programs and data, automatically execute programs from unknown
sources and automatically install programs from unknown sources.

Microsoft goes out of it's way to be stupid.

Re:Goes to show

[jedidiah]

If you want a Unix box broken into you have to "concentrate on it" and "work at it".

This is the part that's not required for Windows.

Dumb engineering practices aggravated by an anti-intellectual user culture of willful ignorance.

Re:Goes to show

[jmorris42]

> Mounting /home with noexec

Which is just great if all of your users are Windows/Mac users who click on the pretty icons and wipe the drool from their chins every couple of minutes. If you have any UNIX folk using the system they will hoist yer ass on a rope minutes after you kill all those scripts and such in their ~/bin directory. And some of us have a ~/src or an ~/rpmbuild tree in our $HOME as well.

I guess if are to ever achieve "World Domination" we need to accept most users will probably be "displaced Windows users" who will keep their same end user habits because the Unix Way isn't for the masses. But jeeze, barring them from ever trying to write/download so much as a bash script is one way to make that a self fulfilling prophesy.

Re:Goes to show

[Karellen]

'Unless you happen to run one of the desktop distros which usually have a default policy of ACCEPT.'

So, as the administrator, make the default policy "DENY".

'Read all my documents through the world-readable home folders? Another convienience feature.'

If you're that worried about your spouse/parents/kids installing malware which can do that, make your home folders non-world-readable. Or even just your sensitive documents folder non-world-readable, if you want to share e.g. your music folder with the people you share the computer with.

'My experience is that people don't keep the accounts truly separate, that's just for convienience. "Hey, can I just check my webmail for a sec?" "Sure" and your email's compromised.'

So keep them truly separate. That's what fast user switching is for. I'm pretty sure even XP has this, and it's only 2 mouse clicks away. [Start] [Switch user].

It's *easier* if you do it that way, because when you log into your PC account, your web browser will remember *your* cookie/login form details for your webmail. If everyone in the house uses, e.g. gmail, this is a bonus.

'Least not without someone more experienced than the average guy.'

OK, setting the default firewall rule of "DENY" is probably not for the average guy. The rest are pretty easy to accomplish with point-and-click UI.

Re:Goes to show

[Anonymous Coward]

The malicious program doesn't have to bind to a privileged port to open up access to the machine, nor does it need to bind to a port at all.

If the malicious programmer set up a 'server' component to the hack, then it would be as simple as establishing a connection from the compromised machine to an open port on the SERVER, completely circumventing the need of the program to open any port whatsoever to continue with it's malicious intention.

Re:Goes to show

[Wee]

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

Re:Goes to show

[Goaway]

Most families these days would have more than one computer.

And even so, it hardly matters. One infection is one infection. The fact that one infection is not automatically several infections is hardly very praiseworthy.

Re:Goes to show

[Goaway]

Can it prevent an application the user installs themselves from doing what I described? Because a whole lot of zombie infections are caused by users installing the malicious software themselves.

Re:Goes to show

[mlts]

I really can't tag the blame all on Microsoft. There is one lurking variable that few people realize:

The developer community attitudes.

Mac developers are loyal to the platform, they don't like it when Apple changes APIs or does a fundamental change such as a new CPU architecture, but they deal with it.

Linux developers are similar. If its for the good of the OS, they will adapt to changes. The a.out to elf executable format change in ages past is a good example.

Windows, its a totally different attitude. Loyalty isn't really a factor in a lot of cases, although there are a number of people who are loyal to the platform. A lot of dev houses are only on Windows because it pays the bills. This is why some Windows devs are hostile to any changes, even ones which are fundamentally increasing platform security. Look how long it took for a lot of Windows apps to just work as a user and not require admin privs. This isn't really MS's fault, its mainly because Windows is the most popular platform out there.

This attitude also reflects into malware writing. Because there are a lot of people who are not really caring about the platform, they don't have hesitations about writing malicious code.

Re:Goes to show

[nxtw]

However, since infecting a server is lower profile than infecting 1000 home computers, people looking for notoriety won't be doing it. I imagine that if someone finds a linux server exploit, they will exploit it as widely as possible without letting anyone know. Until very recently, hacking windows was something you did because you could, and letting people know they had a virus wasn't an issue. With linux, I imagine it's a different game entirely, and the tipping point is already there.

You speak as if this doesn't already happen. I remember fixing a server that was set up with Red Hat 9, about six months after the release (2003). No updates were installed. It got rooted after a few days, using an exploit that was known; patched binaries were available from Red Hat. I think it was discovered because it was scanning other hosts.

If you've got a vulnerable server in an IP range known to host servers, it might get exploited... If you've got a vulnerable system in a residental IP range, it might be infected by an automated scanner... but will anyone be manually scanning residential IP ranges for vulnerable Linux machines anytime soon? Unlikely.

Re:Goes to show

[SEMW]

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.

How's this:

#!/usr/bin/python
import sys, os, stat

if os.geteuid() == 0:
__if os.path.exists(sys.argv[1]):
____os.chmod(sys.argv[1], os.stat(sys.argv[1])[stat.ST_MODE] | stat.S_IXUSR)
____os.spawnv(os.P_WAIT, sys.argv[1], sys.argv[1:])
____os.chmod(sys.argv[1], os.stat(sys.argv[1])[stat.ST_MODE] & ~stat.S_IXUSR)
__else: print "File not found"
else: print "Insufficient privileges"

Re:Goes to show

[mvdwege]

Unix was never designed for security. In fact, the most common objection against Unix in its early days, from users coming from systems like VMS and TOPS-20, was in fact that Unix was horribly insecure.

What makes a difference is that after twenty years of security breaches, a culture has grown in the Unix world that depends on using Best Practices to mitigate the inherent design problems in Unix that make for bad security. Hence, for example, why a modern *nix box shows many different users in the output of ps. Microsoft, with its NIH mentality, refused to draw the lessons that many generations of computer operators had drawn, and decided to trust on the superior security design of the NT kernel. However, they managed to foster a culture that did away with all Best Practices, hence the common spectacle of requiring Administrator access for everything (and then patching it badly with UAC), and running services under the SYSTEM account.

Which only goes to show that design is not everything. You can design a system as secure as you like, as long as you ignore the security features, it will be less secure.

Mart

Re:Goes to show

[blhack]

I think the parent is talking more about general viruses that are just sent out into the tubes with the intent of auto-rooting insecure boxen.

What you're saying is true "Any system with something desirable on it is at risk of getting wHacked", but one system with important information on it is not going to spawn a breed of viri meant to just root ALL of the boxes with that OS.

Re:Goes to show

[Anonymous Coward]

Whoever it was probably spent several weeks working on this, especially given the sophistication of the attack (targeting the signing server to apparently compromise Red Hat's customers).

Does he also engage in chair tossing?

Re:Goes to show

[mcrbids]

Riiighhht.

Because keeping money on the dash of your unlocked car (in plain view) is just as secure as keep it in a hidden safe in your cellar. Any moron can tell that there's a world of difference between these two scenarios, why do so many people fall for this marketshare myth?

Your argument about marketshare ignores the fact that there are real differences in security policy between the two systems, and that these differences do result in differing security footprints. Just like the cash on the dash vs. the hidden safe, there will be differences in security.

Re:Goes to show

[Sentry21]

Put another way, a local exploit is only local until you connect to the internet.

Re:Goes to show

[vadim_t]

Eh? What's that good for?

Let's see if I understand, if the script is executed by root, change file's permissions to add permission to execute by the file's owner, execute, then remove.

First, this doesn't solve the problem. The problem is that you have /home/vadim/app.sh, which is owned by vadim, marked executable, but denied execution by grsec/SELinux/mount options. Doing chmod on it won't make any difference.

Second, root can do anything it wants anyway (excepting SELinux limits), and this tool needs to work for a normal user.

Third, if this is supposed to run as suid, it allows any user to mess with the permissions of any file on the system, and contains a race. And it would run applications as root then.

The application I have in mind would probably need to be suid, ask for the user's password, tell the kernel to temporarily disable the execution limit, set the UID to the calling user, then execute the application.

Re:Goes to show

[pyrr]

Sending spam is money. Enlarging the spam mailing list is money. Building a botnet is money. Spending hours to extract data to perpetrate one identity theft that carries a greater risk of prosecution and may not be overly successful would be like stopping for a couple of seconds to pick a penny up off the sidewalk, when you make well in excess of $36.00/hour (i.e., more than a penny a second) and would make more just going to work and clocking-in. Your computer is worth more to the scum of the net as a tool (botnet node and/or spam relay) and the only information they're likely to want is your address book, MAYBE a gaming account if it's a popular MMORPG that they can turn a quick profit on by looting and then vanish with minimal exposure.

There was an article linked by /. a few months ago rating the relative value of your computer to a cracker. They consider Linux/UNIX machines that have been rooted to be the most valuable since they're more likely to be always-on and connected to a commercial-duty connection. They use those for command and control, further infections, and so on. They're probably not going to refuse any new genuine (as opposed to honeypot) botnet nodes, but they're not as valuable. And a non-Windows machine, if a userspace account is compromised, but root isn't, is all but useless for all those things.

Re:Goes to show

[Sentry21]

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.

Re:Goes to show

[init100]

It certainly can, but you might not want to. One could define an SELinux type for normal users, having all their files labeled with that type, and then only letting that type do very few things. But that would also prevent all nice applications that you install yourself from doing those forbidden things.

Re:Goes to show

[Karellen]

"Given that most computers running Firefox these days are single-user systems"

I'm sorry, but that's not a given. Do you have any study, article, poll or other even tenuous/unscientific bit of actual data to back that assertion, or are you just making shit up?

Most people I know use computers that are used by workmates, partners and/or kids. And they use different accounts for each. Yes, I know that's an anecdote and not statistically valid, but then neither is your contention.

Re:Goes to show

[JohnBailey]

Not unless Linux gains 50+% of the end-user market share.

Provided it's the 50%+ from the stupid end...

Re:Goes to show

[JohnBailey]

How many computers do you honestly think there are out there that have more than a single user?

Well.. On mine. Root, my personal account and a low privilege guest account for someone who drops by and needs to get on the net for a minute.

Re:Goes to show

[Anonymous Coward]

"Most families these days would have more than one computer."

Let me guess, you're middle-class and white, aren't you?

The rest of the world is a little less ignorant about people outside their social comfort zone.

Re:Goes to show

[Anonymous Coward]

Doesn't matter. Virus writers don't write viruses for stupid people. They write viruses that are undetected by Antivirus software and either cause harm to the victims or does something good for the author of the virus (or both). This has absolutely nothing to do with the stupidity of the user.

Re:Goes to show

[Maelwryth]

Why exactly has the parent been modded a troll?
He/she has summarized the effect a virus in a local account could have, pointing out that what is really important to us is in the files we have permission to read/write.

Re:Goes to show

[Goaway]

And do you see how irrelevant that is to the discussion at hand?

Re:Goes to show

[Goaway]

Actually, what I was doing was assuming that most people who have at least one computer are pretty "middle-class and white".

The times are changing, though, and I may just be a little behind on that.

Re:Goes to show

[JohnBailey]

And do you see how irrelevant that is to the discussion at hand?

Nope.. Perhaps you can explain.

Re:Goes to show

[Goaway]

Because a virus can infect your normal account, and it doesn't matter one bit that it can't spread to the rarely-used guest account.

Re:Goes to show

[Edgester]

That's pointless. You will annoy the programming students and researchers who compile code while not preventing the determined people. To get around this, just run the linux loader as the command with the /home/user/executable name as the second parameter. Try it yourself like this: "cp /bin/ls ~/bin/foo; chmod -x ~/bin/foo; /lib64/ld-linux-x86-64.so.2 ~/bin/foo" (Tested on centos 5 x86_64... adjust for 32bit platforms as needed)

Re:Goes to show

[amorsen]

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).

Re:Goes to show

[drinkypoo]

"Spammers need relays to send their spam through. You can run a relay just fine as a normal user"

Not if you don't have access to the firewall settings which will open the port that allows someone to connect to your relay.

You think you're smart, but all the botnet client has to do is open a VPN connection of some sort back to the controller to bypass your firewall entirely (barring egress policies, of course - most of which can be bypassed by connecting to port 80.)

The only works for one user argument is wrong for two reasons. First, most of the time, there is only one user. Second, as others have pointed out, there have been numerous local root escalation exploits. This is why we should all be running selinux. Yes, I realize it is nontrivial. I am not doing it myself, because it is not easy. Someday...

Re:Goes to show

[Karellen]

"all the botnet client has to do is open a VPN connection"

Is that all? Wow, if only setting up tun/tap virtual network devices for VPNs required root access. Oh, wait a minute, it does.

Of course, it's actually simpler than that. All the botnet client has to do is open a TCP connection to a server (e.g. an IRC server) and accept commands from there. (e.g. Send this 10k email to these 25k email addresses.)

However, running an open mail relay, which is what the great-grandparent was talking about though, /is/ solved by the basic firewall rule of not allowing incoming network connections from anywhere. That is generally a bit restrictive though, so the default OOTB experience might ought to be to allow incoming zeroconf/filesharing connections to private address ranges (192.168.*, 10.*), and block all other incoming connections.

"First, most of the time, there is only one user."

As I asked of Sentry21 a couple of posts above, do you have any data at all to back that up? A study, news article, poll... anything but your anecdotal assertion that this is the case?

As I pointed out to Sentry21, my worthless anecdotal evidence from me and the people I know leads me to believe that most computers are used by more than one person, and that these people tend to have their own accounts on those computers.

"Second, as others have pointed out, there have been numerous local root escalation exploits."

OK, that is a problem. But as defense in depth goes, requiring an attacker to exploit a local root escalation in order to fuck over everyone else's account on the system is clearly better than the alternative of having everyone run as root, and the first bit of "dancing bunny" malware automatically own the whole system.

If we get away from the Wintel32 monoculture and end up with a nice range of mail/shell/OS/arch combinations (e.g. Thunderbird/KDE/Linux/PPC vs. Claws/Gnome/OpenBSD/x86-64) then local root escalations will be harder for attackers to take advantage of too.

And SELinux. Someday... :)

Re:Goes to show

[Anonymous Coward]

Linux can be trivially compromised, it has more holes than a Swiss cheese. If you want some hope for your servers use OpenBSD. Their developers are according to Linus "the Penguin" Torvalds a bunch of masterbating(sic) monkeys because they care about security. Go figure.

Re:Goes to show

[drinkypoo]

Is that all? Wow, if only setting up tun/tap virtual network devices for VPNs required root access. Oh, wait a minute, it does.

You can forward ports from the remote to the local with ssh, and you can use something like slirp which effectively provides you with the same thing (only moreso.) No need for a real VPN.

You can also just accept commands (RPC, whee.)

That is generally a bit restrictive though, so the default OOTB experience might ought to be to allow incoming zeroconf/filesharing connections to private address ranges (192.168.*, 10.*), and block all other incoming connections.

I hate to admit it, but Windows XP with SP2 or later is basically the winner here. I have been comparing Linux/netfilter-based firewall solutions and the conclusion I have come up with is that pretty much all of them are lame. I can go into more depth here than anyone cares about, but all you really need to know is that Windows XP's interface-centric configuration turns out to be just about the best thing for almost any home user. There are some serious failings (e.g. in the wireless networking department) but the firewalling is brilliant. You can allow traffic by rule or by application, and the system supports uPnP, both as a client and as a server (internet connection sharing, AKA NAT.)

The further problem however comes with the concept of trusting clients on the network to be who they say they are. If you are acting at the internet border then you need to disallow incoming traffic which claims to be from your internal network that is coming in on an external interface for this to be trustworthy. Dropping source routed frames only protects from attacks like this which come from a source further away from the next hop; if it is compromised (some ISPs have excellent security, while others, uh...) then you need these rules to protect you. If you don't have them, then you really should drop all incoming traffic by default.

Unfortunately, no Linux firewall even has the usability of, say, Black Ice. You know, what we had back in 1996 or 1997, something like that? The thing that comes closest is Firestarter, but it is easy to see how it falls short compared to Windows XP when you try to configure a system with more than two network interfaces. While this is an unusual situation for the home user, it is not unheard of.

Again, selinux is probably the most important and underutilized security tool we have available to us as Linux users. Some distributions are starting to make use of it; most still make it very difficult. I realize the problem is non-trivial, but it must be made a priority. Attacks against Linux will only increase, and the Unix permissions model is woefully inadequate in any case. In particular, GNOME and KDE both need to have integrated support for RBAC and for ACLs if we are going to move forward into a more secure future.

Re:Goes to show

[shentino]

What about all of us geeks that actually have to WRITE and TEST the crap that y'all are supposed to install?

Should we run GCC as root?

No...not a good idea.

Leave gcc running as a normal user. You only need root to "install", aka "make install" in most cases, and there it's usually just a simple file copy operation.

Re:Goes to show

[Wee]

Yes, it is a good idea. If you don't want to use root, set up another user for the purpose of building software.

Security and convenience. Pick the one you want.

-B

OpenSSH bug?

[samcan]

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.

Re:OpenSSH bug?

[3p1ph4ny]

In keeping with the spirit of /., I didn't read TFA.

However, I'd say this is totally unrelated to the Debian bug. The Debian bug was caused as a result of a change a Debian package maintainer made. Since he only made the change for the Debian package and didn't push it back upstream, it's highly unlikely that they are related.

Re:OpenSSH bug?

[tuffy]

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:OpenSSH bug?

[AndGodSed]

I read TFA and it seems that this is not a bug. It is rather a compromise as a result of illicit access to the servers.

Exactly HOW or WHO did this is not mentioned in TFA.

Re:OpenSSH bug?

[tuffy]

The bottom paragraph of the security advisory "details" section lists a minor bugfix, in addition to clean packages related to the breakin.

Re:OpenSSH bug?

[xsuchy]

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).

Re:OpenSSH bug?

[Anonymous Coward]

And yet, people shit frisbees over the problem with Debian, yet everyone wants to give RedHat the benefit of the doubt.

Re:OpenSSH bug?

[Anonymous Coward]

Is this bug in OpenSSH related to the one that was found in Debian-related distros back about April?

Listen, I would appreciate if you would stop calling it an 'OpenSSH bug'. OpenBSD guys had nothing to do with it. It was a GNU/Debian bug, introduced by a clueless Debian Linux developer.

Thanks.

Re:OpenSSH bug?

[Anonymous Coward]

No, it isn't. Read it again.

Re:OpenSSH bug?

[highonv8splash]

Debian's OpenSSH vulnerability was a result of commenting some stuff out of the OpenSSH sourcecode and leaving a hole in it as a result. This is completely different, this sounds like a rogue user was intentionally trying to distribute a different version of OpenSSH with a backdoor built-into it.

Re:OpenSSH bug?

[samcan]

Thanks for clarifying. I didn't read the article either.

Re:OpenSSH bug?

[Anonymous Coward]

The Debian bug was in Debian specific patching. The closest that specific code comes is that perhaps the attacker tried to deploy that code within RedHat, knowing it to be known broken.

Otherwise, this is more related to a break-in that happened a few years ago in Debian.

Re:OpenSSH bug?

[Anonymous Coward]

or maybe you should RTFA

Re:OpenSSH bug?

[Respect_my_Authority]

Is this bug in OpenSSH related to the one that was found in Debian-related distros back about April?

Debian had a security vulnerability in their openssl package (and it was found in May).

http://www.debian.org/security/2008/dsa-1571

Re:OpenSSH bug?

[HappySmileMan]

This seems to me like an honest mistake, someone somehow hacked a computer (either by guessing password, SEing someone to give it to them or exploiting something). Whereas with he Debian thing someone removed a call to seed a random number, There's no real excuse for that, no way could he have actually thought it was good to remove that line of code, either he knew what it did and changed it anyway or he didn't know what it did and therefore shouldn't have changed it

Re:OpenSSH bug?

[scott_karana]

You mean Debian's broken Random Number Generator?
No, the bug is unrelated, and has to do with X11 forwarding in SSH tunnels. It's considered low severity.
Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4752

Re:OpenSSH bug?

[Hatta]

Listen, I would appreciate if you would stop calling it an 'OpenSSH bug'. OpenBSD guys had nothing to do with it. It was a GNU/Debian bug, introduced by a clueless Debian Linux developer.

Is that you Theo?

Thanks.

Oh, guess not.

Re:OpenSSH bug?

[innocent_white_lamb]

It's my understanding that the current problem is detailed here:
 
http://www.securiteam.com/exploits/5MP0E20CAM.html
 
And to check for it you can run 'strings /usr/sbin/sshd | grep bella'

damn't

[extirpater]

source code filching! nothing else.

when?

[stoolpigeon]

Last week? Does that mean earlier this week, or the week before the week I'm in? At what point in whatever week was last week? If I did an install/update after a certain date am I covered?
 
It would be nice if they weren't so vague about the time frame. Maybe it is to encourage people to check and not assume they will not have problems, but in a situation like this, the more accurate a picture I have of what is going on, the better I feel.

Re:when?

[Anonymous Coward]

Last week? Does that mean earlier this week, or the week before the week I'm in? At what point in whatever week was last week? If I did an install/update after a certain date am I covered?

It doesn't matter. Just run the script provided (linked to in the summary) on (say) every system updated during August, and it will tell you if you have installed a potentially compromised package.

Re:when?

[Anonymous Coward]

According to This, it would have been before 14 August as that is when they announced that they noticed something.

Re:when?

[AvitarX]

Last week either means the last 7 days, or the week before the week we were in (last Saturday through the Sunday before last).

So it does not preclude earlier this week, but I would say it is a less common usage to mean the last seven days without a qualifier (such as within the last week).

Re:when?

[Anonymous Coward]

Careful about that script. When you do:

gpg --verify openssh-blacklist-1.0.sh.asc openssh-blacklist-1.0.sh

you get the following warning:

gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.

I wouldn't run that script until this problem is fixed.

Re:when?

[fbjon]

I've never heard of anyone saying "last week" meaning an arbitrary 7-day period.

Re:when?

[Anonymous Coward]

I've heard someone use it several times, just like that in the last week.

Sorry, had to. :)

Re:when?

[Nick Ives]

It's common to use it exactly like that here in the UK. I'm sure I've seen it used in that context on American TV shows too...

roughly 30 kernel 0dayz circulating

[Anonymous Coward]

I can confirm that roughly 30 kernel 0dayz circulate in the underground. Working for all kernelz 2.6.X up to 2.6.27-rc3 :)

happy birthday.

Re:roughly 30 kernel 0dayz circulating

[Anonymous Coward]

I can confirm that I am the son of Jesus.

Re:roughly 30 kernel 0dayz circulating

[Anonymous Coward]

I can confirm that Captain Falcon was selected for Obama's VP.

Re:roughly 30 kernel 0dayz circulating

[Anonymous Coward]

I can confirm that Jesus falcon punched Obama until he gave up the secret 30 government 0-days in the kernel.

Re:roughly 30 kernel 0dayz circulating

[sdsucks]

Nice. I just compiled 2.6.27-rc4 on my notebook so I guess I'm safe for now. ;)

Re:roughly 30 kernel 0dayz circulating

[Anonymous Coward]

Are you sure you know what "confirm" means?

Re:roughly 30 kernel 0dayz circulating

[Anonymous Coward]

No you can't. Unless you provide solid proof, you're not confirming anything (as "Anonymous Coward" is not a known source of reliable information).

Re:roughly 30 kernel 0dayz circulating

[Anonymous Coward]

why is this modded interesting?
there's no proof of _any_ kind offered.
by that token, this would be modded insightful too:
i can confirm that roughly 30 terrorist attacks are being planned in the underground. Sites to attack will include New York City to Tokyo.

Re:roughly 30 kernel 0dayz circulating

[againjj]

And we are supposed to take the word of an AC on faith?

(If the parent weren't (Score:3, Interesting) I would have ignored this smug vacuous statement.)

Re:roughly 30 kernel 0dayz circulating

[HappySmileMan]

Difference is, he's getting ignored or laughed at, once the FBI raid /. for the logs, you're going to gitmo

Suuure...

[Anonymous Coward]

"Just run this shell script to verify you're not infected"

No way I'm falling for that one.

Back to work.

"Compromised?"

[Hyppy]

I could not RTFA (/.ed), but is there any indication of how this "compromise" occurred?

My hats off, though, to the Red Hat folks. Full disclosure and immediate positive action speaks volumes.

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.

Re:"Compromised?"

[corbettw]

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?"

[Anonymous Coward]

/Luthor

WRONG!!!!

Nowt wrong with using Fedora in production. I use it productively on my home machine.

Probably not a great idea to use it in production in an enterprise environment though.

No idea how the intrusion took place- it is not mentioned in tfe (email).

Re:"Compromised?"

[betterunixthanunix]

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.

Re:"Compromised?"

[pembo13]

In all fairness, and not to paint them in a bad light. The sequence was more like immediate action, and then full disclosure. But I got the feeling that the delay was due to some legal issues.

Re:"Compromised?"

[Anonymous Coward]

Last time I checked the servers that host the Fedora infrastructure are running RedHat, not Fedora as you indirectly suggest.

Re:"Compromised?"

[Anonymous Coward]

Better RTFA when you can. 1) There hasn't been full disclosure (yet, I expect they'll tell more when they know more). 2) 'Immediate' is the wrong word here. The problems started last week (and were noticeable to outsiders as the repositories went down) and RH just stonewalled all enquiries until now.

If MS or Sun or any other company behaved this way then Slashdot would be rightly ripping them a new one. I mean, letting your customers run a possibly compromised SSH for over a week???

Re:"Compromised?"

[MrMr]

...At least in theory.
Your theory fails on its first test because of the little detail that only RHEL appears to have been compromised and not Fedora.

Re:"Compromised?"

[Hyppy]

I didn't suggest any such thing, Coward.

The Fedora repository and signed packages may or may not have been compromised. RHEL packages are believed to be safe. Ergo, it's not much of an issue for production (read: critical) servers, since they should not be running a non-production distro.

Re:"Compromised?"

[Anonymous Coward]

Fedora releases also have limited support lifetimes. I forget the length of time but I think it's only one year. After that, you need to upgrade or run without updates - as you note. But doing full OS upgrades is also disruptive in a production environment and there will always be configuration issues and such to bring forward, new bugs, new incompatibilities, etc.

The parent is exactly right - for production, your best option is RHEL or some other supported distro. Then you can upgrade based on features. Not when you start having to run unpatched. The system remains more stable and users see less down time.

At home, I run openSuSe and have the latest release running (with KDE 4.1 - sweet!). No way would I suggest running that production, though, unless there was a very compelling reason for doing so. Right now, at least, there isn't by any stretch of the imagination.

Re:"Compromised?"

[Anonymous Coward]

Someone uploaded "hacked" packages which went to all of the official repositories. So anyone doing a simple yum update would potentially get the bad packages...

Re:"Compromised?"

[assassinator42]

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)."

Re:"Compromised?"

[njhunter]

...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.

Fedora is for those that didn't want change from running Redhat through the years. Those with a higher tolerance for change went to CentOS and the more daring to Debian (the really daring may have tried ports from FreeBSD in between and returned).

Re:"Compromised?"

[Hyppy]

It seems neither OS's repositories were compromised.

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.

Your two statements seem to contradict each other, if you consider the third-party mirrors and distribution sources as "Fedora" repositories.

Re:"Compromised?"

[dstech]

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.

Re:"Compromised?"

[Just Brew It!]

Both the Fedora and Redhat announcements actually say the opposite -- i.e., that none of the official repositories were compromised. The issue is that there may now be packages circulating in the wild which are not legitimate, but appear to be signed with the official Fedora/Redhat keys. If I'm reading things right, it would take the equivalent of a phishing attack against a server admin (i.e. convince them to install a trojaned package which appears to be legit) to compromise a sever running either of these distros. The official repositories are still secure, and if you only install from the official repositories, you will not be affected.

Re:"Compromised?"

[Anonymous Coward]

Is this incident something that is possible in CentOS?

Re:"Compromised?"

[Phroggy]

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.

I thought that too, but I was wrong, and it bit me in the ass. Fedora is NOT appropriate for a production environment, period. Fedora drops all support 13 months after release, which means they stop issuing security patches, period. In a production environment where you're likely to have 13 month uptimes, that would mean a reinstall every time you reboot the machine.

If you want a RedHat-based distro with long-term community support, the one you're looking for is CentOS, or so I'm told. For your desktop that you're likely to reinstall every year or so anyway, go ahead and run Fedora.

Re:"Compromised?"

[StormReaver]

"I could not RTFA (/.ed), but is there any indication of how this "compromise" occurred?"

The article does not indicate how the compromise occurred.

Re:"Compromised?"

[yuna49]

Any ideas about whether the RHEL compromise threatened the integrity of the CentOS repositories? My guess is probably not, since CentOS has a separate signing key, etc., but it would be nice to hear someone say so officially.

Re:"Compromised?"

[bill_mcgonigle]

Wait... so the OpenSSH packages are in the wild? So why are they not re-issuing the RHEL signing key?

Re:"Compromised?"

[Anonymous Coward]

Huh?! CentOS just issued security updates for openssh. So they probably flowed down the compromised code...

Re:"Compromised?"

[Just Brew It!]

I imagine they weighed the disruption of forcing everyone to update their keys against the odds of some sysadmin getting tricked into installing one of the bad packages. I haven't heard anything yet about sightings of the bogus packages "in the wild", but I think we need to assume that it is a possibility. On the other hand, I would think that with a package as critical as OpenSSH, sysadmins would be careful to only install it from official repositories (which, according to the announcement from Redhat, have not been compromised).

Re:"Compromised?"

[Anonymous Coward]

I didn't suggest any such thing, Coward.

Oh, and I am sure that "Hyppy" is your real name. No wait, you are just as much of an anonymous coward as everyone else on this site.

Re:"Compromised?"

[amorsen]

In a production environment where you're likely to have 13 month uptimes, that would mean a reinstall every time you reboot the machine.

Upgrade != reinstall. And if security updates worry you, a 13 month uptime is a bad idea.

Re:"Compromised?"

[Phroggy]

And if security updates worry you, a 13 month uptime is a bad idea.

Only if there are exploitable holes in the kernel. For anything else, you can just restart the service.

Re:"Compromised?"

[amorsen]

Only if there are exploitable holes in the kernel. For anything else, you can just restart the service.

But there are.

Re:"Compromised?"

[Phroggy]

Only if there are exploitable holes in the kernel. For anything else, you can just restart the service.

But there are.

How frequently? And are they DoS or privilege elevation attacks? I might be willing to risk the former, as long as I'm safe from the latter, and neither is possible without first compromising a daemon (on a box without user logins).

Re:"Compromised?"

[bill_mcgonigle]

Oh, I think I just figured it out - Redhat has a 'signing server' which people submit packages to for blind signing (rather than signing them themselves) so the attacker never had to have the private key and passphrase. With Fedora they don't have a signing server so the attacker would have had to have possession of the keys.

Also, Fedora sysadmins tend to be a bit more, um, agile. RHEL is 'nice' in that they take care of everything for you, so you don't actually have to 'get' lots of stuff, so the degree of difficulty would be different, on average.

Not Time for A Distro War

[Bob9113]

Pretty sure most of us are above this anyway, but let's avoid a distro flamewar. You can look through my past comments and see that RH is far from my preferred distro, and I love to take shots at them. But now is not the time. Anyone can get hacked, and it sucks. And they're being responsible about reporting and mitigating.

Godspeed, gentlemen.

Re:Not Time for A Distro War

[Anonymous Coward]

Indeed, now would be a good time for the other distros to carefully examine what the Fedora Project has said so far, and perhaps what little the Fedora Project leadership might wish to discuss privately with them, and then determine what kinds of vulnerabilities their own distros (and/or infrastructures) might have at this time.

In short, whatever exactly happened to the Fedora Project can precipitate a whole array of "what if's" for security specialists to consider, including prevention, identification, isolation, workarounds and eventual repair/recovery.

Re:Not Time for A Distro War

[Anonymous Coward]

You know, you're completely right. Thank you.

Probably a dictionary user/passwd

[billsf]

While it seems likely there are some flaws in SSH (if you know, you know) that won't be posted here, 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'.

Since it seems impossible to educate people about good pass words, these lame attacks will sometimes succeed. Any corporate admin should run 'crack' often. Moving SSH to any port other than 22 will eliminate 99.9% of these lame scans. SSH is secure for today, if used properly. All suspected exploits of the code itself are unproven.

Nothing to be alarmed about here. Problems that affect corporations are unlikely to affect knowledgeable users. To them, computers are 'a necessary evil'. To us, that is our thing.

Re:Probably a dictionary user/passwd

[Anonymous Coward]

SSHguard sounds nice, but if I install it I add to the risk that SSHguard will have a remote exploit. I'll stick to strong passwords.

Re:Probably a dictionary user/passwd

[zrq]

I hadn't heard of SSHguard, but I do use fail2ban.
Any thoughts on which is better SSHguard or Fail2ban ?

Does anyone know of a simple SSH honeypot that looks like a ssh server, but just logs the IP address, usernames and passwords that the robots are trying to use ?

Re:Probably a dictionary user/passwd

[Hatta]

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:Probably a dictionary user/passwd

[Hatta]

Does anyone know of a simple SSH honeypot that looks like a ssh server, but just logs the IP address, usernames and passwords that the robots are trying to use ?

grep /var/log/access.log

Re:Probably a dictionary user/passwd

[zrq]

grep /var/log/access.log

I meant something like this kojoney that pretends to be a ssh server but isn't.

Re:Probably a dictionary user/passwd

[Anonymous Coward]

I cannot speak to Red Hat's internal process, since I am not a Red Hat employee... but as a Fedora contributor I can tell you that as far as I am aware the ssh keys are used for the important contributor access. We are asked to submit a ssh public key into the Fedora Account System which is then used for anything related to a traditional system shell login that makes use of ssh to negotate the communication. When ssh is used by a contributor to do Fedora project work, its used with key authentication..account password authentication is not offered as option..even as a fallback with ssh key auth fails. So its pretty difficult to see how the common brute force scanning of ssh passwords on port 22 would be a possible vector for the breach.

Re:Probably a dictionary user/passwd

[Anonymous Coward]

Telnet access was so 15 years ago

ssh password-auth was so 10 years ago

ssh public key auth was so 5 years ago

Today the smart people first connect to a VPN, _then_ use ssh via public key auth.

Sudo FTF

[dhTardis]

All it has to do is wait for you to run sudo, or wait for a root shell to be open in an xterm and send it fake keystrokes. All that without needing to even read your keystrokes.

Or it can just phone home and use a 0-day local privilege escalation attack before whatever update manager can do its thing. Or just pose as the update manager.

Follow-up on comprised packages?

[Alwin Henseler]

Exactly HOW or WHO did this is not mentioned in TFA

If they have/get their hands on these modified (but signed) packages, it would be nice if they'd do some reverse engineering, and publish a follow-up detailing *what* was modified. That might provide some insight on why it was done (and perhaps who was behind it).

CentOS?

[wiedzmin]

So, does this mean that CentOS is also affected?

Re:CentOS?

[idontgno]

Per http://orcorc.blogspot.com/2008/08/cve-2007-4752-and-centos.html via http://planet.centos.org/:

updated 22 Aug 2008 CentOS acknowledge CVE-2007-4752 and are reviewing our build and signing processes and hosts for signs of tampering subsequent to retrieval of SRPMs.

This is Russ Herrold's blog, so you can consider it authoritative. I think that this announcement has become the channel MOTD on #centos as well.

Executive summary: They're aware of the issue and examining their stuff to see whether they got bit.

Re:CentOS?

[hav0x]

Also the first thing that I thought.

Have a couple(?) servers running centos in the place I started working recently.
Then again those things, for what I've seen (only been there a couple of weeks), haven't been updated in ages, so I kinda dismissed it immediatly.
Yay for not updating production boxes! :D

Interesting how a thing like this affects a whole ecosystem.

Re:CentOS?

[Sadsfae]

What about CentOS? Did the compromised code flowed down to CentOS?

There was no compromised code, they were just taking all precautions possible.

If you look at the update, it fixes an older issue with openssh-server and also signs it with a new key.

Stuff like this is prevalent in big enterprise places like RHT that get a lot of exposure.

Quick, concise response to this situation on the part of Red Hat, well done in my opinion.

Other vendors could learn from their example.

Hmm

[AP31R0N]

So, Fedora and Red Hat use Windows Server 2003 for development?

Uhm... How?

[X.25]

I really only care to know HOW the attacker got in.

Basically, if he used unknown 0-day and RH/Fedora have no idea what he exploited, then they should say so, so people can watch out.

If he stole username/password from someone dumb - say so.

If he walked into the hosting center, say so.

I REALLY want to how know he compromised their server(s).

I might be next v0v

This is becoming a frequent issue in the last year

[psychosmyth]

With several distros being compromised in the last year, it's hard not to suspect some common link. Could this be an attack on free software in general from those that stand to loose money? Conspire if you will.

Re:What?

[Slash.Poop]

I just call them as I see them.

Oh and by the way.....Is there any way I could get a rating of -2, Complete Douchebag? Being modded down to that level by the people that mod these messages, the slashDot TROLLS, will complete my life and bring a smile to my face. Please?

Re:What?

[Anonymous Coward]

No, I'm afraid I can't be bothered. Your miserable life will never be complete.

Documens vs system files

[SEMW]

Like change system files? Nope. ... So... it can mess up my documents? Darn.

Oh, good. My life's work is reconstructable in a mere few decades; wheras if it damages system files, a reinstall could take up to half an hour!

Re:Documens vs system files

[Randle_Revar]

You don't make backups?

Re:Documens vs system files

[SEMW]

Well, yes, but you see the point. Your data is worth a lot more than the OS; which can be redownloaded at any time. And not everyone makes backups.

Re:Documens vs system files

[oddfox]

Most /. users do make backups. Most users do not make backups. These are two very different groups and an important distinction to make when you're talking about system security. People are simply pointing out that personal documents are far more valuable than a hosed system a lot of the time, and rather than saying you have an interesting point and just accepting the fact of the matter, you make the excuse that people should be performing regular backups in the first place. This is the real world, and most people do not bother with that step even if it were feasible for them to do so.

Besides, how do backups help you when your personal information is stolen? Does the fact that you still have it once it's wiped change the fact that the attacker now has it as well? Backups prevent you from losing data, not from having it stolen.

Sorry... Here's proof.

[grayn0de]

http://www.sophos.com/security/analyses/viruses-and-spyware/macinit9403.html

Note that the first detection for this was back in 1994, but still... it's proof that viruses can (and have) be written for Macs.

Now that OS X 10.5 is fully Unix (BSD) in the back end and most Macs are Intel-based architecture and not protected with more than the firewall, I say that it probably just is not noticed as much.

Why do you have the computer?

[DragonHawk]

Like change system files? Nope. How about bind to privileged ports? Nope. So... it can mess up my documents? Darn.

Why do you have the computer? Just so you can have some privileged ports and system files that a remote exploit to an unprivileged account can't touch? Or do you actually, you know, use your computer for stuff?

Because if you're using your computer for anything, then that's what's really valuable.

Case in point: The private keys used to sign Red Hat/Fedora packages qualify as "documents" in your scenario.

This should serve as a wakeup call for all of us

[unix_geek_512]

I applaud Redhat and Fedora for disclosing this and hope that the whole open source community will join forces to help prevent this from happening again.

Unfortunately as the popularity of open source increases it is likely that the community will become a bigger target.

I am sure all the major distributions and most high-profile projects have already been attacked and will continue to be attacked.

Now may be a good time for all of us to review our security procedures and put measures in place to protect the integrity of the source code, binary packages and all systems used for development.

Port randomization, brute force detection and prevention, strong passwords, strong encryption, intrusion detection and source code/binary integrity verification systems should be deployed and updated regularly.

I hate to speculate in the absence of concrete evidence and information on the compromise, but it is quite possible that two or three factor authentication and the measures enumerated earlier might have prevented this compromise from occurring.

I am confident Redhat and Fedora will disclose more information as their investigation proceeds and as any legal issues are addressed.

May the source be with you!

Again?

[kungfuj35u5]

Every time one of these awful exploits are found, it seems majority of them are Redhat vulnerabilities (with the exception of the recent Debian hole). What's up with that?

Re:Again?

[Anonymous Coward]

Every time one of these awful exploits are found, it seems majority of them are Redhat vulnerabilities (with the exception of the recent Debian hole). What's up with that?

I guess you missed the 187 Debian security advisories that have been published so far this year?

Just because many public POC exploits are tailored for RHEL doesn't mean other distros are immune.

what i find interesting

[Anonymous Coward]

is that the hardware is a PCI card.

http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/8/nshield/

Could that be flashed by software? Hope not.
Should be a dip switch on the card to disable/enable flash upgrade by compromised host PC.

"most come with the distribution"

[tepples]

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.

Quite a few people who have posted comments to other Slashdot articles have claimed that the difficulty of installing software that did not "come with the distribution" holds back the spread of GNU/Linux on the home and small-office desktop. There are plenty of apps that just aren't suitable for the major distributions' repositories. For example, some apps are not notable because they're for a vertical market. Others have good reason not to be free software with free content, such as many video games.

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.

How smoothly would this work for college students taking a programming class?

An icon to show you're handicapped by a keylogger

[tepples]

A keylogger wouldn't need root access. All it has to do is monitor the keyboard and send out packets.

In an ideal operating environment, any process that monitors the keyboard would show up in a list of accessibility tools, and the user could view this list using the "access" icon (shaped like a stylized man in a wheelchair) in the system notification area.

Security is a process

[jmorris42]

> A keylogger wouldn't need root access.

Amazingly enough the designers of X back in the Elder Days thought of that possibility and took steps. X has the ability to stop keyloggers from getting things like passwords (barring root, then all bets are off) by including the exclusive keyboard grab. Of course since Moz Corp basically just ports from Windows and Windows doesn't have anything of the sort I'd bet good money Firefox doesn't even use it in dialogs it KNOWS are asking for a password.

It would be an instructive exercise to look at the various places where passwords are requested and see if any of them use it. Does the new GNOME root protection wrappers use it? Does KDE, or any of the distro specific tools? Security is a process, drop the ball at any step and the bad guys win. X did it's bit, did anyone else follow through?

For example xterm does support Secure Keyboard while gnome-terminal doesn't. That said, how many of us have actually USED the secure keyboard feature?

Re:Security is a process

[jambox]

I stand corrected! Well done X guys, poor show Mozilla. Although thinking about it, I wasn't just on about passwords. Keyloggers can be useful when spying on people by getting phone numbers, credit card details, addresses and personal correspondence.

Firefox smells like fail.

[jmorris42]

> I'd bet good money Firefox doesn't even use it in dialogs it KNOWS are asking for a password.

Replying to myself.... Doh, I could have checked it myself so I just did and nope, Firefox doesn't lock the keyboard. Even when it pops up a specific box asking for a username/password pair. Of course if you allow FF to autofill passwords it is a moot point anyway since any process that can run as you can read the obfuscated passwords.

TURN OFF NIGHTLY UPDATES UNTIL YOU HAVE NEW KEYS!

[Jizzbug]

In combination with "New Attack Against Multiple Encryption Functions," everybody running Fedora or RHEL would do good to turn off nightly updates. At least until you have the new package signing keys.

Especially if you're worried about DNS poisoning.

Windows Admin problems not MS fault?

[Nick Ives]

I remember a bug with a W2k service pack that completely disabled the network for non administrators. The word at the time was that even the testers ran as Admin all the time because trying to do anything as a normal user was such a pain.

I don't know about Macs but in Unix the whole running as a normal user thing is enforced by very strong developer policies. MS should have been stricter about enforcing similar polices before NT became mainstream; instead they're having to hack it in late in the game with stuff like UAC.

Also, I don't think people write malware for Windows because they don't care about the platform, it's just because it's the biggest target. If Unix/Mac/ was as huge on the desktop as Windows, that platform would be the target. It's just how it goes.

Turn Off Nightly Updates, until you have new keys!

[Jizzbug]

In combination with "New Attack Against Multiple Encryption Functions," everybody running Fedora, RHEL, or any variant configured against Red Hat update repo's would do good to turn off nightly updates. At least until you have the new package signing keys.

Especially if you're worried about DNS poisoning.

TURN OFF NIGHTLY UPDATES UNTIL YOU HAVE NEW KEYS!

[Anonymous Coward]

In combination with "New Attack Against Multiple Encryption Functions," everybody running Fedora, RHEL, or any variant configured against Red Hat update repo's would do good to turn off nightly updates. At least until you have the new package signing keys.

Especially if you're worried about DNS poisoning.

FUD

[0ld_d0g]

Go read the NT kernel whitepaper. Its fine by me if you dont, people who actually understand kernel architecture will just look at your post and laugh and probably feel sorry.

Its obvious you're trolling , and anyway its not my job to educate people. I know the 12yr olds here just love the "[citation needed]" meme so I wont take the cliche route. I'm not making any claims, you are. It helps when you're informed and not make a complete and utter fool of yourself.

What the compromised packages contained?

[Anonymous Coward]

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.

Re:What the compromised packages contained?

[Anonymous Coward]

Which services were publicly-accessible on your server?

Re:What the compromised packages contained?

[Anonymous Coward]

I had the same problem with rpmforge, but a friend of mine did not. We both run RHEL with the rpmforge repository. Apparently the attacker was being selective and didn't want to draw too much attention by distributing the package worldwide. We run a few ftp mirrors, so that has probably made us a target.

Posting as AC too, same reason.

Re:What the compromised packages contained?

[Anonymous Coward]

(I am an autor of the GP post)

SMTP (postfix, incl. SSL), dovecot (pop3/imap, pop3s/imaps), ssh (hundreds of accounts, so also weak password attack was possible, but nothing incl. remote syslog suggests it is true), DNS (BIND), Samba (altough this one only for limited range of IP addresses), maybe few other services.

Re:What the compromised packages contained?

[Anonymous Coward]

(I am the author of the GP post)

I have verified that the trojanized packages has been installed on my RHEL system on Aug 15 around 0:28, well outside of the normal time yum does its upgrades (from cron.daily, i.e. after 4am). Also the remote syslog server nor the yum.log file reports the upgrade of openssh at that time, so it is possible the package was installed using something other than yum. I wonder why the attacker who was able to change a system time and install a RPM using something other than daily yum update, needed to use a signed RPM package.

Hmm, time going backwards and then forward reminds me of Kerberos. Maybe some ticket replay attack? Do you use Kerberos? I do.

As for the trojanized package: the strings(1) on /usr/sbin/sshd showed that sshd contained the string "sendto" which I was not able to find in any other clean system - so it presumably calls home (probably over UDP). Another interesting string not present in other sshd binaries was ",password".

CentOS?

[Anonymous Coward]

What about CentOS? Did the compromised code flowed down to CentOS?

Definitions

[bill_mcgonigle]

Fedora is NOT appropriate for a production environment, period.

This is entirely dependent on what your production environment does, what its requirements are, and what your server infrastructure looks like. Not every environment has the problem where switching out OS versions is a big deal or results in downtime.

Re:Definitions

[Phroggy]

Fedora is NOT appropriate for a production environment, period.

This is entirely dependent on what your production environment does, what its requirements are, and what your server infrastructure looks like. Not every environment has the problem where switching out OS versions is a big deal or results in downtime.

Alright, fair enough... but replacing the OS every year is definitely not what comes to mind when I think "production environment", even if you can do so without downtime. YMMV.

Simple

[/dev/trash]

No one uses Debian or Ubuntu or Slack all that much so they go after the popular OS.

backups

[Anonymous Coward]

It can mess what are most likely the most important and least-replaceable data on your machine. This doesn't bother you ?

No, because I actually have backups that go back several weeks. (Thank you Time Machine.)

Re:backups

[oddfox]

I didn't play around much with Time Machine when I had 10.5.2 installed on my box but I don't think I could've used it a whole lot anyways since, among other things, it doesn't really work well with FileVault. Hopefully in future revisions to Time Machine they address these deficiencies and turn it into the great product it should be. More to the point of the discussion, would it not be possible for the malware to simply tamper with the Time Machine backup while it's doing its damage? Up until not too long ago you could even launch applications automatically from within a Time Machine backup.

Bwahaha!

[PingXao]

Can SELinux just quietly go away now? Pretty please? I don't mean just disabling it, which I can already do, I mean not install it at all.

Whoa

[Anonymous Coward]

I didn't know Fedora was Debian based..

Dont forget...

[Anonymous Coward]

...to pay your $699 licensing fee you cock smoking teabaggers!

But Linux is more secure!!11!!1!!!1q1!

[Anonymous Coward]

But, but! Linux is more secure!!111!!!

Yea, when was the last time the Windows Update site got hacked....oh yea, never.

Fail.....

Yes, Linux has a small place in business, yes it's a good O/S, NO it is not more secure than Windows no matter how bad the fanboys agrue. Just look at how DHS had to step in and "fix" some projects and now this.

Please, don't flame because you have no other "proof" to backup any claim linux is more secure. Don't be simple Jack.....

"Mama, I'll see you again tonight in my head movies. But this head movies makes my eyes rain!"