| |||||||||||
cvs vulnerabilities - againcvs vulnerabilities - againPosted Jun 11, 2004 19:19 UTC (Fri) by mongre26 (guest, #4224)Parent article: cvs vulnerabilities - again 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.
(Log in to post comments)
|
|||||||||||