Weekly Edition
Return to the Security page
| |||||||||||
cvs vulnerabilities - again
Let us start with a correction: last week's cvs
vulnerability timeline stated that no update had been issued for
CentOS. In fact, this
update was posted to the CentOS-devel mailing list on May 19. One
could argue that such updates should be posted to a more prominent place,
such as the CentOS web site or the
(seemingly dormant) security lists mentioned on the mailing lists page; one
should not have to follow a development list to get security updates. Nonetheless,
we were wrong to say that an update had not been released, and apologize
accordingly.
Now, however, the time has come to deal with a new set of cvs security problems, as detailed in this advisory. A whole list of issues has been found; many of those are remotely exploitable. The time has come to apply a new set of updates, quickly. (And, yes, CentOS has released an update already). Vulnerabilities in cvs are particularly scary. It is possible to run cvs in a chroot mode, which is somewhat helpful in keeping an exploit from leading to a full root compromise of the host system. But cvs servers must have access to the code repositories they serve. It is not all that hard to imagine a cvs exploit being the first step in the insertion of evil code into a free software project's repository. A carefully executed malware insertion could escape detection for a long time. That sort of episode, beyond the immediate damage it would enable, would not reflect well on the security of the free software development process in general. We cannot afford to let it happen. With enough eyeballs, most of the obvious security problems in cvs can probably be found and fixed. That would help substantially. The simple fact, however, is that cvs is not equipped to detect direct tampering with its repositories. This shortcoming is sure to bite somebody someday; the sooner it is fixed (or avoided by a mass shift to a more contemporary version control system which performs integrity checks on its repositories) the safer we all will be. (Log in to post comments)
cvs vulnerabilities - again Posted Jun 10, 2004 3:46 UTC (Thu) by rfunk (subscriber, #4054) [Link] (or avoided by a mass shift to a more contemporary version control system which performs integrity checks on its repositories)So how do subversion, arch, bitkeeper, and so on rate on this?
cvs vulnerabilities - again Posted Jun 10, 2004 3:57 UTC (Thu) by walters (subscriber, #7396) [Link] Arch is better in two major ways:1) There is no arch server, it just relies on your web server and SFTP server. No new untrusted code. 2) Arch allows repositories (archives) to be digitally signed. So even if say your web server was cracked, an attacker couldn't modify code because it would be signed by the committers.
cvs vulnerabilities - again Posted Jun 10, 2004 8:31 UTC (Thu) by ballombe (subscriber, #9523) [Link] " But cvs servers must have access to the code repositories they serve. It is not allthat hard to imagine a cvs exploit being the first step in the insertion of evil code into a free software project's repository. " In fact this is so easy to imagine that I hope most people have taken appropriate measure already: Anonymous (read-only) cvs does not need write access to the code repositories. Commit (write access) via pserver is fundamentally insecure since it use clear text password, and cause other security problems, so write access should only be allowed via ssh. So make sure cvs pserver run as an unprivileged user that cannot write to the repository. Better yet, run it inside a user-mode-linux instance so you can completely control where it can write to (let it use a dedicated /tmp, not the global one, etc.)
chroot as root is quite useless really Posted Jun 10, 2004 11:52 UTC (Thu) by amtota (subscriber, #4012) [Link] If you can get root access from within the chroot, you can escape (chrootagain exploit) Not allowing pserver access provides better protection IMO
cvs vulnerabilities - again Posted Jun 11, 2004 19:19 UTC (Fri) by mongre26 (guest, #4224) [Link] The real answer is to never use pserver.Use ssh which has more of a security focus with features like privilege seperation and is constantly undergoing review for potential issues. Of course the potential issues with ssh should also be carefully researched and understood. It is a shame that for two weeks in a row the security page has been used dicussing pserver. pserver is widely considered a security flaw simply by its existence, even when it is a patched version. For example this site on setting up a CVS server has this to say (found the site in a google search, first page). "The :pserver: method is quite convenient for implementing remotely accessible CVS repositories, but its major drawback is that it is very insecure." Although their recommendations are not the best (chroot or tunneling) when you can use ssh directly (no pserver required at all) they do specifically note the security issue. I have seen this noted again and again and the security failings of pserver are well documented. In my opinion pserver ranks up there with a tftp server as things not to allow public internet access to. What this demonstrates is that research into what you are deploying and the application of good security practice a far more effective way to avoid potential future vulnerabilities. I run cvs repositories, none of which were affected by this flaw because I do not run a pserver. As far as code modification, well even with SSH that is possible. In fact any authentication scheme can be defeated to expose this vulnerability. The answer to this is various snapshot techniques external verification. As a security professional I am still not impressed by the comments about who got the fix out faster. It is much safer to assume that your vendor is going to be slow to respond, or be completely ignorant of a problem. For most software the latter is often the case. Given this assumption you should design your systems according to your own level of acceptance of security risk irrespective of your vendors. That one distro releases a fix slightly faster than another is an interesting PR gimmick. The reality is that no vendor is going to be fast enough, nor is it possible for every admin to be able to apply the fixes as quickly as could be required if all you depend upon is patches. I have audited several sites that simply could not update to the lastest revision of package X because of incompatibilities with their code that would take a significant effort to fix. In these cases other security precautions are necessary. The focus on how fast a patch comes (1 day or 14 days) is only a very small part of the picture and often made irrelevant by local issues. Patch patch patch has become the mantra that is passing security in many places. As a security professional it is frightening to think that we are expected to place the security of our systems merely on the whims and competence of whatever vendor(s) we choose or our ability of the admin to never sleep? How about some security process and procedures to mitigate the risk in the event of a failure? Security is about process, it is about defense in depth, it is about understanding what your have and what its weaknesses or potential weaknesses are, not just clicking when the little bubble turns red on your desktop.
|
|||||||||||