Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
High ProfileHigh ProfilePosted Nov 17, 2004 20:00 UTC (Wed) by elanthis (subscriber, #6227)Parent article: freedesktop.org site compromised
We've fairly recently seen Debian.org, GNOME.org, Savannah.GNU.org, and now FreeDesktop.org security breaches. One has to wonder if it's the same person/group or individuals. Either way, these are all high profile OSS sites, so attacks by people who know what they're doing aren't exactly unexpected.
Still, given how many people tend to vaunt OSS security, it's a bit sad these sites keep getting broken into. I'm curious to see what the supposed break-in method was for FDo, and whether it was do to inept administration (like not applying security patches) or general poor security of the system(s) in question.
(Log in to post comments)
High Profile Posted Nov 17, 2004 20:33 UTC (Wed) by madscientist (subscriber, #16861) [Link] > We've fairly recently seen Debian.org, GNOME.org, Savannah.GNU.org, and now FreeDesktop.org security breaches.
I'm not familiar with the details of gnome.org or fd.org, but the big problem with both Debian and Savannah is that they allow remote login to any registered user. It's one thing to secure a system against remote attacks, but it's an astronomically more difficult thing to secure a system which is intended to let a wide range of users remotely log in.
High Profile Posted Nov 17, 2004 21:43 UTC (Wed) by thomask (guest, #17985) [Link] Hmm. Security in online collaboration could become the achilles heel of the OSS community if we don't work hard enough to secure our systems.
High Profile Posted Nov 17, 2004 21:50 UTC (Wed) by madscientist (subscriber, #16861) [Link] > Security in online collaboration could become the achilles heel of the OSS community if we don't work hard enough to secure our systems.
There's no particular reason that online collaboration environments _HAVE_ to allow remote login; indeed, Savannah has since removed that capability IIRC. Debian has a much more difficult problem to solve but with sufficient automation it could still be done.
The reality is there are always jerks out there and little you can do about it. Similarly, there are always bugs and not much you can do about that. The best we can hope for is to implement enough features like chroot jails and selinux etc. to make the jerks' lives difficult.
High Profile Posted Nov 17, 2004 23:35 UTC (Wed) by Ross (subscriber, #4065) [Link] Short of removing access completely you can do a few things to improve thesituation. These are common knowledge but I'll repeat them anyway :)
* make any suid or sgid program which doesn't absolutely need to be that
You missed some critical steps Posted Nov 18, 2004 3:20 UTC (Thu) by ringerc (guest, #3071) [Link] Another really important one is to deny users the option to use passwords as their only form of authentication for a service. If you must have a password on their account (instead of an invalid hash, so login is impossible), do not permit it to be used for shell logins and don't let anything that takes the password be accessed except by the local hot. Run _everything_ over ssh, and require users to supply an ssh public key during account setup.
If the sshd is trojaned by a local attacker who got in with a password stolen from a less secure system (Apache/SourceForge compromise), they can't steal logins to attack other hosts. Remember, many people use the same usernames/passwords for many sites, and there's little you can do to prevent this. This improves your users' security. It's also considerably harder to steal an ssh key than a password, so it helps your security too.
Next, if at all possible deny local logins. Use ssh to set up port forwards or run automatic commands (like '/usr/bin/cvs server'), but never give users a shell. Unfortunately, this may require the users to manage multiple keys. If you absolutely must give them a shell, if at all possible give them a very restricted shell that can only run a couple of commands. I'm talking not even `ls'. If at all possible, chroot it.
A similar approach can be configured for things like authenticated https. Generate client certificates for the user, and require them before authentication is attempted. This makes brute-force attacks very hard, and means that a stolen password is no good without the attacker also successfully stealing the client certificate from the same person. Passwords compromised as a result of someone using the same username/password with an insecure protocol do the attacker no good at all.
There's also some obvious stuff - run as few services as root as possible, use chroot like there's no tomorrow, run as few services _at_ _all_ as possible, etc.
Just because your server is a public host doesn't mean it shouldn't have a firewall. Lock it down.
SELinux may be a right pain, but perhaps it's less painful in the long run than a compromise? (Frankly, I'm not convinced. It's _really_ painful.)
Finally: Be utterly, foaming paranoid. If you're running a public service, there's no such thing as a trustworthy user. Work as if all of them are actively trying to get you cracked.
I don't know what happened to fd.o or if any of these steps would help them. Sometimes there's just nothing you can do, such as when a major hole is discovered in a daemon you have no choice but to run as root and it's exploited before it becomes public. Still, these steps may well help.
You missed some critical steps Posted Nov 18, 2004 3:43 UTC (Thu) by walters (subscriber, #7396) [Link] SELinux may be a right pain, but perhaps it's less painful in the long run than a compromise? (Frankly, I'm not convinced. It's _really_ painful.) Have you tried Fedora Core 3? I think that its strict policy has made a huge amount of advancement in the last 6 months since FC2. Not to mention that with the targeted default policy, many FC3 users are probably unaware (unless they read the release notes) that daemons like syslog and portmap are transparently protected.
High Profile Posted Nov 18, 2004 3:42 UTC (Thu) by jtc (guest, #6246) [Link] "The reality is there are always jerks out there and little you can do about it. Similarly, there are always bugs and not much you can do about that."
I disagree with the second sentence. While it's usually not possible to produce a system with no bugs, there are a lot of actions that can be taken to develop a system with fewer bugs (often much fewer) than would otherwise occur. Most or all of these actions fall under the category of good software engineering procedures, practices, and techniques. It's not always practical to follow such procedures completely, but I suspect that the ROI for many OSS projects would be significantly higher - less money spent on bug fixing and related maintenance and less money lost to security problems - if a solid subset of these procedures were put in place.
High Profile Posted Nov 18, 2004 9:27 UTC (Thu) by daniels (subscriber, #16193) [Link] freedesktop.org was compromised via TWiki. The thing is, while we did not have evidence of privilege escalation, the kernel vulnerability used to compromise Debian was unknown (as a vulnerability) until after the fact. So, we took full images of the system and commenced a reinstall, and took a much-needed opportunity to have a serious think about our security mechanisms and do many cleanups, et cetera (our Apache configuration, in particular, was abysmal).
When I looked last night, the only place the advisory was on was packetstormsecurity.org, and there seems to be the possibility of a couple of places where shell commands need cleaning up; of course, you can't tell, because they spend a lot of time bypassing the Taint check. Given this, and the fact that the TWiki site does not acknowledge the existence of this hole via either notes on the site, or a new source release, I would very, very seriously recommend looking at something else. fd.o will be moving to Moin when we spring back up.
TWiki hole Posted Nov 18, 2004 11:32 UTC (Thu) by colas (guest, #26092) [Link] Daniel, on Fri, 12 Nov 2004 17:12:13 -0800 Peter Thoeny sent a security alert to all TWiki webmasters listed at http://twiki.org/cgi-bin/view/Main/TWikiInstallationas soon as he was aware of the problem, that you can see at:
http://TWiki.org/cgi-bin/view/Codev/SecurityAlertExecuteC...
I see that you are not listed on the TWikiInstallation page :-(
TWiki hole Posted Nov 18, 2004 12:09 UTC (Thu) by daniels (subscriber, #16193) [Link] Thanks for your reply. But, surely now it's out in the wild, and people are being actively exploited (we weren't targetted specifically, it was just some Undernet script kiddie randomly scanning large swathes of the web, poking for Apache holes, formmail.pl, whatever), isn't it best to have it out on the site's main page, and a new release out the door with the patch? When I looked last night, neither of these have been done.
TWiki hole Posted Nov 18, 2004 12:59 UTC (Thu) by colas (guest, #26092) [Link] Well, what should be done is have all TWiki admins apply the patch, and I do not think they go to TWiki front page very often, so we must rely on other mecanism. So, let's take a small survey, in what way would you (and others reading this thread) have preferred to be warned of security problems?[1] register on a dedicated twiki-security-alert mailing list if we said: "please register to this mailing list" in install instructions, would you have done so (or avoided by fear of spam?) [2] via another (general) security mailing list (which one?) [3] via TWiki engine automatically checking for available updates and mailing you?
TWiki hole Posted Nov 18, 2004 14:11 UTC (Thu) by hmh (subscriber, #3838) [Link] [1] You do not have it yet? An announcement mailing list (moderated), where you send at most 1-2 emails/month and all security notices is really a must for any serious project.
[2] You should at the very least notify people through BugTrack, or a bunch of vendor security teams (make sure some Linux distributions are among them, please) which will get word to everyone else.
[3] This would be nice, but you better use proper cryptography to authenticate the updates...
So my reply is all of the above, and that there is no excuse for [1] not being deployed yet.
TWiki hole Posted Nov 24, 2004 21:58 UTC (Wed) by maphew (guest, #1147) [Link] >[2] You should at the very least notify people through BugTrack,
A notice was sent through BugTraq on Nov 12th. http://seclists.org/lists/bugtraq/2004/Nov/0187.html
TWiki hole Posted Nov 24, 2004 22:42 UTC (Wed) by hmh (subscriber, #3838) [Link] Then the TWiki users can't really complain that there was no notification of the issue, or that it was hidden away inside a Wiki. Maybe it could have been done better, but that's something else.
TWiki hole Posted Nov 18, 2004 17:27 UTC (Thu) by bronson (subscriber, #4806) [Link] Um, it is YOUR obligation to notify your users of security holes using any reasonable means possible, especially if the hole is already in the wild! This includes Bugtraq, your front page, your news section, your mailing lists, notifying all distributions that include your package, etc. Projects that do this well are PHP, Apache, Gallery, ISC software, etc.
At this point, it seems like the TWiki project has some serious damage control to perform. How are you going to assure your users that something like this will not happen again?
TWiki hole Posted Nov 25, 2004 17:22 UTC (Thu) by Cato (subscriber, #7643) [Link] Try searching for CAN-2004-1037 - this will find all the various reports of this vulnerability to a wide range of security email lists, including Bugtraq (most sent on Nov 12th).
TWiki hole Posted Nov 18, 2004 18:07 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Forget about any mechanism where you tell only registered TWiki users about bugs. The Twiki attempts to pressure people to register are wrong-headed, and there's nothing to stop black hats from subscribing to any mailing list you set up.Don't hide bugs. Certainly it can be wise to let the good guys have a head start, for example by alerting any distros that package TWiki in advance. But once you know that people are actively exploiting a security hole, it's your obligation to alert the general public.
TWiki hole Posted Nov 24, 2004 9:47 UTC (Wed) by Cato (subscriber, #7643) [Link] I agree about the low-volume security alert list - not yet in place, but as one of the developers I will help to make sure this happens. Separately, we removed the requirement to register for <a href="http://twiki.org/download.html">TWiki downloads</a> a while back - in retrospect we should have created the announcement list then.<p> There is some discussion of the proposed TWiki <a href="http://twiki.org/cgi-bin/view/Codev/TWikiSecurityAlertPro...">security alert process</a> at TWiki.org, please feel free to join in there.
|
|||||||||||